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
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 |