Re: repeated decoding of prepared transactions

From: Andres Freund <andres(at)anarazel(dot)de>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: repeated decoding of prepared transactions
Date: 2021-02-21 22:26:26
Message-ID: 20210221222626.mzmyz5mg67rn3nef@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-02-21 11:32:29 +0530, Amit Kapila wrote:
> Here, I am assuming you are asking to disable 2PC both via
> apply-worker and tablesync worker till the initial sync (aka all
> tables are in SUBREL_STATE_READY state) phase is complete. If we do
> that and what if commit prepared happened after the initial sync phase
> but prepare happened before that?

Isn't that pretty easy to detect? You compare the LSN of the tx prepare
with the LSN of achieving consistency? Any restart will recover the
LSNs, because restart_lsn will be before the start of the tx.

> At Commit prepared because the 2PC is enabled, we will just send
> Commit Prepared without the actual data and prepare. Now, to solve
> that say we remember in TXN that at prepare time 2PC was not enabled
> so at commit prepared time consider that 2PC is disabled for that TXN
> and send the entire transaction along with commit as we do for non-2PC
> TXNs. But it is possible that a restart might happen before the commit
> prepared and then it is possible that prepare falls before
> start_decoding_at point so we will still skip sending it even though
> 2PC is enabled after the restart and just send the commit
> prepared. So, again that can lead to replica going out of sync.

I don't think that an LSN based approach is susceptible to this. And it
wouldn't require more memory etc than we'd now.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2021-02-21 23:15:03 Re: Extensions not dumped when --schema is used
Previous Message Justin Pryzby 2021-02-21 22:23:08 Re: [HACKERS] GSoC 2017: Foreign Key Arrays