Amit Langote <langote_amit...@lab.ntt.co.jp> writes: > On 2017/09/25 12:10, Michael Paquier wrote: >> As long as I don't forget... Another thing currently on HEAD and >> REL_10_STABLE is that OIDs of partitioned tables are used, but the >> RangeVar of the parent is used for error reports. This leads to >> incorrect reports if a partition gets away in the middle of autovacuum >> as only information about the parent is reported to the user.
> Oh, you're right. The original RangeVar (corresponding to the table > mentioned in the command) refers to the parent table. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers