Re: Added schema level support for publication. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Added schema level support for publication.
Date
Msg-id CAA4eK1K4a9dZ-7pV=zRAUAfMiCoEkjxn2befwP5A_AVxb4aO0Q@mail.gmail.com
Whole thread Raw
In response to Re: Added schema level support for publication.  (vignesh C <vignesh21@gmail.com>)
Responses Re: Added schema level support for publication.
List pgsql-hackers
On Fri, Sep 17, 2021 at 5:40 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Thu, Sep 16, 2021 at 9:54 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > I think there is one more similar locking problem.
> > AlterPublicationSchemas()
> > {
> > ..
> > + if (stmt->action == DEFELEM_ADD)
> > + {
> > + List *rels;
> > +
> > + rels = GetPublicationRelations(pubform->oid, PUBLICATION_PART_ROOT);
> > + RelSchemaIsMemberOfSchemaList(rels, schemaidlist, true);
> > ...
> > ...
> > }
> >
> > Here, we don't have a lock on the relation. So, what if the relation
> > is concurrently dropped after you get the rel list by
> > GetPublicationRelations?
>
> This works fine without locking even after concurrent drop, I felt
> this works because of MVCC.
>

Can you share the exact scenario you have tested? I think here it can
give a wrong error because it might access invalid cache entry, so I
think a lock is required here. Also, as said before, this might help
to make the rel list consistent in function
CheckObjSchemaNotAlreadyInPublication().

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Added schema level support for publication.
Next
From: Fabrice Chapuis
Date:
Subject: Re: Logical replication timeout problem