Re: Added schema level support for publication.
От | vignesh C |
---|---|
Тема | Re: Added schema level support for publication. |
Дата | |
Msg-id | CALDaNm0D0rfdGY+YXMaH+xdQYgD-eQZ2TJEfv7WGbPqSDr3b0w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Added schema level support for publication. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On Thu, Aug 12, 2021 at 5:54 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Fri, Aug 6, 2021 at 5:33 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > Thanks for the comments, the attached v19 patch has the fixes for the comments.
>
> Thank you for updating the patch!
>
> Here are some comments on v19 patch:
>
> + case OCLASS_PUBLICATION_SCHEMA:
> + RemovePublicationSchemaById(object->objectId);
> + break;
>
> +void
> +RemovePublicationSchemaById(Oid psoid)
> +{
> + Relation rel;
> + HeapTuple tup;
> +
> + rel = table_open(PublicationSchemaRelationId, RowExclusiveLock);
> +
> + tup = SearchSysCache1(PUBLICATIONSCHEMA, ObjectIdGetDatum(psoid));
> +
> + if (!HeapTupleIsValid(tup))
> + elog(ERROR, "cache lookup failed for publication schema %u",
> + psoid);
> +
> + CatalogTupleDelete(rel, &tup->t_self);
> +
> + ReleaseSysCache(tup);
> +
> + table_close(rel, RowExclusiveLock);
> +}
>
> Since RemovePublicationSchemaById() does simple catalog tuple
> deletion, it seems to me that we can DropObjectById() to delete the
> row of pg_publication_schema.
Relation cache invalidations were missing in the function, I have added and retained the function with invalidation changes.
> ---
> {
> - ScanKeyInit(&key[0],
> + ScanKeyData skey[1];
> +
> + ScanKeyInit(&skey[0],
> Anum_pg_class_relkind,
> BTEqualStrategyNumber, F_CHAREQ,
>
> CharGetDatum(RELKIND_PARTITIONED_TABLE));
>
> - scan = table_beginscan_catalog(classRel, 1, key);
> + scan = table_beginscan_catalog(classRel, 1, skey);
>
> Since we specify 1 as the number of keys in table_beginscan_catalog(),
> can we reuse 'key' instead of using 'skey'?
Modified.
> ---
> Even if we drop all tables added to the publication from it, 'pubkind'
> doesn't go back to 'empty'. Is that intentional behavior? If we do
> that, we can save the lookup of pg_publication_rel and
> pg_publication_schema in some cases, and we can switch the publication
> that was created as FOR SCHEMA to FOR TABLE and vice versa.
I felt this can be handled as a separate patch as the same scenario applies for all tables publication too. Thoughts?
> ---
> +static void
> +UpdatePublicationKindTupleValue(Relation rel, HeapTuple tup, int col,
> + char pubkind)
>
> Since all callers of this function specify Anum_pg_publication_pubkind
> to 'col', it seems 'col' is not necessary.
Modified
> ---
> +static void
> +AlterPublicationSchemas(AlterPublicationStmt *stmt, Relation rel,
> + HeapTuple tup,
> Form_pg_publication pubform)
>
> I think we don't need to pass 'pubform' to this function since we can
> get it by GETSTRUCT(tup).
Modified.
> ---
> + Oid schemaId = get_rel_namespace(relid);
> List *pubids = GetRelationPublications(relid);
> + List *schemaPubids = GetSchemaPublications(schemaId);
>
> Can we defer to get the list of schema publications (i.g.,
> 'schemaPubids') until we find the PUBKIND_SCHEMA publication? Perhaps
> the same is true for building 'pubids'.
I felt that we can get the publication information and use it whenever required instead of querying in the loop. Thoughts?
> ---
> + List of publications
> + Name | Owner | All tables | Inserts
> | Updates | Deletes | Truncates | Via root | PubKind
> +--------------------+--------------------------+------------+---------+---------+---------+-----------+----------+---------
> + testpib_ins_trunct | regress_publication_user | f | t
> | f | f | f | f | e
> + testpub_default | regress_publication_user | f | f
> | t | f | f | f | e
>
> I think it's more readable if \dRp shows 'all tables', 'table',
> 'schema', and 'empty' in PubKind instead of the single character.
Modified
> I think 'Pub kind' is more consistent with other column names.
Modified
Thanks for the comments, these issues are fixed in the v20 patch attached at [1].
[1] - https://www.postgresql.org/message-id/CALDaNm00X9SQBokUTy1OxN1Sa2DFsK8rg8j_wLgc-7ZuKcuh0Q%40mail.gmail.com
>
> On Fri, Aug 6, 2021 at 5:33 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > Thanks for the comments, the attached v19 patch has the fixes for the comments.
>
> Thank you for updating the patch!
>
> Here are some comments on v19 patch:
>
> + case OCLASS_PUBLICATION_SCHEMA:
> + RemovePublicationSchemaById(object->objectId);
> + break;
>
> +void
> +RemovePublicationSchemaById(Oid psoid)
> +{
> + Relation rel;
> + HeapTuple tup;
> +
> + rel = table_open(PublicationSchemaRelationId, RowExclusiveLock);
> +
> + tup = SearchSysCache1(PUBLICATIONSCHEMA, ObjectIdGetDatum(psoid));
> +
> + if (!HeapTupleIsValid(tup))
> + elog(ERROR, "cache lookup failed for publication schema %u",
> + psoid);
> +
> + CatalogTupleDelete(rel, &tup->t_self);
> +
> + ReleaseSysCache(tup);
> +
> + table_close(rel, RowExclusiveLock);
> +}
>
> Since RemovePublicationSchemaById() does simple catalog tuple
> deletion, it seems to me that we can DropObjectById() to delete the
> row of pg_publication_schema.
Relation cache invalidations were missing in the function, I have added and retained the function with invalidation changes.
> ---
> {
> - ScanKeyInit(&key[0],
> + ScanKeyData skey[1];
> +
> + ScanKeyInit(&skey[0],
> Anum_pg_class_relkind,
> BTEqualStrategyNumber, F_CHAREQ,
>
> CharGetDatum(RELKIND_PARTITIONED_TABLE));
>
> - scan = table_beginscan_catalog(classRel, 1, key);
> + scan = table_beginscan_catalog(classRel, 1, skey);
>
> Since we specify 1 as the number of keys in table_beginscan_catalog(),
> can we reuse 'key' instead of using 'skey'?
Modified.
> ---
> Even if we drop all tables added to the publication from it, 'pubkind'
> doesn't go back to 'empty'. Is that intentional behavior? If we do
> that, we can save the lookup of pg_publication_rel and
> pg_publication_schema in some cases, and we can switch the publication
> that was created as FOR SCHEMA to FOR TABLE and vice versa.
I felt this can be handled as a separate patch as the same scenario applies for all tables publication too. Thoughts?
> ---
> +static void
> +UpdatePublicationKindTupleValue(Relation rel, HeapTuple tup, int col,
> + char pubkind)
>
> Since all callers of this function specify Anum_pg_publication_pubkind
> to 'col', it seems 'col' is not necessary.
Modified
> ---
> +static void
> +AlterPublicationSchemas(AlterPublicationStmt *stmt, Relation rel,
> + HeapTuple tup,
> Form_pg_publication pubform)
>
> I think we don't need to pass 'pubform' to this function since we can
> get it by GETSTRUCT(tup).
Modified.
> ---
> + Oid schemaId = get_rel_namespace(relid);
> List *pubids = GetRelationPublications(relid);
> + List *schemaPubids = GetSchemaPublications(schemaId);
>
> Can we defer to get the list of schema publications (i.g.,
> 'schemaPubids') until we find the PUBKIND_SCHEMA publication? Perhaps
> the same is true for building 'pubids'.
I felt that we can get the publication information and use it whenever required instead of querying in the loop. Thoughts?
> ---
> + List of publications
> + Name | Owner | All tables | Inserts
> | Updates | Deletes | Truncates | Via root | PubKind
> +--------------------+--------------------------+------------+---------+---------+---------+-----------+----------+---------
> + testpib_ins_trunct | regress_publication_user | f | t
> | f | f | f | f | e
> + testpub_default | regress_publication_user | f | f
> | t | f | f | f | e
>
> I think it's more readable if \dRp shows 'all tables', 'table',
> 'schema', and 'empty' in PubKind instead of the single character.
Modified
> I think 'Pub kind' is more consistent with other column names.
Modified
Thanks for the comments, these issues are fixed in the v20 patch attached at [1].
[1] - https://www.postgresql.org/message-id/CALDaNm00X9SQBokUTy1OxN1Sa2DFsK8rg8j_wLgc-7ZuKcuh0Q%40mail.gmail.com
Regards,
Vignesh
Vignesh
В списке pgsql-hackers по дате отправления: