remembering locks and dynahash.c

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: remembering locks and dynahash.c
Date: 2012-05-30 15:44:54
Message-ID: CAMkU=1w-B5SXbn51qYm8T-Jd6P3V2czf2u4jsZUf+W7XAw6=iA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Currently the resource owner does not remember what locks it holds.
When a resource owner wants to release its locks or reassign them to
its parent, it just digs through the backends entire
LockMethodLocalHash table. When that table is very large, but the
current owner owns only a small fraction of them, this leads to
performance problems. The only place I know of where this happens is
pg_dump.

I am working on making resource owner remember a limited number of
locks, so it can reassign them more efficiently.

Currently I'm having resowner.c remember the LOCALLOCKTAG, because I
thought that that was the only handle I could use. But now I'm
wondering if I should remember the LOCALLOCK * instead. I don't see
any instructions in dynahash about how long a pointer is valid for,
and looking through the code it seems like it should be valid until
the entry is removed or the hash table is destroyed. Even across a
table expansion I think the pointers stay put, it i just the
dynahash-private pointers to those pointers that change.

So, any advice on whether it is possible, or advisable, to remember
the LOCALLOCK * rather than the LOCALLOCKTAG?

Cheers,

Jeff

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-30 16:02:06 Not quite a security hole: CREATE LANGUAGE for non-superusers
Previous Message Sergey Koposov 2012-05-30 15:42:24 Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile