On Fri, Jun 09, 2017 at 11:45:58AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > On 6/8/17 23:53, Tom Lane wrote:
> >> ! ERROR: publication "addr_pub" does not exist
>
> > The \d+ command attempts to print out any publications that the relation
> > is part of. To find the publications it is part of, it runs this query:
>
> > "SELECT pub.pubname\n"
> > " FROM pg_catalog.pg_publication pub,\n"
> > " pg_catalog.pg_get_publication_tables(pub.pubname)\n"
> > "WHERE relid = '%s'\n"
> > "ORDER BY 1;",
>
> > pg_get_publication_tables() calls GetPublicationByName(), which throws
> > this error.
>
> > So I suppose that if a publication is dropped between the time
> > pg_publication is read and the function is called, you could get this error.
>
> Yeah, I'd suspected as much but not tracked it down yet.
>
> > How could we improve that?
>
> What we've done in many comparable situations is to allow a
> catalog-probing function to return NULL instead of failing
> when handed an OID or other identifier that it can't locate.
> Here it seems like pg_get_publication_tables() needs to use
> missing_ok = TRUE and then return zero rows for a null result.
> Arguably, a nonexistent publication publishes no tables, so
> it's not clear that's not the Right Thing anyway.
>
> BTW, isn't the above command a hugely inefficient way of finding
> the publications for the target rel? Unless you've got a rather
> small number of rather restricted publications, seems like it's
> going to take a long time. Maybe we don't care too much about
> manual invocations of \d+, but I bet somebody will carp if there's
> not a better way to find this out. Maybe a better answer is to
> define a more suitable function pg_publications_for_table(relid)
> and let it have the no-error-for-bad-OID behavior.
[Action required within three days. This is a generic notification.]
The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.
[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com