Andres Freund writes:
> On 2013-11-28 10:31:21 -0500, Tom Lane wrote:
>> The only remaining risk is that, if pointer
>> fetch/store isn't atomic, we might fetch a half-updated pointer; which
>> will be non-null, but not something we can use to reach the list. Since
>> we do purport to support suc
On 2013-11-28 10:31:21 -0500, Tom Lane wrote:
> The only remaining risk is that, if pointer
> fetch/store isn't atomic, we might fetch a half-updated pointer; which
> will be non-null, but not something we can use to reach the list. Since
> we do purport to support such architectures, we'd better
Robert Haas writes:
> In terms of making this more robust, one idea - along the lines you
> mentioned in your original post - is to have a separate code path for
> the case where we're releasing *all* locks.
Yeah, I thought seriously about that, but concluded that it was too
debatable for a back-
On Wed, Nov 27, 2013 at 8:21 PM, Tom Lane wrote:
> I wrote:
>> We could still do this if we were willing to actually reject requests
>> for session level locks on fast-path-eligible lock types. At the moment
>> that costs us nothing really. If anyone ever did have a use case, we
>> could conside
I wrote:
> We could still do this if we were willing to actually reject requests
> for session level locks on fast-path-eligible lock types. At the moment
> that costs us nothing really. If anyone ever did have a use case, we
> could consider adding the extra logic to support it.
Nope, that *sti
Andres Freund writes:
> On 2013-11-27 17:25:44 -0500, Tom Lane wrote:
>> Or we
>> could add a restriction to EligibleForRelationFastPath that restricts
>> the fast-path mechanism to non-session locks, in which case we'd not
>> need to make the zeroing contingent on allLocks either. I don't think
On 2013-11-27 17:25:44 -0500, Tom Lane wrote:
> Or we
> could add a restriction to EligibleForRelationFastPath that restricts
> the fast-path mechanism to non-session locks, in which case we'd not
> need to make the zeroing contingent on allLocks either. I don't think
> we take any fast-path-eligi
In LockReleaseAll, we have this coding:
for (partition = 0; partition < NUM_LOCK_PARTITIONS; partition++)
{
LWLockIdpartitionLock = FirstLockMgrLock + partition;
SHM_QUEUE *procLocks = &(MyProc->myProcLocks[partition]);
proclock = (PROCLOCK *) SHMQueueNext(pro
