| 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 15:37:53 |
| Message-ID: | 8746.972315473@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:
> Only slightly; one interpretation of a table lock is that it locks all of
> the data in the table; and a lock on the pg_class row locks the metadata. I
> must admit that I am having a little difficulty thinking of a case where
> the distinction would be useful...
I can't see any value in locking the data without locking the metadata.
Given that, the other way round is sort of moot...
> So where do
> SELECT FOR UPDATE IN ROW SHARE MODE
We don't support that (never heard of it before, in fact)
> and
> LOCK TABLE IN ROW EXCLUSIVE MODE statements.
> fit in?
That one is just a table lock (RowExclusiveLock). All the variants
of LOCK TABLE are table-level locks.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Philip Warner | 2000-10-23 15:39:13 | Re: relation ### modified while in use |
| Previous Message | Bruce Momjian | 2000-10-23 15:33:33 | Re: [COMMITTERS] pgsql/src/test/regress/expected (plpgsql.out inet.out foreign_key.out errors.out) |