Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> It's assumed that the same strategy is used when unpinning, which is
>> true for the current usage (and apparently needs to be documented).
>
> I don't believe that for a moment. Even in the trivial heapscan case,
> the last pin is typically dropped during a tupleslot clear operation
> sometime after the scan itself has moved on to the next page. In a more
> general context (such as parallel heapscan and indexscan on a rel) it's
> certainly too risky to assume it.
Hmm, I guess you're right. :(
One idea is to keep track which pins are taken using the bulk strategy.
It's a bit tricky when a buffer is pinned multiple times since we don't
know which ReleaseBuffer corresponds which ReadBuffer, but perhaps we
could get away with just a flag per pinned buffer. Set the flag when a
buffer is pinned with bulk strategy and it wasn't pinned by us before,
and clear it when it's pinned with another strategy. I'm thinking we
steal one bit from PrivateRefCount for this.
>> Normally buffers that are in the ring are recycled quickly, in which
>> case the usage_count will always be increased from 0->1 in UnpinBuffer,
>> regardless of the check. The check is there to avoid inflating the
>> usage_count on buffers that happened to be already in shared_buffers.
>
> A heapscan would pin the buffer only once and hence bump its count at
> most once, so I don't see a big problem here. Also, I'd argue that
> buffers that had a positive usage_count shouldn't get sucked into the
> ring to begin with.
True, except that with the synchronized scans patch two synchronized
scans will pin the buffer twice.
>> If we figure out another way to deal with the COPY usage_count, maybe we
>> could remove the check altogether. I've been thinking of changing COPY
>> anyway so that it always kept the last page it inserted to pinned, to
>> avoid the traffic to buffer manager on each tuple.
>
> This is getting fairly invasive for a part of the patch you've not
> justified at all yet...
>
>> Let me know if you want me to make changes and submit a new version.
>
> I can work on this stuff; please do the tests to show whether it's worth
> handling COPY TO REL, and keep on with Jeff's patch.
Ok.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com