Simon Riggs wrote:
> On Fri, 2009-12-04 at 10:23 +0200, Heikki Linnakangas wrote:
>>> @Heikki: Why is error checking in KnownAssignedXidsRemove() #ifdef'd
>> out??
>>
>> It's explained in the comment:
>> /* XXX: This can still happen: If a transaction with a subtransaction
>> * that haven't been reported yet aborts, and no WAL records have been
>> * written using the subxid, the abort record will contain that subxid
>> * and we haven't seen it before.
>> */
>
> Just realised that this occurs again because the call to
> RecordKnownAssignedTransactionIds() was removed from
> xact_commit_abort().
>
> I'm guessing you didn't like the call in that place for some reason,
> since I smile while I remember it has been removed twice(!) even though
> I put "do not remove" comments on it to describe this corner case.
>
> Not going to put it back a third time.
:-). Well, it does seem pointless to add entries to the hash table, just
to remove them at the very next line. But you're right, we should still
advance latestObservedXid, and if we do that, we need to memorize any
not-yet-seen XIDs in the known-assigned xids array. So that
RecordKnownAssignedTransactionIds() call needs to be put back.
BTW, if you want to resurrect the check in KnownAssignedXidsRemove(),
you also need to not complain before you reach the running-xacts record
and open up for read-only connections.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com