EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS

Поиск
Список
Период
Сортировка
От Andres Freund
Тема EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Дата
Msg-id 20210802065116.j763tz3vz4egqy3w@alap3.anarazel.de
обсуждение исходный текст
Ответы Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Andres Freund <andres@anarazel.de>)
Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi,

While looking at a patch I noticed that SubPostmasterMain() for bgworkers
unconditionally does

        /* Need a PGPROC to run CreateSharedMemoryAndSemaphores */
        InitProcess();

which presents a problem, because StartBackgroundWorker() then does

    /*
     * If we're not supposed to have shared memory access, then detach from
     * shared memory.  If we didn't request shared memory access, the
     * postmaster won't force a cluster-wide restart if we exit unexpectedly,
     * so we'd better make sure that we don't mess anything up that would
     * require that sort of cleanup.
     */
    if ((worker->bgw_flags & BGWORKER_SHMEM_ACCESS) == 0)
    {
        ShutdownLatchSupport();
        dsm_detach_all();
        PGSharedMemoryDetach();
    }

which presents a problem: We've initialized all kind of references to shared
memory, own a PGPROC, but have detached from shared memory.

In practice this will lead pretty quickly to a segfault, because process exit
will run proc_exit callbacks, which in turn will try to do a ProcKill(). Or
logging dereferences MyProc, or ...

It seems the above code block would need to at least do shmem_exit() before
the PGSharedMemoryDetach()?

This code has been introduced in

commit 4d155d8b08fe08c1a1649fdbad61c6dcf4a8671f
Author: Robert Haas <rhaas@postgresql.org>
Date:   2014-05-07 14:54:43 -0400

    Detach shared memory from bgworkers without shmem access.

    Since the postmaster won't perform a crash-and-restart sequence
    for background workers which don't request shared memory access,
    we'd better make sure that they can't corrupt shared memory.

    Patch by me, review by Tom Lane.

but before that things were just slightly differently broken...


I tested both the crash and that a shmem_exit() fixes it with an ugly hack in
regress.c. I don't really know how to write a good testcase for this, given
that the communication facilities of a unconnected bgworker are quite
limited... I guess the bgworker could create files or something :(.

Greetings,

Andres Freund



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

Предыдущее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Parallel Inserts (WAS: [bug?] Missed parallel safety checks..)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS