– TransferPredicateLocksToNewTarget should initialize a new lock
entry’s commitSeqNo to that of the old one being transferred, or
take the minimum commitSeqNo if it is merging two lock entries.
Also, CreatePredicateLock should initialize commitSeqNo for to
InvalidSerCommitSeqNo instead of to 0. (I don’t think using 0 would
actually affect anything, but we should be consistent.) I also added
a couple of assertions I used to track this down: a lock’s
commitSeqNo should never be zero, and it should be
InvalidSerCommitSeqNo if and only if the lock is not held by
OldCommittedSxact. Dan Ports, to fix leak of predicate locks
reported by YAMAMOTO Takashi.http://git.postgresql.org/pg/commitdiff/dad1f4638235e5ff5696b948b88ba24cd99b415e
– Fix the size of predicate lock manager’s shared memory hash tables
at creation. This way they don’t compete with the regular lock
manager for the slack shared memory, making the behavior more
predictable.http://git.postgresql.org/pg/commitdiff/7c797e7194d969f974abf579cacf30ffdccdbb95

– Revert the patch to check if we’ve reached end-of-backup also when
doing crash recovery, and throw an error if not. hubert depesz
lubaczewski pointed out that that situation also happens in the
crash recovery following a system crash that happens during an
online backup. We might want to do something smarter in 9.1, like
put the check back for backups taken with pg_basebackup, but that’s
for another patch.http://git.postgresql.org/pg/commitdiff/54685b1c2b356b4b9c0938f6b8dcc52e173c0400

– On HP/UX, the structs used by ioctl(SIOCGLIFCONF) are named
differently than on other platforms, and only IPv6 addresses are
returned. Because of those two issues, fall back to
ioctl(SIOCGIFCONF) on HP/UX, so that it at least compiles and finds
IPv4 addresses. This function is currently only used for
interpreting samehost/samenet in pg_hba.conf, which isn’t that
critical.http://git.postgresql.org/pg/commitdiff/40e64017f3a4f1f7547dcbc62c2dcf80511ff842

– Reduce the initial size of local lock hash to 16 entries. The hash
table is seq scanned at transaction end, to release all locks, and
making the hash table larger than necessary makes that slower. With
very simple queries, that overhead can amount to a few percent of
the total CPU time used. At the moment, backend startup needs 6
locks, and a simple query with one table and index needs 3 locks. 16
is enough for even quite complicated transactions, and it will grow
automatically if it fills up.http://git.postgresql.org/pg/commitdiff/4c37c1e3b2a7ba7b5519e5e366720e7444878a78

– Fix RI_Initial_Check to use a COLLATE clause when needed in its
query. If the referencing and referenced columns have different
collations, the parser will be unable to resolve which collation to
use unless it’s helped out in this way. The effects are sometimes
masked, if we end up using a non-collation-sensitive plan; but if we
do use a mergejoin we’ll see a failure, as recently noted by Robert
Haas. The SQL spec states that the referenced column’s collation
should be used to resolve RI checks, so that’s what we do. Note
however that we currently don’t append a COLLATE clause when writing
a query that examines only the referencing column. If we ever
support collations that have varying notions of equality, that will
have to be changed. For the moment, though, it’s preferable to
leave it off so that we can use a normal index on the referencing
column.http://git.postgresql.org/pg/commitdiff/921b993677e165607029a52e7f866bbd112345a5

– Be more wary of missing statistics in eqjoinsel_semi(). In
particular, if we don’t have real ndistinct estimates for both
sides, fall back to assuming that half of the left-hand rows have
join partners. This is what was done in 8.2 and 8.3 (cf
nulltestsel() in those versions). It’s pretty stupid but it won’t
lead us to think that an antijoin produces no rows out, as seen in
recent example from Uwe Schroeder.http://git.postgresql.org/pg/commitdiff/3f5d2fe3029b181fe773a02f1d4b34624c357634

– Pass collations to functions in FunctionCallInfoData, not FmgrInfo.
Since collation is effectively an argument, not a property of the
function, FmgrInfo is really the wrong place for it; and this
becomes critical in cases where a cached FmgrInfo is used for
varying purposes that might need different collation settings. Fix
by passing it in FunctionCallInfoData instead. In particular this
allows a clean fix for bug #5970 (record_cmp not working). This
requires touching a bit more code than the original method, but
nobody ever thought that collations would not be an invasive
patch…http://git.postgresql.org/pg/commitdiff/d64713df7e5996ab3ab337b5e0901cf2c53773f9

– Ensure mark_dummy_rel doesn’t create dangling pointers in
RelOptInfos. When we are doing GEQO join planning, the current
memory context is a short-lived context that will be reset at the
end of geqo_eval(). However, the RelOptInfos for base relations are
set up before that and then re-used across many GEQO cycles. Hence,
any code that modifies a baserel during join planning has to be
careful not to put pointers to the short-lived context into the
baserel struct. mark_dummy_rel got this wrong, leading to
easy-to-reproduce-once-you-know-how crashes in 8.4, as reported
off-list by Leo Carson of SDSC. Some improvements made in 9.0 make
it difficult to demonstrate the crash in 9.0 or HEAD; but there’s no
doubt that there’s still a risk factor here, so patch all branches
that have the function. (Note: 8.3 has a similar function, but it’s
only applied to joinrels and thus is not a hazard.)http://git.postgresql.org/pg/commitdiff/eca75a12a27d28b972fc269c1c8813cd8eb15441

– Guard against incoming rowcount estimate of NaN in cost_mergejoin().
Although rowcount estimates really ought not be NaN, a bug elsewhere
could perhaps result in that, and that would cause Assert failure in
cost_mergejoin, which I believe to be the explanation for bug #5977
from Anton Kuznetsov. Seems like a good idea to expend a couple
more cycles to prevent that, even though the real bug is elsewhere.
Not back-patching, though, because we don’t encourage running
production systems with Asserts on.http://git.postgresql.org/pg/commitdiff/72826fb362c4aada6d2431df0b706df448806c02

– Prevent incorrect updates of pg_index while reindexing pg_index
itself. The places that attempt to change pg_index.indcheckxmin
during a reindexing operation cannot be executed safely if pg_index
itself is the subject of the operation. This is the explanation for
a couple of recent reports of VACUUM FULL failing with
ERROR: duplicate key value violates unique constraint “pg_index_indexrelid_index”
DETAIL: Key (indexrelid)=(2678) already exists.
However, there isn’t any real need to update indcheckxmin in such a
situation, if we assume that pg_index can never contain a truly
broken HOT chain. This assumption holds if new indexes are never
created on it during concurrent operations, which is something we
don’t consider safe for any system catalog, not just pg_index.
Accordingly, modify the code to not manipulate indcheckxmin when
reindexing any system catalog. Back-patch to 8.3, where HOT was
introduced. The known failure scenarios involve 9.0-style VACUUM
FULL, so there might not be any real risk before 9.0, but let’s not
assume that.http://git.postgresql.org/pg/commitdiff/4b6106ccfea21e86943f881edcf3cfc03661a415

– Clean up collation processing in prepunion.c. This area was a few
bricks shy of a load, and badly under-commented too. We have to
ensure that the generated targetlist entries for a set-operation
node expose the correct collation for each entry, since higher-level
processing expects the tlist to reflect the true ordering of the
plan’s output. This hackery wouldn’t be necessary if
SortGroupClause carried collation info … but making it do so would
inject more pain in the parser than would be saved here. Still, we
might want to rethink that sometime.http://git.postgresql.org/pg/commitdiff/121f49a00e432ee9cfad7270d99504350cd1015f

– foreach() and list_delete() don’t mix. Fix crash when releasing
duplicate entries in the encoding conversion cache list, caused by
releasing the current entry of the list being chased by foreach().
We have a standard idiom for handling such cases, but this loop
wasn’t using it. This got broken in my recent rewrite of GUC assign
hooks. Not sure how I missed this when testing the modified code,
but I did. Per report from Peter.http://git.postgresql.org/pg/commitdiff/88dc6fa7a164c306d8a1295769edb818d8520a3f

– Fix assorted infelicities in collation handling in psql’s
describe.c. In \d, be more careful to print collation only if it’s
not the default for the column’s data type. Avoid assuming that the
name “default” is magic. Fix \d on a composite type so that it will
print per-column collations. It’s no longer the case that a
composite type cannot have modifiers. (In consequence, the expected
outputs for composite-type regression tests change.) Fix \dD so that
it will print collation for a domain, again only if it’s not the
same as the base type’s collation.http://git.postgresql.org/pg/commitdiff/c29abc8b6f5334ac2f7046a33b233776ead12395

– Fix toast table creation. Instead of using slightly-too-clever
heuristics to decide when we must create a TOAST table, just check
whether one is needed every time the table is altered. Checking
whether a toast table is needed is cheap enough that we needn’t
worry about doing it on every ALTER TABLE command, and the previous
coding is apparently prone to accidental breakage: commit
04e17bae50a73af524731fa11210d5c3f7d8e1f9 broken ALTER TABLE .. SET
STORAGE, which moved some actions from AT_PASS_COL_ATTRS to
AT_PASS_MISC, and commit 6c5723998594dffa5d47c3cf8c96ccf89c033aae
broke ALTER TABLE .. ADD COLUMN by changing the way that adding
columns recurses into child tables. Noah Misch, with one comment
change by mehttp://git.postgresql.org/pg/commitdiff/39a68e5c6ca7b41b889e773ca58535324af69630