PostgreSQL 15 preview - Logical decoding of sequences

原创 digoal 2022-01-20

247

作者

digoal

日期

2022-02-11

Logical decoding of sequences  
author  Tomas Vondra <tomas.vondra@postgresql.org>    
Thu, 10 Feb 2022 17:43:28 +0000 (18:43 +0100)  
committer   Tomas Vondra <tomas.vondra@postgresql.org>    
Thu, 10 Feb 2022 17:43:51 +0000 (18:43 +0100)  
commit  0da92dc530c9251735fc70b20cd004d9630a1266  
tree    03521fcac88d0602a391c7c73ae8fe1185b670e7    tree  
parent  0d4513b6138650355fcc981a9f34ff57b8d69db4    commit | diff  
Logical decoding of sequences  
This extends the logical decoding to also decode sequence increments.  
We differentiate between sequences created in the current (in-progress)  
transaction, and sequences created earlier. This mixed behavior is  
necessary because while sequences are not transactional (increments are  
not subject to ROLLBACK), relfilenode changes are. So we do this:  
* Changes for sequences created in the same top-level transaction are  
  treated as transactional, i.e. just like any other change from that  
  transaction, and discarded in case of a rollback.  
* Changes for sequences created earlier are applied immediately, as if  
  performed outside any transaction. This applies also after ALTER  
  SEQUENCE, which may create a new relfilenode.  
Moreover, if we ever get support for DDL replication, the sequence  
won't exist until the transaction gets applied.  
Sequences created in the current transaction are tracked in a simple  
hash table, identified by a relfilenode. That means a sequence may  
already exist, but if a transaction does ALTER SEQUENCE then the  
increments for the new relfilenode will be treated as transactional.  
For each relfilenode we track the XID of (sub)transaction that created  
it, which is needed for cleanup at transaction end. We don't need to  
check the XID to decide if an increment is transactional - if we find a  
match in the hash table, it has to be the same transaction.  
This requires two minor changes to WAL-logging. Firstly, we need to  
ensure the sequence record has a valid XID - until now the the increment  
might have XID 0 if it was the first change in a subxact. But the  
sequence might have been created in the same top-level transaction. So  
we ensure the XID is assigned when WAL-logging increments.  
The other change is addition of "created" flag, marking increments for  
newly created relfilenodes. This makes it easier to maintain the hash  
table of sequences that need transactional handling.  
Note: This is needed because of subxacts. A XID 0 might still have the  
sequence created in a different subxact of the same top-level xact.  
This does not include any changes to test_decoding and/or the built-in  
replication - those will be committed in separate patches.  
A patch adding decoding of sequences was originally submitted by Cary  
Huang. This commit reworks various important aspects (e.g. the WAL  
logging and transactional/non-transactional handling). However, the  
original patch and reviews were very useful.  
Author: Tomas Vondra, Cary Huang  
Reviewed-by: Peter Eisentraut, Hannu Krosing, Andres Freund  
Discussion: https://postgr.es/m/d045f3c2-6cfb-06d3-5540-e63c320df8bc@enterprisedb.com  
Discussion: https://postgr.es/m/1710ed7e13b.cd7177461430746.3372264562543607781@highgo.ca