| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
| |
Not sure why this isn't causing serious problems in some simple tests,
but it definitely isn't going to do anything desirable...
|
|
|
|
|
| |
branch. I wasn't excited about doing this when the first report came in,
but now that we have two of 'em, I suppose it had better get fixed.
|
|
|
|
|
| |
made in passing for 8.0, but now that we have a bug report showing it's
needed, we should put it into 7.4 branch.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
value of 'start' could be past the end of the page, if the page was
split by some concurrent inserting process since we visited it. In
this situation the code could look at bogus entries and possibly find
a match (since after all those entries still contain what they had
before the split). This would lead to 'specified item offset is too large'
followed by 'PANIC: failed to add item to the page', as reported by Joe
Conway for scenarios involving heavy concurrent insertion activity.
|
| |
|
| |
|
|
|
|
| |
that refers to a now-deleted userid. Per gripe from Chris Ochs.
|
|
|
|
|
|
| |
for transaction commits that occurred just before the checkpoint. This is
an EXTREMELY serious bug --- kudos to Satoshi Okada for creating a
reproducible test case to prove its existence.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
force relcache rebuild for the other table as well as the column's
own table. Otherwise, already-cached foreign key triggers will stop
working. Per example from Alexander Pravking.
|
|
|
|
|
|
|
| |
This is required by SQL spec to avoid failures in cases like
SELECT sum(win)/sum(lose) FROM ... GROUP BY ... HAVING sum(lose) > 0;
AFAICT we have gotten this wrong since day one. Kudos to Holger Jakobs
for being the first to notice.
|
|
|
|
| |
et al.
|
| |
|
| |
|
|
|
|
| |
is actually needed. Backport of Oliver Elphick's recent patch.
|
| |
|
| |
|
| |
|
|
|
|
| |
array.
|
|
|
|
|
|
|
|
|
|
| |
issue in timestamp conversion that we hacked around for so long by
ignoring the seconds field from localtime(). It's simple: you have
to watch out for platform-specific roundoff error when reducing a
possibly-fractional timestamp to integral time_t form. In particular
we should subtract off the already-determined fractional fsec field.
This should be enough to get an exact answer with int64 timestamps;
with float timestamps, throw in a rint() call just to be sure.
|
| |
|
|
|
|
|
| |
an overlength token. Printout was always garbage and could dump core
entirely :-(. Per report from Martin Pitt.
|
|
|
|
|
|
| |
to ExclusiveLock. This still serializes the operations of this module,
but doesn't conflict with concurrent ANALYZE operations. Per trouble
report from Philip Warner a few weeks ago.
|
|
|
|
|
|
| |
by Ken Ashcraft's report. I think there is no actual bug here since if
the int32 value does wrap a little bit, palloc will still reject it.
Still it's better that the code be obviously correct.
|
|
|
|
| |
infinite-loop problems if a bogus data length is passed.
|
| |
|
|
|
|
|
| |
Didier Moens. Bug is new in 7.4, and was caused by not updating everyplace
I should've when replacing locParam markers by allParam.
|
|
|
|
|
| |
by the SQL spec and by our parser. Thanks to Jonathan Scott for finding
this longstanding error.
|
|
|
|
| |
time_t; on some platforms they are not the same width. Per Manfred Koizar.
|
| |
|
|
|
|
|
|
|
|
| |
are sought first as local FROM columns, then as local SELECT-list aliases,
and finally as outer FROM columns; the former behavior made outer FROM
columns take precedence over aliases. This does not change spec
conformance because SQL99 allows only the first case anyway, and it seems
more useful and self-consistent. Per gripe from Dennis Bjorklund 2004-04-05.
|
|
|
|
| |
Per example from Jiang Wei.
|
|
|
|
|
|
|
| |
That particular corner case is not exactly compelling, but given 7.4's
ability to discard redundant join clauses, it is possible for the situation
to arise from queries that are not so obviously silly. Per bug report
of 6-Apr-04.
|
|
|
|
|
| |
equal to the desired restart value (must clear is_called, did not).
Per bug report #1127 from Piotr Konieczny.
|
|
|
|
|
|
|
| |
7.4 rewrite for hashed aggregate support. If the transition data type
is pass-by-reference, the transValue must be pfreed when starting a new
group boundary, else we have a one-value-per-group leakage. Thanks to
Rae Steining for providing a reproducible test case.
|
| |
|
|
|
|
|
| |
simplistic; it recognized SELECT * FROM but not SELECT * FROM LIMIT.
Per bug report from Jeff Bohmer.
|
|
|
|
|
|
|
|
|
|
| |
equivalent sort expressions to use was broken: you can't just look
at the relation membership, you have to actually grovel over the
individual Vars in each expression. I think this did work when it
was written, but it was broken by subsequent optimizations that made
join relations not propagate every single input variable upward.
Must find the Var that got propagated, not choose one at random.
Per bug report from Daniel O'Neill.
|
|
|
|
|
| |
indexTotalCost. I think this may not make any real difference in 7.4,
but it definitely is a problem with CVS tip's new equation.
|
|
|
|
|
| |
is generating, to avoid problems when subselects are involved. Per
report from Damon Hart.
|
|
|
|
|
|
|
|
|
|
| |
and FreeDir routines modeled on the existing AllocateFile/FreeFile.
Like the latter, these routines will avoid failing on EMFILE/ENFILE
conditions whenever possible, and will prevent leakage of directory
descriptors if an elog() occurs while one is open.
Also, reduce PANIC to ERROR in MoveOfflineLogs() --- this is not
critical code and there is no reason to force a DB restart on failure.
All per recent trouble report from Olivier Hubaut.
|
|
|
|
|
|
| |
number of openable files and the number already opened. This eliminates
depending on sysconf(_SC_OPEN_MAX), and allows much saner behavior on
platforms where open-file slots are used up by semaphores.
|
|
|
|
|
|
| |
problem, per previous discussion. Make some additional changes to
centralize the knowledge of just how identifier downcasing is done,
in hopes of simplifying any future tweaking in this area.
|
|
|
|
|
|
| |
Nov 2002: when constant-expression simplification removes all the
aggregate function calls from a query, that doesn't mean we can act as
though there never were any aggregates. Per bug report from Gabor Szucs.
|
| |
|
|
|
|
| |
(Same patch committed to HEAD but I fat-fingered the commit message...)
|
|
|
|
| |
Not sure how this mistake evaded detection for so long.
|