Hi all, I have been looking more closely at the problem in $subject, that I have mentioned a couple of times, like here: https://www.postgresql.org/message-id/cab7npqqa37oune_rjzpmwc4exqalx9f27-ma_-rsfl_3mj+...@mail.gmail.com
As of HEAD, the RangeVar defined in calls of vacuum() is used for error reporting, only in two cases: for autoanalyze and autovacuum when reporting to users that a lock cannot be taken on a relation. The thing is that autovacuum has the good idea to call vacuum() on only one relation at the same time, with always a relation OID and a RangeVar defined, so the code currently on HEAD is basically fine with its error reporting, because get_rel_oids() will always work on the relation OID with its RangeVar, and because code paths with manual VACUUMs don't use the RangeVar for any reports. While v10 is safe, I think that this is wrong in the long-term and that may be a cause of bugs if people begin to generate reports for manual VACUUMs, which is plausible in my opinion. The patch attached, is what one solution would look like if we would like to make things more robust as long as manual VACUUM commands can only specify one relation at the same time. I have found that tracking the parent OID by tweaking a bit get_rel_oids() was the most elegant solution. Please note that this range of problems is something that I think is better solved with the infrastructure that support for VACUUM with multiple relations includes (last version here https://www.postgresql.org/message-id/766556dd-aa3c-42f7-acf4-5dc97f41f...@amazon.com). So I don't think that the patch attached should be integrated, still I am attaching it to satisfy the curiosity of anybody looking at this message. In conclusion, I think that the open item of $subject should be removed from the list, and we should try to get the multi-VACUUM patch in to cover any future problems. I'll do so if there are no objections. One comment on top of vacuum() is wrong by the way: in the case of a manual VACUUM or ANALYZE, a NULL RangeVar is used if no relation is specified in the command. Thanks, -- Michael
vac-rangevar-v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
