remembering locks and dynahash.c

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема remembering locks and dynahash.c
Дата
Msg-id CAMkU=1w-B5SXbn51qYm8T-Jd6P3V2czf2u4jsZUf+W7XAw6=iA@mail.gmail.com
обсуждение исходный текст
Ответы Re: remembering locks and dynahash.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sergey Koposov
Дата:
Сообщение: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Следующее
От: Tom Lane
Дата:
Сообщение: Not quite a security hole: CREATE LANGUAGE for non-superusers