- 12 7月, 2008 1 次提交
-
-
由 Tom Lane 提交于
-
- 11 7月, 2008 4 次提交
-
-
由 Peter Eisentraut 提交于
Document return type of cast functions. Also change documentation to prefer the term "binary coercible" in its present sense instead of the previous term "binary compatible".
-
由 Alvaro Herrera 提交于
CopySnapshot, per Neil Conway. Also add a comment about the assumption in GetSnapshotData that the argument is statically allocated. Also, fix some more typos in comments in snapmgr.c.
-
由 Neil Conway 提交于
alphabetically.
-
由 Tom Lane 提交于
wal_segment_size to make those configuration parameters available to clients, in the same way that block_size was previously exposed. Bernd Helmle, with comments from Abhijit Menon-Sen and some further tweaking by me.
-
- 10 7月, 2008 2 次提交
-
-
由 Tom Lane 提交于
the current query level that aren't in fact output parameters of the current initPlans. (This means, for example, output parameters of regular subplans.) To make this work correctly for output parameters coming from sibling initplans requires rejiggering the API of SS_finalize_plan just a bit: we need the siblings to be visible to it, rather than hidden as SS_make_initplan_from_plan had been doing. This is really part of my response to bug #4290, but I concluded this part probably shouldn't be back-patched, since all that it's doing is to make a debugging cross-check tighter.
-
由 Tom Lane 提交于
bug #4290. The fundamental bug is that masking extParam by outer_params, as finalize_plan had been doing, caused us to lose the information that an initPlan depended on the output of a sibling initPlan. On reflection the best thing to do seemed to be not to try to adjust outer_params for this case but get rid of it entirely. The only thing it was really doing for us was to filter out param IDs associated with SubPlan nodes, and that can be done (with greater accuracy) while processing individual SubPlan nodes in finalize_primnode. This approach was vindicated by the discovery that the masking method was hiding a second bug: SS_finalize_plan failed to remove extParam bits for initPlan output params that were referenced in the main plan tree (it only got rid of those referenced by other initPlans). It's not clear that this caused any real problems, given the limited use of extParam by the executor, but it's certainly not what was intended. I originally thought that there was also a problem with needing to include indirect dependencies on external params in initPlans' param sets, but it turns out that the executor handles this correctly so long as the depended-on initPlan is earlier in the initPlans list than the one using its output. That seems a bit of a fragile assumption, but it is true at the moment, so I just documented it in some code comments rather than making what would be rather invasive changes to remove the assumption. Back-patch to 8.1. Previous versions don't have the case of initPlans referring to other initPlans' outputs, so while the existing logic is still questionable for them, there are not any known bugs to be fixed. So I'll refrain from changing them for now.
-
- 09 7月, 2008 2 次提交
-
-
由 Tom Lane 提交于
1024 to improve performance when sending large elog messages. Also add a comment about why we use that number. Since this represents an externally visible behavior change, and might possibly result in portability issues, it seems best not to back-patch it.
-
由 Tom Lane 提交于
log message at newlines cost O(N^2) for very long messages with few or no newlines. For messages in the megabyte range this became the dominant cost. Per gripe from Achilleas Mantzios. Patch all the way back, since this is a safe change with no portability risks. I am also thinking of increasing PG_SYSLOG_LIMIT, but that should be done separately.
-
- 08 7月, 2008 4 次提交
-
-
由 Neil Conway 提交于
-
由 Bruce Momjian 提交于
/* This is PGC_SIGHUP so all backends have the same value. */
-
由 Tom Lane 提交于
results always contribute two groups, regardless of the expression contents. This is very substantially more accurate than the regular heuristic for certain boolean tests like "col IS NULL". Per gripe from Sam Mason. Back-patch to all supported releases, since the behavior of estimate_num_groups() hasn't changed all that much since 7.4.
-
由 Tom Lane 提交于
the timezone argument as a timezone abbreviation, and only try it as a full timezone name if that fails. The zic database has four zones (CET, EET, MET, WET) that are full daylight-savings zones and yet have names that are the same as their abbreviations for standard time, resulting in ambiguity. In the timestamp input functions we resolve the ambiguity by preferring the abbreviation, and AT TIME ZONE should work the same way. (No functionality is lost because the zic database also has other names for these zones, eg Europe/Zurich.) Per gripe from Jaromir Talir. Backpatch to 8.1. Older releases did not have the issue because AT TIME ZONE only accepted abbreviations not zone names. (Thus, this patch also arguably fixes a compatibility botch introduced at 8.1: in ambiguous cases we now behave the same as 8.0 did.)
-
- 07 7月, 2008 1 次提交
-
-
由 Tom Lane 提交于
variable that has units. Per report from Stefan Kaltenbrunner. Backport to 8.2. I also backported my patch of 2007-06-21 that prevented comparable overflows on the input side, since that now seems to have enough field track record to be back-patched safely. That patch included addition of hints listing the available unit names, which I did not bother to strip out of it --- this will make a little more work for the translators, but they can copy the translation from 8.3, and anyway an untranslated hint is better than no hint.
-
- 04 7月, 2008 4 次提交
-
-
由 Teodor Sigaev 提交于
-
由 Magnus Hagander 提交于
* Don't cut off the prefix. With this fix, it's again readable. * Properly store it in the Global namespace as intended.
-
由 Tom Lane 提交于
known to the SQL parser. Dave Page
-
由 Peter Eisentraut 提交于
scripts, to allow running the test successfully with another database name.
-
- 03 7月, 2008 5 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
Guillaume Lelarge, with some additional fixes by me.
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
fix by Kris Jurka.
-
- 02 7月, 2008 1 次提交
-
-
由 Tom Lane 提交于
-
- 01 7月, 2008 8 次提交
-
-
由 Heikki Linnakangas 提交于
output for CREATE FUNCTION. This makes it easier to read especially if the function body is long. Original idea and patch by Greg Sabino Mullane, though this is a stripped down version of that.
-
由 Heikki Linnakangas 提交于
of different types than the underlying column. The capability isn't yet used for anything, but will be required by upcoming patch to analyze tsvector columns. Jan Urbanski
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
one for client-side, restoring the previous behaviour with different sort order for the 'log' level. Also, remove redundant list of available options, since the enum code will output it automatically.
-
由 Tom Lane 提交于
timezone setting in the current year and for 100 years back, rather than always examining years 1904-2004. The original coding would have problems distinguishing zones whose behavior diverged only after 2004; which is a situation we will surely face sometime, if it's not out there already. In passing, also prevent selection of the dummy "Factory" timezone, even if that's exactly what the system is using. Reporting time as GMT seems better than that.
-
由 Tom Lane 提交于
backend. If so, send a LOG message to the postmaster log, and if the table is beyond the vacuum-for-wraparound horizon, forcibly drop it. Per recent discussions. Perhaps we ought to back-patch this, but it probably needs to age a bit in HEAD first.
-
由 Bruce Momjian 提交于
observation by David Fetter.
-
由 Bruce Momjian 提交于
values as postgresql.conf.
-
- 30 6月, 2008 2 次提交
-
-
由 Heikki Linnakangas 提交于
As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
-
由 Tom Lane 提交于
space is tracked via GetMemoryChunkSpace, there's really no advantage to duplicating datumCopy's innards here. This is one bit of my toast indirection patch that should go in anyway.
-
- 29 6月, 2008 1 次提交
-
-
由 Tom Lane 提交于
it ought to conform to the rest of palloc.h in using Size for sizes.
-
- 28 6月, 2008 2 次提交
-
-
由 Tom Lane 提交于
of any lower outer join, even if it also references the non-nullable side and so could not get pushed below the outer join anyway. We need this in case the clause is an OR clause: if it doesn't get marked outerjoin_delayed, create_or_index_quals() could pull an indexable restriction for the nullable side out of it, leading to wrong results as demonstrated by today's bug report from toruvinn. (See added regression test case for an example.) In principle this has been wrong for quite a while. In practice I don't think any branch before 8.3 can really show the failure, because create_or_index_quals() will only pull out indexable conditions, and before 8.3 those were always strict. So though we might have improperly generated null-extended rows in the outer join, they'd get discarded from the result anyway. The gating factor that makes the failure visible is that 8.3 considers "col IS NULL" to be indexable. Hence I'm not going to risk back-patching further than 8.3.
-
由 Magnus Hagander 提交于
Hiroshi Saito
-
- 27 6月, 2008 3 次提交
-
-
由 Tom Lane 提交于
taking the maximum of any child rel's width, we should weight the widths proportionally to the number of rows expected from each child. In hindsight this is obviously correct because row width is really a proxy for the total physical size of the relation. Per discussion with Scott Carey (bug #4264).
-
由 Bruce Momjian 提交于
wasn't working.
-
由 Teodor Sigaev 提交于
and non-C locale. Fix is just to use correct source's length for char2wchar call.
-