Re: [HACKERS] Shaky coding for vacuuming partitioned relations

Amit Langote <Langote_Amit_f8@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