Re: BufferAlloc: don't take two simultaneous locks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BufferAlloc: don't take two simultaneous locks
Дата
Msg-id 1468260.1649945038@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BufferAlloc: don't take two simultaneous locks  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: BufferAlloc: don't take two simultaneous locks
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> With the existing system, there is a hard cap on the number of hash
> table entries that we can ever need: one per buffer, plus one per
> partition to cover the "extra" entries that are needed while changing
> buffer tags. With the patch, the number of concurrent buffer tag
> changes is no longer limited by NUM_BUFFER_PARTITIONS, because you
> release the lock on the old buffer partition before acquiring the lock
> on the new partition, and therefore there can be any number of
> backends trying to change buffer tags at the same time. But that
> means, as the comment implies, that there's no longer a hard cap on
> how many hash table entries we might need.

I agree that "just hope it doesn't overflow" is unacceptable.
But couldn't you bound the number of extra entries as MaxBackends?

FWIW, I have extremely strong doubts about whether this patch
is safe at all.  This particular problem seems resolvable though.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)
Следующее
От: "Euler Taveira"
Дата:
Сообщение: Re: Support logical replication of DDLs