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.eisentr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers