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 CAA4eK1LEMPoDDuvCyqFYrntwtMjQ72Z1+rsyutQZ9bYBcrDGdA@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, Aug 6, 2021 at 2:02 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Wed, Aug 4, 2021 at 4:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Tue, Aug 3, 2021 at 8:38 PM vignesh C <vignesh21@gmail.com> wrote:
>
> > 6.
> > + {PublicationSchemaRelationId, /* PUBLICATIONSCHEMAMAP */
> > + PublicationSchemaPsnspcidPspubidIndexId,
> > + 2,
> > + {
> > + Anum_pg_publication_schema_psnspcid,
> > + Anum_pg_publication_schema_pspubid,
> > + 0,
> > + 0
> > + },
> >
> > Why don't we keep pubid as the first column in this index?
>
> I wanted to keep it similar to PUBLICATIONRELMAP, should we keep it as
> it is, thoughts?
>

Okay, I see your point. I think for PUBLICATIONRELMAP, we need it
because it is searched using the only relid in
GetRelationPublications, so, similarly, in the patch, you are using
schema_oid in GetSchemaPublications, so probably that will help. I was
wondering why you haven't directly used the cache in
GetSchemaPublications similar to GetRelationPublications? It seems
there is a danger for concurrent object drop. Can you please check how
the safety is ensured say when either one wants to drop the
corresponding relation/schema or publication? Another point is why
can't we use the other index (where the index is on relid or
schema_oid (PublicationSchemaObjectIndexId))?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Added schema level support for publication.
Next
From: Mahendra Singh Thalor
Date:
Subject: Re: Support reset of Shared objects statistics in "pg_stat_reset" function