On 11/27/23 13:08, Hayato Kuroda (Fujitsu) wrote: > Dear Amit, Tomas, > >>>> >>>> I am wondering that instead of building the infrastructure to know >>>> whether a particular change is transactional on the decoding side, >>>> can't we have some flag in the WAL record to note whether the change >>>> is transactional or not? I have discussed this point with my colleague >>>> Kuroda-San and we thought that it may be worth exploring whether we >>>> can use rd_createSubid/rd_newRelfilelocatorSubid in RelationData to >>>> determine if the sequence is created/changed in the current >>>> subtransaction and then record that in WAL record. By this, we need to >>>> have additional information in the WAL record like XLOG_SEQ_LOG but we >>>> can probably do it only with wal_level as logical. >>>> >>> >>> I may not understand the proposal exactly, but it's not enough to know >>> if it was created in the same subxact. It might have been created in >>> some earlier subxact in the same top-level xact. >>> >> >> We should be able to detect even some earlier subxact or top-level >> xact based on rd_createSubid/rd_newRelfilelocatorSubid. > > Here is a small PoC patchset to help your understanding. Please see attached > files. > > 0001, 0002 were not changed, and 0004 was reassigned to 0003. > (For now, I focused only on test_decoding, because it is only for evaluation > purpose.) > > 0004 is what we really wanted to say. is_transactional is added in WAL > record, and it stores > whether the operations is transactional. In order to distinguish the status, > rd_createSubid and > rd_newRelfilelocatorSubid are used. According to the comment, they would be a > valid value > only when the relation was changed within the transaction > Also, sequences_hash was not needed anymore, so it and related functions were > removed. > > How do you think? >
I think it's an a very nice idea, assuming it maintains the current behavior. It makes a lot of code unnecessary, etc. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
