Andres Freund <and...@2ndquadrant.com> writes:
> On 2014-01-21 19:45:19 -0500, Tom Lane wrote:
>> I don't think that's a comparable case. Incomplete actions are actions
>> to be taken immediately, and which the replayer then has to complete
>> somehow if it doesn't find the rest of the action in the WAL sequence.
>> The only thing to be done with the records I'm proposing is to remember
>> their contents (in some fashion) until it's time to apply them. If you
>> hit end of WAL you don't really have to do anything.
> Would that work for the promotion case as well? Afair there's the
> assumption that everything >= TransactionXmin can be looked up in
> pg_subtrans or in the procarray - which afaics wouldn't be the case with
> your scheme? And TransactionXmin could very well be below such an
> "incomplete commit"'s xids afaics.
Uh, what? The behavior I'm talking about is *exactly the same*
as what happens now. The only change is that the data sent to the
WAL file is laid out a bit differently, and the replay logic has
to work harder to reassemble it before it can apply the commit or
abort action. If anything outside replay can detect a difference
at all, that would be a bug.
Once again: the replayer is not supposed to act immediately on the
subsidiary records. It's just supposed to remember their contents
so it can reattach them to the eventual commit or abort record,
and then do what it does today to replay the commit or abort.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
