Re: [HACKERS] Issue with logical replication: MyPgXact->xmin alreadyis valid - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [HACKERS] Issue with logical replication: MyPgXact->xmin alreadyis valid
Date
Msg-id c5a08ccb-123c-6649-486b-77c2a1e6b723@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Issue with logical replication: MyPgXact->xmin alreadyis valid  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
On 07/10/17 18:23, Konstantin Knizhnik wrote:
> On 10/07/2017 04:26 PM, Petr Jelinek wrote:
>>
>> Hmm so you start transaction (you have to when running
>> CREATE_REPLICATION_SLOT with USE_SNAPSHOT parameter). And while the slot
>> is being created the config is reloaded. And since now you are in
>> transaction the tsearch hook for GUC processing tries to access catalogs
>> which sets the xmin for the transaction.
> 
> Actually this slot is implicitly created by LogicalRepSyncTableStart to
> perform initial data sync.
> 

That does not change what I said above.

>>
>> That's not good, but I can't really say I have idea about what to do
>> with it other than to set some kind of flag saying that logical decoding
>> snapshot is being built and using that to skip catalog access which does
>> not seem very pretty.
>>
> It is not quite clear from the comment why it is not possible to
> overwrite MyPgXact->xmin or just use existed value.
> 

We can't use existing value because the snapshot used to read data would
no longer correspond to the one we just built as consistent start point.

About overwriting, well we may be able to do that if there was no active
snapshot in the transaction, ie we could try doing something like
SnapshotResetXmin() or possibly rather InvalidateCatalogSnapshot() since
the xmin was set for reading catalog snapshot before checking the
MyPgXact->xmin.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] separate serial_schedule useful?
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Discussion on missing optimizations