On Tue, Sep 26, 2017 at 10:55 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/09/26 9:51, Michael Paquier wrote: >> On Tue, Sep 26, 2017 at 8:48 AM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >>> On Mon, Sep 25, 2017 at 11:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>>> Yeah, I'd noticed that while reviewing the vacuum-multiple-tables patch. >>>> My thought about fixing it was to pass a null RangeVar when handling a >>>> table we'd identified through inheritance or pg_class-scanning, to >>>> indicate that this wasn't a table named in the original command. This >>>> only works conveniently if you decide that it's appropriate to silently >>>> ignore relation_open failure on such table OIDs, but I think it is. >>>> >>>> Not sure about whether we ought to try to fix that in v10. It's a >>>> mostly-cosmetic problem in what ought to be an infrequent corner case, >>>> so it might not be worth taking risks for post-RC1. OTOH, I would >>>> not be surprised to get bug reports about it down the road. >>> >>> Something like that looks like a good compromise for v10. I would >>> rather see a more complete fix with each relation name reported >>> correctly on HEAD though. The information provided would be useful for >>> users when using autovacuum when skipping a relation because no lock >>> could be taken on it. >> >> Actually, perhaps this should be tracked as an open item? A simple fix >> is leading to the path that no information is better than misleading >> information in this case. > > +1.
Let's track it then and spawn a separate thread with a patch. Do you want to work on it or should I? The solution proposed by Tom seems like the correct answer. I am adding an item for now, we could always link it to a thread later on. Let's also track the problem that has been reported on this thread. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers