Re: Hot standby, misc issues

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, misc issues
Date: 2009-12-05 20:56:56
Message-ID: 4B1AC918.90807@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-12-05 21:07:01 Re: Reading recovery.conf earlier
Previous Message Tom Lane 2009-12-05 20:43:06 Re: Reading recovery.conf earlier