aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
* Convert array_map to use new fmgr interface.Tom Lane2000-05-29
|
* Neglected to add fmgr.h to set of installed headers...Tom Lane2000-05-29
|
* Tweak fmgrtab generation so that the F_XXX macros that give OIDs forTom Lane2000-05-29
| | | | | | | | | | built-in procedures are named after the prosrc field of pg_proc (ie, the actual C function name), not the proname field. This did not use to make a difference back when the two were always the same, but in the presence of overloaded proname values we'd best try to use the C name instead. AFAICT this change affects no existing code, but it is necessary to be able to get at some built-in functions that no macro was being generated for before.
* Repair problems with overrun of timezone name length. Increase MAXTZLENTom Lane2000-05-29
| | | | | | to 10, and be consistent about whether it counts the trailing null (it does not). Also increase MAXDATELEN to be sure no buffer overflows are caused by the longer MAXTZLEN.
* Add analyze.c file for split.Bruce Momjian2000-05-29
|
* Split vacuum and analyze into separate filesBruce Momjian2000-05-29
|
* Update messages.Bruce Momjian2000-05-29
|
* Make analyze do vacuum/analyze in one step.Bruce Momjian2000-05-29
|
* More vacuum cleanupBruce Momjian2000-05-29
|
* more cleanupBruce Momjian2000-05-29
|
* Add analyze log messages for verbose mode.Bruce Momjian2000-05-29
|
* cleanupBruce Momjian2000-05-29
|
* Allow vacuum to perform analyze with shared lock. Update cvs manual.Bruce Momjian2000-05-29
|
* Generated header files parse.h and fmgroids.h are now copied intoTom Lane2000-05-29
| | | | | the src/include tree, so that -I backend is no longer necessary anywhere. Also, clean up some bit rot in contrib tree.
* Second round of fmgr changes: triggers are now invoked in new style,Tom Lane2000-05-29
| | | | CurrentTriggerData is history.
* More vacuum cleanupsBruce Momjian2000-05-29
|
* More vacuum renaming.Bruce Momjian2000-05-29
|
* Miscellaneous cleanups of places that needed to account for newTom Lane2000-05-28
| | | | pg_language entries.
* Constant-expression simplifier now knows how to simplify strict functionsTom Lane2000-05-28
| | | | | that have at least one constant-NULL input, even if other inputs are not constants.
* Install fmgr rewrite doc as README file.Tom Lane2000-05-28
| | | | Need to update user docs still ...
* First round of changes for new fmgr interface. fmgr itself and theTom Lane2000-05-28
| | | | | | | key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
* define YY_NEVER_INTERACTIVE for flex, to persuade flex that it's notTom Lane2000-05-27
| | | | | necessary to call isatty() for each and every received query. That's one less kernel call per query cycle ...
* Update kerberos patchBruce Momjian2000-05-27
|
* Back out kerberos changes. Causes compile problems.Bruce Momjian2000-05-27
|
* Patch for Kerberos V.Bruce Momjian2000-05-27
| | | | | | | | | | | | Most (nearly all) of the work was done by David Wragg <dpw@doc.ic.ac.uk> He patched 6.5.3. I've updated it for 7.0RC5. It works for MIT kerberos 1.1.1 (and previously for 1.0.6 as well). I've got the patch against 6.5.3, plus kerberized RPMS. Mike Wyer <mw@doc.ic.ac.uk> || "Woof?"
* Clean up pg_hba.confBruce Momjian2000-05-27
|
* Improve pg_hba.conf examplesBruce Momjian2000-05-27
|
* Reduce eqsel()'s fudge-factor for estimating the frequency of valuesTom Lane2000-05-26
| | | | | | | other than the most common value in a column. We had had 0.5, make it 0.1 to make it more likely that an indexscan will be chosen. Really need better statistics instead, but this should stem the bleeding meanwhile ...
* Fix too long syslog message problemTatsuo Ishii2000-05-26
|
* Generate a reasonable error message when an aggregate function is appliedTom Lane2000-05-26
| | | | to an undecorated relation name (cf. example from Ed Loehr, 5/25/00).
* More paranoia about global variables containing references to long-Tom Lane2000-05-26
| | | | since-closed file descriptors...
* After closing frontend socket, set MyProcPort->sock = -1 to ensure thatTom Lane2000-05-26
| | | | | | | | | subsequent I/O attempts fail cleanly. I'm speculating about failure scenarios in which we do pq_close, then something in a proc_exit routine opens a file (re-using that kernel FD number), then something else fails and tries to write an elog message to the frontend ... message ends up in opened file, oops. No known examples of this but it seems like a potential hole.
* Add some elog(DEBUG)'s to help diagnose mdblindwrt failures.Tom Lane2000-05-25
|
* Clean up sloppy coding of _outAExpr().Tom Lane2000-05-25
|
* Modify raw parsetree representation returned by gram.y for SubLinks:Tom Lane2000-05-25
| | | | | | | | the oper field should be a valid Node structure so it can be dumped by outfuncs.c without risk of coredump. (We had been using a raw pointer to character string, which surely is NOT a valid Node.) This doesn't cause any backwards compatibility problems for stored rules, since raw unanalyzed parsetrees are never stored.
* Do table renaming in a sane order: physical file rename must happenTom Lane2000-05-25
| | | | | | | *last*, after all updating of system catalogs. In old code, an error detected during TypeRename left the relation hosed. Also, add a call to flush the relation's relcache entry, rather than trusting to shared cache invalidation to flush it for us.
* heap_drop() should flush the relcache entry for theTom Lane2000-05-25
| | | | relation being dropped.
* On solaris, createdb/dropdb fails because of strange behavior of system().Tatsuo Ishii2000-05-25
| | | | | (it returns error with errno ECHILD upon successful completion of commands). This fix ignores an error from system() if errno == ECHILD.
* Make setproctitle update for every query.Bruce Momjian2000-05-24
|
* comment cleanupBruce Momjian2000-05-23
|
* Fix problem in which sloppily-coded test in ExecInitIndexScan wouldTom Lane2000-05-23
| | | | | | | | | | | | think that both sides of indexqual look like index keys. An example is create table inside (f1 float8 primary key); create table outside (g1 float8, g2 float8); select * from inside,outside where f1 = atan2(g1+1, g2); ERROR: ExecInitIndexScan: both left and right ops are rel-vars (note that failure is potentially platform-dependent). Solution is a cleanup I had had in mind to make anyway: functional index keys should be represented as Var nodes in the fixed indexqual, just like regular index keys.
* CleanupBruce Momjian2000-05-22
|
* I am attempting to integrate postgres (v 7.0) with an open sourceBruce Momjian2000-05-22
| | | | | | | | | | | | | | | | | | | | project I am working on (Recall - a distributed, fault-tolerant, replicated, storage framework @ http://www.fault-tolerant.org). Recall is written in C++. I need to include the postgres headers and there are some problems when including the headers w/C++. Attached is a patch generated from postgres/src that fixes my problems. I was hoping to get this into the main source. It's very small (2k) and 3 files are changed: backend/utils/fmgr/fmgr.c, backend/utils/Gen_fmgrtab.sh.in, and include/access/tupdesc.h. In C++, you get a multiply defined symbol because the variable (FmgrInfo *fmgr_pl_finfo) is defined in the header (the patch moves it to the .c file). The other problem in tupdesc.h is the use of typeid is a problem in c++ (I renamed it to oidtypeid). Thanks, Neal Norwitz
* Remove calls to getprotobyname(), which we now know leaks memory onTom Lane2000-05-21
| | | | | | some platforms --- and I also see that it is documented as not thread- safe on HPUX and possibly other platforms. No good reason not to just use IPPROTO_TCP constant from <netinet/in.h> instead.
* Repair memory leaks that caused CacheCxt to grow without bound. WeTom Lane2000-05-21
| | | | | | | | | really ought to fix relcache entry construction so that it does not do so much with CurrentMemoryContext = CacheCxt. As is, relatively harmless leaks in either sequential or index scanning translate to permanent leaks if they occur when called from relcache build. For the moment, however, the path of least resistance is to repair all such leaks...
* Add debug code to aid in memory-leak tracking: if SHOW_MEMORY_STATS isTom Lane2000-05-21
| | | | | defined then statistics about memory usage of all the global memory contexts are printed after each commit.
* Clean up grotty references to CacheCxt (externs inside functions,Tom Lane2000-05-20
| | | | duplicate global declarations, no points for style at all!)
* Enhance multibyte support.Tatsuo Ishii2000-05-20
| | | | SJIS UDC (NEC selection IBM kanji) support contributed by Eiji Tokuya
* Add KEEPALIVE option to the socket of backend. This will automaticallyTatsuo Ishii2000-05-20
| | | | terminate the backend that has no frontend anymore.
* Revise FlushRelationBuffers/ReleaseRelationBuffers per discussion withTom Lane2000-05-19
| | | | | | | | | | | | | | | | | | | | | Hiroshi. ReleaseRelationBuffers now removes rel's buffers from pool, instead of merely marking them nondirty. The old code would leave valid buffers for a deleted relation, which didn't cause any known problems but can't possibly be a good idea. There were several places which called ReleaseRelationBuffers *and* FlushRelationBuffers, which is now unnecessary; but there were others that did not. FlushRelationBuffers no longer emits a warning notice if it finds dirty buffers to flush, because with the current bufmgr behavior that's not an unexpected condition. Also, FlushRelationBuffers will flush out all dirty buffers for the relation regardless of block number. This ensures that pg_upgrade's expectations are met about tuple on-row status bits being up-to-date on disk. Lastly, tweak BufTableDelete() to clear the buffer's tag so that no one can mistake it for being a still-valid buffer for the page it once held. Formerly, the buffer would not be found by buffer hashtable searches after BufTableDelete(), but it would still be thought to belong to its old relation by the routines that sequentially scan the shared-buffer array. Again I know of no bugs caused by that, but it still can't be a good idea.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 18:02:59 +0000