On Mon, Dec 13, 2021 at 07:53:43PM +0900, Michael Paquier wrote:
> Well, I don't think that it is a big deal one way or the other, as
> we'd finish with InvalidXLogRecPtr for the LSN and 0 for the timestamp
> anyway. If both of you feel that just removing the assertion rather
> than adding an
On Mon, Dec 13, 2021 at 03:46:55PM +0530, Amit Kapila wrote:
> This is my understanding as well. I think here the point of Sawada-San
> is why to have additional for replorigin_session_origin_lsn in prepare
> code path? I think the way you have it in your patch is correct as
> well but it is
On Mon, Dec 13, 2021 at 2:00 PM Michael Paquier wrote:
>
> On Mon, Dec 13, 2021 at 04:30:36PM +0900, Masahiko Sawada wrote:
> > Why do we check if replorigin_session_origin_lsn is not invalid data
> > only when PREPARE TRANSACTION?
>
> Well, it does not matter for the case of PREPARE TRANSACTION,
On Mon, Dec 13, 2021 at 04:30:36PM +0900, Masahiko Sawada wrote:
> Why do we check if replorigin_session_origin_lsn is not invalid data
> only when PREPARE TRANSACTION?
Well, it does not matter for the case of PREPARE TRANSACTION, does it?
we would include values for the the origin LSN and
On Mon, Dec 13, 2021 at 12:44 PM Michael Paquier wrote:
>
> Hi all,
> (CCing some folks who worked on this area lately)
>
> The following sequence of commands generates an assertion failure, as
> of $subject:
> select pg_replication_origin_create('popo');
> select
Hi all,
(CCing some folks who worked on this area lately)
The following sequence of commands generates an assertion failure, as
of $subject:
select pg_replication_origin_create('popo');
select pg_replication_origin_session_setup('popo');
begin;
select txid_current();
prepare transaction 'popo';
