Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling - Mailing list pgsql-hackers

From Richard Huxton
Subject Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Date
Msg-id 412AF6C0.4010607@archonet.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
List pgsql-hackers
Christopher Kings-Lynne wrote:
>> Uh ... the interesting question is usually not "does this backend hold
>> any row locks", it is "is this row locked by any backends".  If the
>> latter question is not *exceedingly* cheap to answer, at least in the
>> normal case where the answer is no, you don't have a workable solution,
>> because you'll be adding nontrivial overhead to every row update.
> 
> 
> OK, what I mean is to know if a row is locked by any backend, why can't 
> we just put a reference count of the number of locks on that row, 
> instead of recording each backend separately?  Wouldn't that require a 
> fixed amount of shared mem?

Don't forget having to deal with a backend dying without being able to 
decrement the count (not my idea, Bruce (iirc) mentioned it last time 
this was discussed). I think at the least you'd need a 
max-trans-id-with-lock number stored next to the count so that in the 
event of backend crashes the lock will eventually be released.

--  Richard Huxton  Archonet Ltd


pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: PITR: XLog File compression on Archive
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: 8.0 beta 1 on linux-mipsel R5900