From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vadim Mikheev <vadim(at)krs(dot)ru> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Notice: heap_open/close changes committed |
Date: | 1999-09-20 14:00:39 |
Message-ID: | 13572.937836039@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vadim Mikheev <vadim(at)krs(dot)ru> writes:
> 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
> ^^^^^^^^^^^^^^^^
> 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.
Drat. I was afraid I might be getting in over my head :-(
> 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?
That seems like much too high a price to pay.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-09-20 14:07:52 | Re: [HACKERS] Anyone understand shared buffer refcount mechanism? |
Previous Message | Tom Lane | 1999-09-20 13:55:19 | Re: [HACKERS] why do shmem attach? |