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