| From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Notice: heap_open/close changes committed |
| Date: | 1999-09-20 01:24:31 |
| Message-ID: | 37E58CCF.32C57B87@krs.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>
> 2. I made most opens of system relations grab AccessShareLock if
> read-only, or RowExclusiveLock if read-write, on the theory that
^^^^^^^^^^^^^^^^
> these accesses correspond to an ordinary search or update of a user
> relation. This maximizes concurrency of access to the system tables.
There are problems here. In the case of normal UPDATE/DELETE
(when RowExclusiveLock is acquired) Executor takes care about
the-same-row writers, but other parts of system don't check
is tuple read being updated concurrent transaction or not.
This is the old bug (pre-6.5.X released WRITE lock just after
system table was modified). I had no time to fix it and so
just changed old WRITE lock with new AccessExclusiveLock.
But we have to handle this in proper way (wait if t_xmax
is id of an active transaction).
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vadim Mikheev | 1999-09-20 01:25:47 | Re: [HACKERS] Why do we need pg_vlock? |
| Previous Message | Bruce Momjian | 1999-09-20 00:02:35 | Re: [HACKERS] Command Locations (was Re: HISTORY for 6.5....) |