On Thu, Jun 23, 2016 at 10:56 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jun 22, 2016 at 10:13 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> A scan that has seen the flag won't look at the >>> tuple in any case. >> >> Why so? Assume that scan started on new bucket where >> split-in-progress flag was set, now it will not look at tuples that >> are marked as moved-by-split in this bucket, as it will assume to find >> all such tuples in old bucket. Now, if allow Vacuum or someone else >> to remove tuples from old with just an Exclusive lock, it is quite >> possible that scan miss the tuple in old bucket which got removed by >> vacuum. > > Oh, you're right. So we really need to CLEAR the split-in-progress > flag before removing any tuples from the old bucket. >
I think that alone is not sufficient, we also need to out-wait any scan that has started when the flag is set and till it is cleared. Before vacuum starts cleaning particular bucket, we can certainly detect if it has to clean garbage tuples (the patch sets has_garbage flag in old bucket for split operation) and only for that case we can out-wait the scans. So probably, how it can work is during vacuum, take Exclusive lock on bucket, check if has_garbage flag is set and split-in-progress flag is cleared on bucket, if so then wait till the pin-count on bucket is 1, else if has_garbage is not set, then just proceed with clearing dead tuples from bucket. This will reduce the requirement of having cleanup lock only when it is required (namely when bucket has garbage tuples). -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers