if geqo_rand() returns exactly 1.0, resulting in failure due to indexing
off the end of the pool array. Also, since this is using inexact float math,
it seems wise to guard against roundoff error producing values slightly
outside the expected range. Per report from bug@zedware.org.
to just around the bare recv() call that gets a command from the client.
The former placement in PostgresMain was unsafe because the intermediate
processing layers (especially SSL) use facilities such as malloc that are
not necessarily re-entrant. Per report from counterstorm.com.
to columns of an RTE that was a function returning RECORD with a column
definition list. Apparently no one has tried to use non-default typmod
with a function returning RECORD before.
if they are two-byte multibyte characters. Same thing can be happen
if octet_length(multibyte_chars) == n where n is char(n).
Long standing bug since 7.3 days. Per report and fix from Yoshiyuki Asaba.
and VACUUM: in the interval between adding a new page to the relation
and formatting it, it was possible for VACUUM to come along and decide
it should format the page too. Though not harmful in itself, this would
cause data loss if a third transaction were able to insert tuples into
the vacuumed page before the original extender got control back.
before we check commit/abort status. Formerly this was done in some paths
but not all, with the result that a transaction might be considered
committed for some purposes before it became committed for others.
Per example found by Jan Wieck.
output area as INTERNAL not CSTRING. This is to prevent people from
calling the functions by hand. This is a permanent solution for the
back branches but I hope it is just a stopgap for HEAD.
of timetz values misbehaved in --enable-integer-datetime cases, and
EXTRACT(EPOCH) subtracted the zone instead of adding it in all cases.
Backpatch to all supported releases (except --enable-integer-datetime code
does not exist in 7.2).
was large enough to be batched and the tuples fell into a batch where
there were no inner tuples at all. Thanks to Xiaoyu Wang for finding a
test case that exposed this long-standing bug.
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.
complete ExtendCLOG() before advancing nextXid, so that if that routine
fails, the next incoming transaction will try it again. Per trouble
report from Christopher Kings-Lynne.
incorrect permissions checking, but in fact disabled most all permissions
checks for view updates. This corrects problems reported by Sergey
Yatskevich among others, at the cost of re-introducing the problem
previously reported by Tim Burgess. However, since we'd lived with that
problem for quite awhile without knowing it, we can live with it awhile
longer until a proper fix can be made in 7.5.
This should prevent some obscure cases of 'variable not in subplan target
lists', although actual failures have only been reported against 7.4 in
which the bug is much easier to trigger.
rule split the query into one INSERT and one UPDATE where the UPDATE
then hit's the just created row without modifying the key fields again.
In this special case, the new key slipped in totally unchecked.
Jan
subquery that didn't previously have one. We have traditionally made
the caller of ResolveNew responsible for updating the hasSubLinks flag
of the outermost query, but this fails to account for hasSubLinks in
subqueries. Fix ResolveNew to handle this. We might later want to
change the calling convention of ResolveNew so that it can fix the
outer query too, simplifying callers. But I went with the localized
fix for now. Per bug report from J Smith, 20-Oct-03.
in the schema search path. Otherwise pg_dump doesn't correctly dump
scenarios where a custom opclass is created in 'public' and then used
by indexes in other schemas.
