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.
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.
The existing code didn't correctly allocate data arrays, and it
failed to loop when a stream didn't provide the full amount of
data requested of it.
Reported by Jan de Visser.
ability to update LOBs is unimplemented. The 1.5 JDK's CachedRowSet
implementation calls this method regardless of whether large objects
are used or not.
relationships. Resulting columns from getImportedExportedKeys should
be FKTABLE_SCHEM and PKTABLE_SCHEM, not _SCHEMA.
Per report from jeff@bonevich.com.
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.
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.
