| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Per report from César Miguel Oliveira Alves.
|
| |
|
|
| |
Simon Riggs
|
| |
|
|
|
|
| |
protection.
Simon Riggs
|
| | |
|
| |
|
|
|
|
| |
it. This is a stripped down version of the patch applied to HEAD.
Per report from Tom Lane based on buildfarm evidence.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the alreadyDeleted list has to be passed down through
deleteDependentObjects(), else objects that are deleted via auto/internal
dependencies don't get reported back up to performMultipleDeletions().
Depending on the visitation order, this could cause the code to try to delete
an already-deleted object, leading to strange errors in DROP OWNED (typically
"cache lookup failed for relation NNNNN" or similar). Per bug #4289.
Patch for back branches only. This code has recently been rewritten in HEAD,
and doesn't have this particular bug anymore.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
* Don't cut off the prefix. With this fix, it's again readable.
* Properly store it in the Global namespace as intended.
|
| |
|
|
| |
fix by Kris Jurka.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Hiroshi Saito
|
| |
|
|
| |
arguments on restart. Patch to releases 8.0 - 8.3.X.
|
| |
|
|
| |
parsing. Per bug #4253 from Giorgio Valoti.
|
| |
|
|
|
|
|
|
|
|
|
| |
by installing an error context subroutine that will provide the file name
and line number for all errors detected while reading a config file.
Some of the reader routines were already doing that in an ad-hoc way for
errors detected directly in the reader, but it didn't help for problems
detected in subroutines, such as encoding violations.
Back-patch to 8.3 because 8.3 is where people will be trying to debug
configuration files.
|
| |
|
|
|
|
|
|
|
| |
that it depends on for replan-forcing purposes. We need to consider plain OID
constants too, because eval_const_expressions folds a RelabelType atop a Const
to just a Const. This change could result in OID values that aren't really
for tables getting added to the dependency list, but the worst-case
consequence would be occasional useless replans. Per report from Gabriele
Messineo.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Directly reading interp->result is deprecated in Tcl 8.0 and later;
you're supposed to use Tcl_GetStringResult. This code finally broke with
Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even
though it preserves the logical state of the result. (There's arguably a
Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a
just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as
a bug.)
2. We were being sloppy about the encoding of the result: some places would
push database-encoding data into the Tcl result, which should not happen,
and we were assuming that any error result coming back from Tcl was in the
database encoding, which is not a good assumption.
3. There were a lot of calls of Tcl_SetResult that uselessly specified
TCL_VOLATILE for constant strings. This is only a minor performance issue,
but I fixed it in passing since I had to look at all the calls anyway.
#2 is a live bug regardless of which Tcl version you are interested in,
so back-patch even to branches that are unlikely to be used with Tcl 8.5.
I went back as far as 8.0, which is as far as the patch applied easily;
7.4 was using a different error processing scheme that has got its own
problems :-(
|
| |
|
|
|
|
|
|
|
| |
the problem happened in. These are all supposedly can't-happen cases, but
when they do happen it's useful to know where.
Back-patch to 8.3, but not further because the patch doesn't apply cleanly
further back. Given the lack of response to my proposal of this, there
doesn't seem to be enough interest to justify much back-porting effort.
|
| |
|
|
|
|
|
| |
CacheInvalidateRelcache() crashes if called in WAL recovery, because the
invalidation infrastructure hasn't been initialized yet.
Back-patch to 8.2, where the bug was introduced.
|
| |
|
|
| |
replacing the tedious and error-prone manual process we've been using.
|
| |
|
|
| |
recently snuck into cash.c. Per report from Edmundo Robles Lopez.
|
| |
|
|
|
| |
running on a 64-bit platform ... strtol() will happily return 64-bit
output in that case. Per bug #4231 from Geoff Tolley.
|
| | |
|
| |
|
|
|
|
|
| |
patches that dealt with object ownership. It wasn't updating pg_shdepend
nor adjusting the aggregate's ACL. In 8.2 and up, fix this permanently
by making it use AlterFunctionOwner_oid. In 8.1, the function code wasn't
factored that way, so just copy and paste.
|
| |
|
|
|
|
|
|
|
|
| |
This is needed because :: casting binds more tightly than minus, so for
example -1::integer is not the same as (-1)::integer, and there are cases
where the difference is important. In particular this caused a failure
in SELECT DISTINCT ... ORDER BY ... where expressions that should have
matched were seen as different by the parser; but I suspect that there
could be other cases where failure to parenthesize leads to subtler
semantic differences in reloaded rules. Per report from Alexandr Popov.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
doesn't work, and the real reason why not is it's unclear where the path
is relative to (initdb's CWD, or the data directory?). We could make an
arbitrary decision, but it seems best to make the user be unambiguous.
Per gripe from Devrim.
|
| |
|
|
| |
Morocco, Iraq, Choibalsan, Pakistan, Syria, Cuba, Argentina/San_Luis).
|
| |
|
|
|
|
| |
rather than "\x09". Before 8.3 we just printed tabs as-is, leading to poor
formatting of subsequent columns, but consensus is that "\x09" is not an
improvement over that. Back-patch of fix that's already in HEAD.
|
| |
|
|
|
|
|
|
| |
memory if the compressed data is corrupt.
Backpatch as far as 8.2. The issue exists in older branches too, but given
the lack of field reports, it's not clear it's worth any additional effort
to adapt the patch to the slightly different code in older branches.
|
| |
|
|
|
|
|
|
|
|
| |
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the full environment.
Fixes crash with translated error messages per bugs 4180
and 4196.
Tom Lane
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
called before, not after, calling the assign_hook if any. This is because
push_old_value might fail (due to palloc out-of-memory), and in that case
there would be no stack entry to tell transaction abort to undo the GUC
assignment. Of course the actual assignment to the GUC variable hasn't
happened yet --- but the assign_hook might have altered subsidiary state.
Without a stack entry we won't call it again to make it undo such actions.
So this is necessary to make the world safe for assign_hooks with side
effects. Per a discussion a couple weeks ago with Magnus.
Back-patch to 8.0. 7.x did not have the problem because it did not have
allocatable stacks of GUC values.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cases. Recent buildfarm experience shows that it is sometimes possible
to execute several SQL commands in less time than the granularity of
Windows' not-very-high-resolution gettimeofday(), leading to a failure
because the tests expect the value of now() to change and it doesn't.
Also, it was recognized some time ago that the same area of the tests
could fail if local midnight passes between the insertion and the checking
of the values for 'yesterday', 'tomorrow', etc. Clean all this up per
ideas from myself and Greg Stark.
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to go beoynd 10MB, as demonstrated by Gavin Sharry's example of dropping a
schema with ~25000 objects. The really bogus thing about the limit was that
it was enforced when a state file file was read in, not when it was written,
so you would end up with a prepared transaction that you can't commit or
abort, and the only recourse was to shut down the server and remove the file
by hand.
Raise the limit to MaxAllocSize, and enforce it also when a state file is
written. We could've removed the limit altogether, but reading in a file
larger than MaxAllocSize would fail anyway because we read it into a
palloc'd buffer.
Backpatch down to 8.1, where 2PC and this issue was introduced.
|
| |
|
|
|
| |
example from Rod Taylor. On reflection the correct test here is for any
polymorphic type, not specifically ANYARRAY as in the original coding.
|
| |
|
|
|
| |
CoerceViaIO nodes. This improves the ability of the planner to deal with
cases where the node input is a constant. Per bug #4170.
|
| |
|
|
|
|
|
| |
crashes on certain platforms. In particular, the MSVC runtime is known
to do this.
Fixes bug #4162, reported and diagnosed by Javier Pimas
|
| |
|
|
| |
Do not close files that weren't opened.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
varoattno along with varattno. This resulted in having Vars that were not
seen as equal(), causing inheritance of the "same" constraint from different
parent relations to fail. An example is
create table pp1 (f1 int check (f1>0));
create table cc1 (f2 text, f3 int) inherits (pp1);
create table cc2(f4 float) inherits(pp1,cc1);
Backpatch as far as 7.4. (The test case still fails in 7.4, for reasons
that I don't feel like investigating at the moment.)
This is a backpatch commit only. The fix will be applied in HEAD as part
of the upcoming pg_constraint patch.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
parameter. This fixes bug 4137 reported by Wojciech Strzalka, where a WAL
file is deleted too early when starting the recovery of a warm standby server.
Also add a sanity check in pg_standby so that it will refuse to delete anything
earlier than the file being restored, and improve the debug message in case
nothing is deleted.
Simon Riggs. Backpatch to 8.3, which is where %r was introduced.
|
| |
|
|
|
|
| |
standalone msvc build of libpq.
Hiroshi Saito
|
