Re: margay fails assertion in stats/dsa/dsm code

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: margay fails assertion in stats/dsa/dsm code
Дата
Msg-id CA+TgmoYGNgRwN=pVK70GC=CtU8sUXwNC1admiH2H4iUjEC=F3g@mail.gmail.com
обсуждение исходный текст
Ответ на margay fails assertion in stats/dsa/dsm code  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: margay fails assertion in stats/dsa/dsm code  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Thu, Jun 2, 2022 at 8:06 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> I know that on Solaris we use dynamic_shared_memory=posix.  The other
> Solaris/Sparc system is wrasse, and it's not doing this.  I don't see
> it yet, but figured I'd report this much to the list in case someone
> else does.

My first thought was that the return value of the call to
dsm_impl_op() at the end of dsm_attach() is not checked and that maybe
it was returning NULL, but it seems like whoever wrote
dsm_impl_posix() was pretty careful to ereport(elevel, ...) in every
failure path, and elevel is ERROR here, so I don't see any issue. My
second thought was that maybe control had escaped from dsm_attach()
due to an error before we got to the step where we actually map the
segment, but then the dsm_segment * would be returned to the caller.
Maybe they could retrieve it later using dsm_find_mapping(), but that
function has no callers in core.

So I'm kind of stumped too, but did you by any chance check whether
there are any DSM-related messages in the logs before the assertion
failure?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Hardening PostgreSQL via (optional) ban on local file system access
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: making relfilenodes 56 bits