| 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 15:39:58 |
| Message-ID: | 37E6554E.8F4C0F13@krs.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>
> > 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.
>
> I do not think changing RowExclusiveLock back to AccessExclusiveLock
> will fix it unless we hold the lock till end of transaction, no?
Yes.
> That seems like much too high a price to pay.
That's why I proposed to use Exclusive lock (it doesn't conflict
with AccessShareLock used by readers).
> > But we have to handle this in proper way (wait if t_xmax
> > is id of an active transaction).
>
> Yes. Where is the code that does this right in the regular executor?
> I will see what needs to be done to make the system table accesses
> act the same.
Sorry - I messed things up: heap_replace/heap_delete wait for
concurrent update, but doesn't update/delete modified tuple.
They return result code (HeapTupleMayBeUpdated etc in utils/tqual.h)
and it's up to caller decide what to do if tuple modified by
concurrent transaction.
For _updated_ tuple TID of new tuple version is also returned
(if requested)...
Examples of how this is handled/used by Executor are
in execMain.c (just search for HeapTupleUpdated).
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brook Milligan | 1999-09-20 16:19:49 | Re: [HACKERS] Re: HISTORY for 6.5.2 |
| Previous Message | Bruce Momjian | 1999-09-20 15:33:29 | Re: [HACKERS] Status on Jan Wieck |