On Fri, Jan 7, 2022 at 1:28 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > > + * *during* a callback if we do any syscache or table access in the > > + * callback. > > > As we don't take locks on tables, can invalidation events be accepted > > during table access? I could be missing something but I see relation.c > > accepts invalidation messages only when lock mode is not 'NoLock'. > > The core point here is that you're assuming that NO code path taken > during logical decoding would try to take a lock. I don't believe it, > at least not unless you can point me to some debugging cross-check that > guarantees it. >
AFAIK, currently, there is no such debugging cross-check in locking APIs but we can add one to ensure that we don't acquire lock on user-defined tables during logical decoding. As pointed by Robert, I also don't think accessing user tables will work during logical decoding. > Given that we're interested in historic not current snapshots, I can > buy that it might be workable to manage syscache invalidations totally > differently than the way it's done in normal processing, in which case > (*if* it's done like that) maybe no invals would need to be recognized > while an output plugin is executing. But (a) the comment here is > entirely wrong if that's so, and (b) I don't see anything in inval.c > that makes it work differently. > I think we need invalidations to work in output plugin to ensure that the RelationSyncEntry has correct information. -- With Regards, Amit Kapila.
