Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling

From: Richard Huxton <dev(at)archonet(dot)com>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Date: 2004-08-24 08:05:20
Message-ID: 412AF6C0.4010607@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2004-08-24 11:06:23 Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Previous Message Christopher Kings-Lynne 2004-08-24 07:36:21 Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB SD 2004-08-24 08:05:59 Re: 8.0 beta 1 on linux-mipsel R5900
Previous Message Zeugswetter Andreas SB SD 2004-08-24 07:43:45 Re: PITR: XLog File compression on Archive