RE: Session in aborted transaction misses effective_wal_level change - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Session in aborted transaction misses effective_wal_level change
Date
Msg-id OS7PR01MB18317EB21BD4551CC8EEB6F22F5962@OS7PR01MB18317.jpnprd01.prod.outlook.com
Whole thread
In response to Re: Session in aborted transaction misses effective_wal_level change  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Session in aborted transaction misses effective_wal_level change
List pgsql-hackers
Dear Bertrand, Sawada-san,

> I wonder if it wouldn't make more sense to keep this after
> XactTopFullTransactionId
> is reset, as in v1?
> 
> Indeed, couldn't a barrier be processed during AtCleanup_Memory(), while the
> XID is still valid, and set XLogLogicalInfoUpdatePending again after this call?

Per my research the function calls MemoryContextCallResetCallbacks(), which can
calls the arbitrary functions from core and extensions. So It's possible that a
random callback calls CHECK_FOR_INTERRUPTS() and consumes a barrier.

I still prefer to put after resetting the XactTopFullTransactionId.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: shihao zhong
Date:
Subject: Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers
Next
From: shihao zhong
Date:
Subject: Re: pg_resetwal: refuse to run when backup_label exists