On 10/5/17, 12:29 AM, "Michael Paquier" <michael.paqu...@gmail.com> wrote: > On Thu, Oct 5, 2017 at 1:23 AM, Bossart, Nathan <bossa...@amazon.com> wrote: >> Presently, there are a few edge cases in vacuum_rel() and analyze_rel() that >> I >> believe do not have sufficient logging. This was discussed a bit in the >> vacuum-multiple-relations thread [0], but it was ultimately decided that any >> logging changes should be proposed separately. > > I think that I agree with that, especially now with VACUUM allowing > multiple relations. The discussion then would be how much logging we > want. WARNING looks adapted per the discussions we had on the other > thread as manual VACUUMs can now involve much more relations, even > with partitioned tables. More opinions would be welcome.
Thanks for taking a look. >> and a test that exercises a bit of this functionality. > > My take on those test would be to not include them. This is a lot just > to test two logging lines where the relation has been dropped. Yeah, I'm not terribly concerned about those tests. >> If this change were to be considered for back-patching, we would likely want >> to >> also apply Michael's RangeVar fix for partitioned tables to 10 [1]. Without >> this change, log messages for unspecified partitions will be emitted with the >> parent's RangeVar information. > > Well, that's assuming that we begin logging some information for > manual VACUUMs using the specified RangeVar, something that does not > happen at the top of upstream REL_10_STABLE, but can happen if we were > to include the patch you are proposing on this thread for > REL_10_STABLE. But the latter is not going to happen. Or did you patch > your version of v10 to do so in your stuff? For v10 the ship has > already sailed, so I think that it would be better to just let it go, > and rely on v11 which has added all the facility we wanted. I agree. I didn't mean to suggest that it should be back-patched, just that v10 has a small quirk that needs to be handled if others feel differently. Nathan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
