Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
Date | |
Msg-id | CA+TgmobMGiNGHgBv7LF3qgcdVWsA8aEJvcHb3kx=zZ20dm+0jQ@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager (Masahiko Sawada <sawada.mshk@gmail.com>) |
Responses |
Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-hackers |
On Wed, Nov 8, 2017 at 9:40 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > Speaking of the acquiring these four lock types and heavy weight lock, > there obviously is a call path to acquire any of four lock types while > holding a heavy weight lock. In reverse, there also is a call path > that we acquire a heavy weight lock while holding any of four lock > types. The call path I found is that in heap_delete we acquire a tuple > lock and call XactLockTableWait or MultiXactIdWait which eventually > could acquire LOCKTAG_TRANSACTION in order to wait for the concurrent > transactions finish. But IIUC since these functions acquire the lock > for the concurrent transaction's transaction id, deadlocks doesn't > happen. No, that's not right. Now that you mention it, I realize that tuple locks can definitely cause deadlocks. Example: setup: rhaas=# create table foo (a int, b text); CREATE TABLE rhaas=# create table bar (a int, b text); CREATE TABLE rhaas=# insert into foo values (1, 'hoge'); INSERT 0 1 session 1: rhaas=# begin; BEGIN rhaas=# update foo set b = 'hogehoge' where a = 1; UPDATE 1 session 2: rhaas=# begin; BEGIN rhaas=# update foo set b = 'quux' where a = 1; session 3: rhaas=# begin; BEGIN rhaas=# lock bar; LOCK TABLE rhaas=# update foo set b = 'blarfle' where a = 1; back to session 1: rhaas=# select * from bar; ERROR: deadlock detected LINE 1: select * from bar; ^ DETAIL: Process 88868 waits for AccessShareLock on relation 16391 of database 16384; blocked by process 88845. Process 88845 waits for ExclusiveLock on tuple (0,1) of relation 16385 of database 16384; blocked by process 88840. Process 88840 waits for ShareLock on transaction 1193; blocked by process 88868. HINT: See server log for query details. So what I said before was wrong: we definitely cannot exclude tuple locks from deadlock detection. However, we might be able to handle the problem in another way: introduce a separate, parallel-query specific mechanism to avoid having two participants try to update and/or delete the same tuple at the same time - e.g. advertise the BufferTag + offset within the page in DSM, and if somebody else already has that same combination advertised, wait until they no longer do. That shouldn't ever deadlock, because the other worker shouldn't be able to find itself waiting for us while it's busy updating a tuple. After some further study, speculative insertion locks look problematic too. I'm worried about the code path ExecInsert() [taking speculative insertion locking] -> heap_insert -> heap_prepare_insert -> toast_insert_or_update -> toast_save_datum -> heap_open(rel->rd_rel->reltoastrelid, RowExclusiveLock). That sure looks like we can end up waiting for a relation lock while holding a speculative insertion lock, which seems to mean that speculative insertion locks are subject to at least theoretical deadlock hazards as well. Note that even if we were guaranteed to be holding the lock on the toast relation already at this point, it wouldn't fix the problem, because we might still have to build or refresh a relcache entry at this point, which could end up scanning (and thus locking) system catalogs. Any syscache lookup can theoretically take a lock, even though most of the time it doesn't, and thus taking a lock that has been removed from the deadlock detector (or, say, an lwlock) and then performing a syscache lookup with it held is not OK. So I don't think we can remove speculative insertion locks from the deadlock detector either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
pgsql-hackers by date: