Re: this is in plain text (row level locks)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: sailesh(at)cs(dot)berkeley(dot)edu, Jenny - <nat_lazy(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: this is in plain text (row level locks)
Date: 2003-07-24 04:12:27
Message-ID: 200307240412.h6O4CR027317@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Sailesh Krishnamurthy wrote:
> >> Does pgsql only record X locks on the individual tuples on-disk or
> >> does it do so for S locks as well ?
>
> > We don't need to shared lock individual rows because of MVCC --- well,
> > we sort of do by recording our xid in our proc structure, so folks don't
> > change things underneath us. We prevent expired rows from disappearing
> > from the disk by others looking at our proc start xid.
>
> This is actually an issue though. Row-level shared locks would be
> really nice to have for foreign-key handling. Right now we have to
> use X locks for those, and that leads to deadlocking problems for
> applications.

Is the plan to allow one backend to shared lock the row while others can
read it but not modify it, or is the idea to actually allow multiple
backends to record their shared status on the row?

--
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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-07-24 04:29:50 Re: this is in plain text (row level locks)
Previous Message Bruce Momjian 2003-07-24 04:08:07 Re: [HACKERS] PATCH: Memory leaks on start-up