From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Reset snapshot export state on the transaction abort |
Date: | 2021-10-14 09:28:55 |
Message-ID: | CAFiTN-sz+wWKomcpUJJ8eC-VAEZQR4zBd7g4a=0_1YqQjunGvw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 14, 2021 at 12:24 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Oct 13, 2021 at 10:53:24AM +0530, Dilip Kumar wrote:
> > Actually, it is not required because 1) Snapshot export can not be
> > allowed within a transaction block, basically, it starts its own
> > transaction block and aborts that while executing any next replication
> > command see SnapBuildClearExportedSnapshot(). So our problem is only
> > if the transaction block internally started for exporting, gets
> > aborted before any next command arrives. So there is no possibility
> > of starting any sub transaction.
>
> Yes, you are right here. I did not remember the semantics this relies
> on. I have played more with the patch, reviewed the whole, and the
> fields you are resetting as part of the snapshot builds seem correct
> to me. So let's fix this.
Great, thanks!
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | 蔡梦娟 (玊于) | 2021-10-14 10:03:06 | Some doubts about streaming startpoint in WaitForWALToBecomeAvailable() |
Previous Message | Amit Langote | 2021-10-14 09:00:51 | Re: a misbehavior of partition row movement (?) |