Re: relation ### modified while in use

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

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> 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?

How is that different from taking locks on the table itself?

In any case, we don't have the ability to hold multiple classes of locks
on individual tuples, AFAIK. UPDATE and SELECT FOR UPDATE use a
different mechanism that involves setting fields in the header of the
affected tuple. There's no room there for more than one kind of lock;
what's worse, checking and waiting for that lock is far slower than
normal lock-manager operations. (But on the plus side, you can be
holding locks on any number of tuples without risking overflowing the
lock manager table, and releasing the locks at commit takes no cycles.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ned Lilly 2000-10-23 14:53:48 Great Bridge is hiring!
Previous Message Bruce Momjian 2000-10-23 14:45:28 Re: Add support for <xti.h>