aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
...
* Add a CaseSensitive parameter to synonym dictionaries.Tom Lane2008-03-10
| | | | Simon Riggs
* Remove no-longer-used XLogCacheByte field of XLogCtl.Tom Lane2008-03-10
| | | | Itagaki Takahiro
* Reduce memory consumption during VACUUM of large relations, by usingTom Lane2008-03-10
| | | | | | | FSMPageData (6 bytes) instead of PageFreeSpaceInfo (8 or 16 bytes) for the temporary array of page-free-space information. Itagaki Takahiro
* Remove postmaster.c's check that NBuffers is at least twice MaxBackends.Tom Lane2008-03-09
| | | | | | | | | | | | With the addition of multiple autovacuum workers, our choices were to delete the check, document the interaction with autovacuum_max_workers, or complicate the check to try to hide that interaction. Since this restriction has never been adequate to ensure backends can't run out of pinnable buffers, it doesn't really have enough excuse to live to justify the second or third choices. Per discussion of a complaint from Andreas Kling (see also bug #3888). This commit also removes several documentation references to this restriction, but I'm not sure I got them all.
* Change patternsel() so that instead of switching from a pureTom Lane2008-03-09
| | | | | | | | | | pattern-examination heuristic method to purely histogram-driven selectivity at histogram size 100, we compute both estimates and use a weighted average. The weight put on the heuristic estimate decreases linearly with histogram size, dropping to zero for 100 or more histogram entries. Likewise in ltreeparentsel(). After a patch by Greg Stark, though I reorganized the logic a bit to give the caller of histogram_selectivity() more control.
* Modify prefix_selectivity() so that it will never estimate the selectivityTom Lane2008-03-08
| | | | | | | | | | | | | | of the generated range condition var >= 'foo' AND var < 'fop' as being less than what eqsel() would estimate for var = 'foo'. This is intuitively reasonable and it gets rid of the need for some entirely ad-hoc coding we formerly used to reject bogus estimates. The basic problem here is that if the prefix is more than a few characters long, the two boundary values are too close together to be distinguishable by comparison to the column histogram, resulting in a selectivity estimate of zero, which is often not very sane. Change motivated by an example from Peter Eisentraut. Arguably this is a bug fix, but I'll refrain from back-patching it for the moment.
* Refactor heap_page_prune so that instead of changing item states on-the-fly,Tom Lane2008-03-08
| | | | | | | | | | | | | | | | | it accumulates the set of changes to be made and then applies them. It had to accumulate the set of changes anyway to prepare a WAL record for the pruning action, so this isn't an enormous change; the only new complexity is to not doubly mark tuples that are visited twice in the scan. The main advantage is that we can substantially reduce the scope of the critical section in which the changes are applied, thus avoiding PANIC in foreseeable cases like running out of memory in inval.c. A nice secondary advantage is that it is now far clearer that WAL replay will actually do the same thing that the original pruning did. This commit doesn't do anything about the open problem that CacheInvalidateHeapTuple doesn't have the right semantics for a CTID change caused by collapsing out a redirect pointer. But whatever we do about that, it'll be a good idea to not do it inside a critical section.
* Improve efficiency of attribute scanning in CopyReadAttributesCSV.Andrew Dunstan2008-03-08
| | | | | | The loop is split into two parts, inside quotes, and outside quotes, saving some instructions in both parts. Heikki Linnakangas
* Improve pglz_decompress() so that it cannot clobber memory beyond theTom Lane2008-03-08
| | | | | | | | | | | | available output buffer when presented with corrupt input. Some testing suggests that this slows the decompression loop about 1%, which seems an acceptable price to pay for more robustness. (Curiously, the penalty seems to be *less* on not-very-compressible data, which I didn't expect since the overhead per output byte ought to be more in the literal-bytes path.) Patch from Zdenek Kotala. I fixed a corner case and did some renaming of variables to make the routine more readable.
* This patch addresses some issues in TOAST compression strategy thatTom Lane2008-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | were discussed last year, but we felt it was too late in the 8.3 cycle to change the code immediately. Specifically, the patch: * Reduces the minimum datum size to be considered for compression from 256 to 32 bytes, as suggested by Greg Stark. * Increases the required compression rate for compressed storage from 20% to 25%, again per Greg's suggestion. * Replaces force_input_size (size above which compression is forced) with a maximum size to be considered for compression. It was agreed that allowing large inputs to escape the minimum-compression-rate requirement was not bright, and that indeed we'd rather have a knob that acted in the other direction. I set this value to 1MB for the moment, but it could use some performance studies to tune it. * Adds an early-failure path to the compressor as suggested by Jan: if it's been unable to find even one compressible substring in the first 1KB (parameterizable), assume we're looking at incompressible input and give up. (Possibly this logic can be improved, but I'll commit it as-is for now.) * Improves the toasting heuristics so that when we have very large fields with attstorage 'x' or 'e', we will push those out to toast storage before considering inline compression of shorter fields. This also responds to a suggestion of Greg's, though my original proposal for a solution was a bit off base because it didn't fix the problem for large 'e' fields. There was some discussion in the earlier threads of exposing some of the compression knobs to users, perhaps even on a per-column basis. I have not done anything about that here. It seems to me that if we are changing around the parameters, we'd better get some experience and be sure we are happy with the design before we set things in stone by providing user-visible knobs.
* Change hashscan.c to keep its list of active hash index scans inTom Lane2008-03-07
| | | | | | | | | | | | | TopMemoryContext, rather than scattered through executor per-query contexts. This poses no danger of memory leak since the ResourceOwner mechanism guarantees release of no-longer-needed items. It is needed because the per-query context might already be released by the time we try to clean up the hash scan list. Report by ykhuang, diagnosis by Heikki. Back-patch to 8.0, where the ResourceOwner-based cleanup was introduced. The given test case does not fail before 8.2, probably because we rearranged transaction abort processing somehow; but this coding is undoubtedly risky so I'll patch 8.0 and 8.1 anyway.
* Fix memory arrangement of tsquery after removing stop words. It causesTeodor Sigaev2008-03-07
| | | | | | | | | | | | a unused memory holes in tsquery. Per report by Richard Huxton <dev@archonet.com>. It was working well because in fact tsquery->size is not used for any kind of operation except comparing tsqueries. So, in HEAD it's enough to fix to_tsquery function, but for previous version it's needed to remove optimization in CompareTSQ to prevent requirement of renew all stored tsquery.
* Improve "bgwriter_lru_multiplier" GUC description.Bruce Momjian2008-03-06
|
* Clean up double negative, per Tom Lane.Alvaro Herrera2008-03-05
|
* Add support for dlopen on recent NetBSD/MIPS, per Rémi Zara.Alvaro Herrera2008-03-05
|
* In PrepareToInvalidateCacheTuple, don't force initialization of catalogTom Lane2008-03-05
| | | | | | | | | | caches that we don't actually need to touch. This saves some trivial number of cycles and avoids certain cases of deadlock when doing concurrent VACUUM FULL on system catalogs. Per report from Gavin Roy. Backpatch to 8.2. In earlier versions, CatalogCacheInitializeCache didn't lock the relation so there's no deadlock risk (though that certainly had plenty of risks of its own).
* When text search string is too long, in error message report actual andBruce Momjian2008-03-05
| | | | maximum number of bytes allowed.
* Fix PREPARE TRANSACTION to reject the case where the transaction has dropped aTom Lane2008-03-04
| | | | | | | temporary table; we can't support that because there's no way to clean up the source backend's internal state if the eventual COMMIT PREPARED is done by another backend. This was checked correctly in 8.1 but I broke it in 8.2 :-(. Patch by Heikki Linnakangas, original trouble report by John Smith.
* Fix another place that was assuming that a local variable declared asTom Lane2008-03-01
| | | | | | | | "struct varlena" would be at least word-aligned. Per buildfarm results from gypsy_moth. I did a little bit of trawling for other instances of this coding pattern, and didn't find any; but if we turn up any more of them I think we'd better revert the "char [4]" patch and find another way of making tuptoaster.c alignment-safe.
* Fix unportable usages of tolower(). On signed-char machines, it is necessaryTom Lane2008-03-01
| | | | | | | | | to explicitly cast the output back to char before comparing it to a char value, else we get the wrong result for high-bit-set characters. Found by Rolf Jentsch. Also, fix several places where <ctype.h> functions were being called without casting the argument to unsigned char; this is likewise unportable, but we keep making that mistake :-(. These found by buildfarm member salamander, which I will desperately miss if it ever goes belly-up.
* Disable the undocumented xmlvalidate() function, which was unintentionallyTom Lane2008-03-01
| | | | | | | | | left in the code though it was not meant to be provided. It represents a security hole because unprivileged users could use it to look at (at least the first line of) any file readable by the backend. Fortunately, this is only possible if the backend was built with XML support, so the damage is at least mitigated; and 8.3 probably hasn't propagated into any security-critical uses yet anyway. Per report from Sergey Burladyan.
* Remove long-unused and broken TCL_ARRAYS.Alvaro Herrera2008-02-29
|
* Reducing the assumed alignment of struct varlena means that the compilerTom Lane2008-02-29
| | | | | | | | | | is also licensed to put a local variable declared that way at an unaligned address. Which will not work if the variable is then manipulated with SET_VARSIZE or other macros that assume alignment. So the previous patch is not an unalloyed good, but on balance I think it's still a win, since we have very few places that do that sort of thing. Fix the one place in tuptoaster.c that does it. Per buildfarm results from gypsy_moth (I'm a bit surprised that only one machine showed a failure).
* Write the objfiles.txt rules in a way that is compatible with GNU make 3.78,Peter Eisentraut2008-02-29
| | | | and simpler, too.
* Fix several memory leaks when rescanning SRFs. Arrange for an SRF'sNeil Conway2008-02-29
| | | | | | | | | | | | | | | | | | "multi_call_ctx" to be a distinct sub-context of the EState's per-query context, and delete the multi_call_ctx as soon as the SRF finishes execution. This avoids leaking SRF memory until the end of the current query, which is particularly egregious when the SRF is scanned multiple times. This change also fixes a leak of the fields of the AttInMetadata struct in shutdown_MultiFuncCall(). Also fix a leak of the SRF result TupleDesc when rescanning a FunctionScan node. The TupleDesc is allocated in the per-query context for every call to ExecMakeTableFunctionResult(), so we should free it after calling that function. Since the SRF might choose to return a non-expendable TupleDesc, we only free the TupleDesc if it is not being reference-counted. Backpatch to 8.3 and 8.2 stable branches.
* Change expand_subsys function so that it preserves the relative order ofPeter Eisentraut2008-02-27
| | | | | the files passed as argument. This is desirable so that the dtrace rule in src/backend/Makefile works.
* If RelationBuildDesc() fails to open a critical system index, PANIC withTom Lane2008-02-27
| | | | | a relevant error message instead of just dumping core. Odd that nobody reported this before Darren Reed.
* Fixed dtrace buildPeter Eisentraut2008-02-26
| | | | found by Magne Mæhre
* Need more dependencies to get the build order right when objfiles.txtPeter Eisentraut2008-02-26
| | | | doesn't exist yet.
* We don't need to rebuild objfiles.txt every time an object file changes.Peter Eisentraut2008-02-26
| | | | | | | So only rebuild when a makefile changes (which presumably defines the file list somewhere), and only touch the file if an object changed. The touch is necessary so the parent make knows something changed and ultimately rebuilds postgres.
* Fix encode(...bytea..., 'escape') so that it converts all high-bit-set byteTom Lane2008-02-26
| | | | | | | | | | | | | | | | | values into \nnn octal escape sequences. When the database encoding is multibyte this is *necessary* to avoid generating invalidly encoded text. Even in a single-byte encoding, the old behavior seems very hazardous --- consider for example what happens if the text is transferred to another database with a different encoding. Decoding would then yield some other bytea value than what was encoded, which is surely undesirable. Per gripe from Hernan Gonzalez. Backpatch to 8.3, but not further. This is a bit of a judgment call, but I make it on these grounds: pre-8.3 we don't really have much encoding safety anyway because of the convert() function family, and we would also have much higher risk of breaking existing apps that may not be expecting this behavior. 8.3 is still new enough that we can probably get away with making this change in the function's behavior.
* Reject year zero during datetime input, except when it's a 2-digit yearTom Lane2008-02-25
| | | | | | | (then it means 2000 AD). Formerly we silently interpreted this as 1 BC, which at best is unwarranted familiarity with the implementation. It's barely possible that some app somewhere expects the old behavior, though, so we won't back-patch this into existing release branches.
* Fix datetime input to behave correctly for Feb 29 in years BC.Tom Lane2008-02-25
| | | | | | | | | | | | | | | | | | | Formerly, DecodeDate attempted to verify the day-of-the-month exactly, but it was under the misapprehension that it would know whether we were looking at a BC year or not. In reality this check can't be made until the calling function (eg DecodeDateTime) has processed all the fields. So, split the BC adjustment and validity checks out into a new function ValidateDate that is called only after processing all the fields. In passing, this patch makes DecodeTimeOnly work for BC inputs, which it never did before. (The historical veracity of all this is nonexistent, of course, but if we're going to say we support proleptic Gregorian calendar then we should do it correctly. In any case the unpatched code is broken because it could emit dates that it would then reject on re-inputting.) Per report from Bernd Helmle. Back-patch as far as 8.0; in 7.x we were not using our own calendar support and so this seems a bit too risky to put into 7.4.
* Link postgres from all object files at once, to avoid the error-pronePeter Eisentraut2008-02-25
| | | | | | | | | | | | | | SUBSYS.o step and allow for better optimization by the linker. Instead of partial linking into SUBSYS.o, the list of object files is assembled in objfiles.txt files that are expanded when the final linking is done. Because we are not yet sure how long command lines different platforms can handle, the old way of linking is still available, by defining the make variable PARTIAL_LINKING (e.g., make all PARTIAL_LINKING=1). If we determine that this is necessary for some platforms, then we will document this in a more prominent place.
* Avoid trying to print a NULL char pointer in --describe-config. On someTom Lane2008-02-23
| | | | platforms this works, but on some it crashes. Zdenek Kotala
* Change the declaration of struct varlena so that the length word isTom Lane2008-02-23
| | | | | | | | | | | | | | | represented as "char ...[4]" not "int32". Since the length word is never supposed to be accessed via this struct member anyway, this won't break any existing code that is following the rules. The advantage is that C compilers will no longer assume that a pointer to struct varlena is word-aligned, which prevents incorrect optimizations in TOAST-pointer access and perhaps other places. gcc doesn't seem to do this (at least not at -O2), but the problem is demonstrable on some other compilers. I changed struct inet as well, but didn't bother to touch a lot of other struct definitions in which it wouldn't make any difference because there were other fields forcing int alignment anyway. Hopefully none of those struct definitions are used for accessing unaligned Datums.
* Rename miscadmin.h's PG_VERSIONSTR macro to PG_BACKEND_VERSIONSTR toTom Lane2008-02-20
| | | | | make it a bit clearer what it is, and get rid of duplicate definitions in initdb and pg_ctl.
* Put a CHECK_FOR_INTERRUPTS call into the loops that try to find a unique newTom Lane2008-02-20
| | | | | | | | | | OID or new relfilenode. If the existing OIDs are sufficiently densely populated, this could take a long time (perhaps even be an infinite loop), so it seems wise to allow the system to respond to a cancel interrupt here. Per a gripe from Jacky Leng. Backpatch as far as 8.1. Older versions just fail on OID collision, instead of looping.
* Improve error messages emitted when VACUUM and ANALYZE skip a table.Alvaro Herrera2008-02-20
| | | | | Per gripe from Clodoaldo Pinto Neto on Message-ID: <a595de7a0801060326qbfc790ax2a60573043c2e2be@mail.gmail.com>
* Change error message to be able to differentiate the two cases. Per suggestionAlvaro Herrera2008-02-20
| | | | from Jaime Casanova.
* More refactoring, so that the SUBSYS.o rules are now all in one place.Peter Eisentraut2008-02-19
|
* This subdirectory has been unused, dead, and broken for 10 years.Peter Eisentraut2008-02-19
|
* Remove another target I forgot during the refactoringPeter Eisentraut2008-02-19
|
* Refactor backend makefiles to remove lots of duplicate codePeter Eisentraut2008-02-19
|
* Remove unnecessary opening of other relation in RI_FKey_keyequal_upd_pkTom Lane2008-02-18
| | | | | | | | | | | | | and RI_FKey_keyequal_upd_fk, as well as no-longer-needed calls of ri_BuildQueryKeyFull. Aside from saving a few cycles, this avoids needless deadlock risks when an update is not changing the columns that participate in an RI constraint. Per a gripe from Alexey Nalbat. Back-patch to 8.3. Earlier releases did have a need to open the other relation due to the way in which they retrieved information about the RI constraint, so this problem unfortunately can't easily be improved pre-8.3. Tom Lane and Stephan Szabo
* Observe errors in makefilePeter Eisentraut2008-02-18
|
* Add back #include <time.h> in a couple of files that seem to need itTom Lane2008-02-17
| | | | on Linux.
* Replace time_t with pg_time_t (same values, but always int64) in on-diskTom Lane2008-02-17
| | | | | | | | | | | | | | data structures and backend internal APIs. This solves problems we've seen recently with inconsistent layout of pg_control between machines that have 32-bit time_t and those that have already migrated to 64-bit time_t. Also, we can get out from under the problem that Windows' Unix-API emulation is not consistent about the width of time_t. There are a few remaining places where local time_t variables are used to hold the current or recent result of time(NULL). I didn't bother changing these since they do not affect any cross-module APIs and surely all platforms will have 64-bit time_t before overflow becomes an actual risk. time_t should be avoided for anything visible to extension modules, however.
* Allow AS to be omitted when specifying an output column name in SELECTTom Lane2008-02-15
| | | | | | (or RETURNING), but only when the output name is not any SQL keyword. This seems as close as we can get to the standard's syntax without a great deal of thrashing. Original patch by Hiroshi Saito, amended by me.
* Remove ancient restriction that LIMIT/OFFSET can't contain a sub-select.Tom Lane2008-02-15
| | | | | | | This was probably protecting some implementation limitation when it was put in, but as far as I can tell the planner and executor have no such assumption anymore; the case seems to work fine. Per a gripe from Grzegorz Jaskiewicz.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 18:53:13 +0000