|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Postgres hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: pgsql: Avoid duplicate XIDs at recovery when building initial snapshot|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2018-10-22 12:03:26 +0900, Michael Paquier wrote:
> (moving to -hackers)
> On Sun, Oct 14, 2018 at 10:42:40AM -0700, Andres Freund wrote:
> > I'm unhappy this approach was taken over objections. Without a real
> > warning.
> Oops, that was not clear to me. Sorry about that! I did not see you
> objecting again after the last arguments I raised. The end of PREPARE
> TRANSACTION is designed like that since it has been introduced, so
> changing the way the dummy GXACT is inserted before the main one is
> cleared from its XID does not sound wise to me. The current design is
> also present for a couple of reasons, please see this thread:
> This has resulted in e26b0abd.
None of them explains why having "corrupt" WAL that's later fixed up is
a good idea.
> Among the things I thought are:
> - Clearing the XID at the same time the dummy entry is added, which
> actually means to hold on ProcArrayLock longer while doing more at the
> end of prepare. I actually don't think you can do that cleanly without
> endangering the transaction visibility for other backends, and syncrep
> may cause the window to get wider.
> - Changing GetRunningTransactionData so as duplicates are removed at
> this stage. However this also requires to hold ProcArrayLock for
That's *MUCH* better than what we have right
now. GetRunningTransactionData() isn't called all that often, for once,
and for another the WAL then is correct.
> > Even leaving the crummyness aside, did you check other users of
> > XLOG_RUNNING_XACTS, e.g. logical decoding?
> I actually spent some time checking that, so it is not innocent.
> SnapBuildWaitSnapshot() waits for transactions to commit or abort based
> on the XIDs in the record. And that's the only place where those XIDs
> are used so it won't matter to wait twice for the same transaction to
> finish. The error callback would be used only once.
Right. We used to use it more (and it'd probably caused problems), but
since 955a684e0401954a58e956535107bc4b7136d952 it should be ok...
|Next Message||Alvaro Herrera||2018-10-22 22:15:38||Re: pgsql: Avoid duplicate XIDs at recovery when building initial snapshot|
|Previous Message||Andres Freund||2018-10-22 17:41:55||Re: pgsql: Avoid duplicate XIDs at recovery when building initial snapshot|
|Next Message||Jung, Jinho||2018-10-22 18:08:19||Re: Regarding query minimizer (simplifier)|
|Previous Message||Andrey Lepikhov||2018-10-22 17:54:19||Re: [PATCH] XLogReadRecord returns pointer to currently read page|