Re: [HACKERS] Something is rotten in publication drop

On Thu, Jun 15, 2017 at 02:04:04AM +0000, Noah Misch wrote:
> 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

This PostgreSQL 10 open item is past due for your status update.  Kindly send
a status update within 24 hours, and include a date for your subsequent status
update.  Refer to the policy on open item ownership:
https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com