Re: Heap truncation without AccessExclusiveLock (9.4)

On 20.05.2013 16:59, Robert Haas wrote:
> On Fri, May 17, 2013 at 3:38 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> If we could use the catchup interrupts to speed that up though, that would
>> be much better. I think vacuum could simply send a catchup interrupt, and
>> wait until everyone has caught up. That would significantly increase the
>> traffic of sinval queue and catchup interrupts, compared to what it is
>> today, but I think it would still be ok. It would still only be a few sinval
>> messages and catchup interrupts per truncation (ie. per vacuum).
>
> Hmm. So your proposal is to only send these sinval messages while a
> truncation is in progress, not any time the relation is extended?
> That would certainly be far more appealing from the point of view of
> not blowing out sinval.

Right.

> It shouldn't be difficult to restrict the set of backends that have to
> be signaled to those that have the relation open. You could have a
> special kind of catchup signal that means "catch yourself up, but
> don't chain"

What does "chain" mean above?

> - and send that only to those backends returned by
> GetConflictingVirtualXIDs.

Yeah, that might be a worthwhile optimization.

> It might be better to disconnect this mechanism from sinval entirely.
> In other words, just stick a version number on your shared memory
> data structure and have everyone advertise the last version number
> they've seen via PGPROC. The sinval message doesn't really seem
> necessary; it's basically just a no-op message to say "reread shared
> memory", and a plain old signal can carry that same message more
> efficiently.

Hmm. The sinval message makes sure that when a backend locks a relation,
it will see the latest value, because of the AcceptInvalidationMessages
call in LockRelation. If there is no sinval message, you'd need to
always check the shared memory area when you lock a relation.

> One other thought regarding point 6 from your original proposal. If
> it's true that a scan could hold a pin on a buffer above the current
> hard watermark, which I think it is, then that means there's a scan in
> progress which is going to try to fetch pages beyond that also, up to
> whatever the end of file position was when the scan started. I
> suppose that heap scans will need to be taught to check some
> backend-local flag before fetching each new block, to see if a hard
> watermark change might have intervened. Is that what you have in
> mind?

Yes, heap scan will need to check the locally cached high watermark
value every time when stepping to a new page.

- Heikki