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