RE: Potential data loss due to race condition during logical replication slot creation - Mailing list pgsql-bugs

From Hayato Kuroda (Fujitsu)
Subject RE: Potential data loss due to race condition during logical replication slot creation
Date
Msg-id TYCPR01MB120774D17B90FFDAC087B959FF52C2@TYCPR01MB12077.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Potential data loss due to race condition during logical replication slot creation  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Potential data loss due to race condition during logical replication slot creation  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-bugs
Dear Amit,

> I feel setting "needs_full_snapshot" to true for decoding means the
> snapshot will start tracking non-catalog committed xacts as well which
> is costly.

I think the approach was most conservative one which does not have to change
the version of the snapshot. However, I understood that you wanted to consider
the optimized solution for HEAD first.

> See SnapBuildCommitTxn(). Can we avoid this problem if we
> would have list of all running xacts when we serialize the snapshot by
> not decoding any xact whose xid lies in that list? If so, one idea to
> achieve could be that we maintain the highest_running_xid while
> serailizing the snapshot and then during restore if that
> highest_running_xid is <= builder->initial_xmin_horizon, then we
> ignore restoring the snapshot. We already have few such cases handled
> in SnapBuildRestore().

Based on the idea, I made a prototype. It can pass tests added by others and me.
How do other think?

Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/ 



Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18399: Query plan optimization results in runtime error when hoisting cast from inside subquery
Next
From: Amit Kapila
Date:
Subject: Re: Potential data loss due to race condition during logical replication slot creation