Re: [COMMITTERS] pgsql: Logical replication

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Logical replication
Date: 2018-06-11 23:16:34
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-committers pgsql-hackers


On 2017-01-20 14:06:18 +0000, Peter Eisentraut wrote:
> Logical replication
> - Add PUBLICATION catalogs and DDL
> - Add SUBSCRIPTION catalog and DDL
> - Define logical replication protocol and output plugin
> - Add logical replication workers

I know I mentioned this before, but I just hit it again. Please split
up your commits in more logical chunks. This has a *LOT* of largely
unrelated pieces. Lots of them without so much as a comment about why
they have been changed. The above certainly doesn't explain why the
*generic* cache invalidation code was affected:

@@ -509,8 +514,10 @@ RegisterRelcacheInvalidation(Oid dbId, Oid relId)
* If the relation being invalidated is one of those cached in the local
* relcache init file, mark that we need to zap that file at commit.
+ * Same is true when we are invalidating whole relcache.
- if (OidIsValid(dbId) && RelationIdIsInInitFile(relId))
+ if (OidIsValid(dbId) &&
+ (RelationIdIsInInitFile(relId) || relId == InvalidOid))
transInvalInfo->RelcacheInitFileInval = true;

I mean, like, seriously? What is this stuff about?

I kinda guess the motivating factor is:

* CacheInvalidateRelcacheAll
* Register invalidation of the whole relcache at the end of command.
* This is used by alter publication as changes in publications may affect
* large number of tables.

RegisterRelcacheInvalidation(InvalidOid, InvalidOid);

but that doesn't explain why it's not tied to a database? Nor why the
relcache init file is now invalidated when there's a publication change?


Andres Freund

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2018-06-11 23:18:12 pgsql: Fix access to just-closed relcache entry.
Previous Message Michael Paquier 2018-06-11 21:53:50 pgsql: Fix oversight from 9e149c8 with spin-lock handling

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-12 00:33:05 Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
Previous Message Tom Lane 2018-06-11 23:05:04 Re: why partition pruning doesn't work?