Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,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 11:06:23
Message-ID: 200408241106.i7OB6Ne22325@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Richard Huxton wrote:
> 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.

Even more significantly, how does the backend know where to go to
decrement its row counts on commit?  I think the best we could do would
be to store the xids on the row for each backend that has a shared lock.
The list could be cleared out automatically by looking in the PROC
structure and removing completed xids.  However, that is a lot of
storage for each row to have and a centralized table is probably best
where backends can clean up on their own on commit.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-08-24 11:06:36
Subject: Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Previous:From: Daniel KalchevDate: 2004-08-24 09:54:26
Subject: Re: missing data/global

pgsql-committers by date

Next:From: Bruce MomjianDate: 2004-08-24 11:06:36
Subject: Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling
Previous:From: Richard HuxtonDate: 2004-08-24 08:05:20
Subject: Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group