On 2018-07-23 19:37:46 +0530, Nikhil Sontakke wrote: > Hi Andres, > > >> > what I'm proposing is that that various catalog access functions throw a > >> > new class of error, something like "decoding aborted transactions". > >> > >> When will this error be thrown by the catalog functions? How will it > >> determine that it needs to throw this error? > > > > The error check would have to happen at the end of most systable_* > > functions. They'd simply do something like > > > > if (decoding_in_progress_xact && TransactionIdDidAbort(xid_of_aborted)) > > ereport(ERROR, (errcode(DECODING_ABORTED_XACT), errmsg("oops"))); > > > > i.e. check whether the transaction to be decoded still is in > > progress. As that would happen before any potentially wrong result can > > be returned (as the check happens at the tail end of systable_*), > > there's no issue with wrong state in the syscache etc. > > > > Oh, ok. The systable_* functions use the passed in snapshot and return > tuples matching to it. They do not typically have access to the > current XID being worked upon..
That seems like quite a solvable issue, especially compared to the locking schemes proposed. > We can find out if the snapshot is a logical decoding one by virtue of > its "satisfies" function pointing to HeapTupleSatisfiesHistoricMVCC. I think we even can just do something like a global TransactionId check_if_transaction_is_alive = InvalidTransactionId; and just set it up during decoding. And then just check it whenever it's not set tot InvalidTransactionId. Greetings, Andres Freund