Re: Bugs in pgoutput.c

On Fri, Jan 7, 2022 at 1:28 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.