Re: Avoid streaming the transaction which are skipped (in corner cases)
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-11-26T05:28:55Z
Lists: pgsql-hackers
On Fri, Nov 25, 2022 at 4:04 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > > Excellent catch. We were looking at this code last week and wondered > the purpose of this abort. Probably we should have some macro or > function to decided whether to skip a transaction based on log record. > That will avoid using different values in different places. We do have a common function i.e. SnapBuildXactNeedsSkip() but there are two problems 1) it has a dependency on the input parameter so the result may vary based on the input 2) this is only checked based on the LSN but there are other factors dbid and originid based on those also transaction could be skipped during DecodeCommit. So I think one possible solution could be to remember a dbid and originid in ReorderBufferTXN as soon as we get the first change which has valid values for these parameters. And now as you suggested have a common function that will be used by streaming as well as by DecodeCommit to decide on whether to skip or not. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Avoid unnecessary streaming of transactions during logical replication.
- bf07ab492c46 16.0 landed
-
Fix assertion failures while processing NEW_CID record in logical decoding.
- 16b1fe0037dc 16.0 cited