On 9/20/17, 2:29 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> I started to look at this...
Thanks for taking a look.
> I think that the way this ought to work is you process the VacuumRelation
> structs purely sequentially, each in its own transaction, so you don't
> need leaps of faith about what to do if a relation changes between the
> first time you look at it and when you actually come to process it.
How might this work for VACUUM statements with no tables specified? It
seems like we must either handle the case when the relation changes before
it is processed or hold a lock for the duration of the vacuuming.
> The idea of "fast failing" because some later VacuumRelation struct might
> contain an error seems like useless complication, both in terms of the
> implementation and the user-visible behavior.
I agree that the patch might be simpler without this, but the user-visible
behavior is the reason I had included it. In short, my goal was to avoid
errors halfway through a long-running VACUUM statement because the user
misspelled a relation/column name or the relation/column was dropped.
It's true that the tests become mostly pointless if the relations or
columns change before they are processed, but this seems like it would be
a rarer issue in typical use cases.
I'll continue to look into switching to a more sequential approach and
eliminating the leaps of faith.
> As for the other patch, I wonder if it might not be better to
> silently ignore duplicate column names. But in either case, we don't
> need a pre-check, IMO. I'd just leave it to the lookup loop in
> do_analyze_rel to notice if it's looked up the same column number
> twice. That would be more likely to lead to a back-patchable fix,
> too. 0002 as it stands is useless as a back-patch basis, since it
> proposes modifying code that doesn't even exist in the back branches.
I'd be happy to write something up that is more feasibly back-patched.
Nathan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers