On Thu, Jun 23, 2016 at 10:56 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jun 22, 2016 at 10:13 PM, Amit Kapila <amit.kapila16@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
