From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted |
Date: | 2017-11-16 20:49:21 |
Message-ID: | CAH2-Wzn0OXhMesmxUvk9_F75KaPH52FU=wj6xmWaGJTE3gvMOw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 16, 2017 at 12:44 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I would like to get rid of that LockPage() call, for sure, because
> it's problematic in terms of allowing writes in parallel mode.
> However, I think the reason here is the same as why the hash AM used
> to use them. If you use a buffer lock, you really can't -- or
> shoudn't, at least -- hold it across a whole series of operations,
> because anyone waiting for that lock is waiting *uninterruptibly*.
I'm well aware of that.
> The hash AM wanted to iterate through all of the pages in a bucket
> chain and do something to each one while preventing concurrent scans;
> the need here is similar. Aside from the uninterruptible-wait
> problem, such coding patterns are extremely prone to deadlock. If
> there's any chance that a process waiting for the buffer lock you hold
> might be holding a buffer lock you try to acquire, you have got a
> problem.
But there is only ever one page locked, the meta-page. And, it's
always an ExclusiveLock. I don't see much use for deadlock avoidance.
In any case, it's unusual to have a patch that uses LockPage() without
explaining the choice.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-11-16 20:54:07 | Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted |
Previous Message | Robert Haas | 2017-11-16 20:44:28 | Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted |