Re: relation ### modified while in use

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alex Pilosov <alex(at)pilosoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: relation ### modified while in use
Date: 2000-10-24 00:03:38
Message-ID: 39F4D1D9.D449E871@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner wrote:

> At 15:29 23/10/00 +0900, Hiroshi Inoue wrote:
> >
> >If we have a mechanism to acquire a share lock on a tuple,we
> >could use it for managing system info generally. However the
> >only allowed lock on a tuple is exclusive. Access(Share/Exclusive)
> >Lock on tables would give us a restricted solution about pg_class
> >tuples.
> >
>
> Don't we have this ability? What about taking a RowShare lock on the
> pg_class tuple whenever you read from the table; then requiring schema
> updates take a RowExclusive lock on the pg_class tuple?
>

Both RowShare and RowExclusive lock are table level
locking. The implementation of tuple level locking is
quite different from that of table level locking.
The information of table level locking is held in shared
memory. OTOH the information of tuple level locking
is held in the tuple itself i.e. a transaction(t_xmax) is
updating/deleting/selecting for update the tuple....
If other backends are about to update/delete/select
for update a tuple,they check the information of the
tuple and if the tuple is being updated/... they wait until
the end of the transaction(t_xmax).

Regards.
Hiroshi Inoue

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-10-24 00:20:36 BLERe: AW: AW: relation ### modified while in use
Previous Message Dominic J. Eidson 2000-10-23 22:00:48 Re: Great Bridge is hiring!