Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)
Дата
Msg-id CAEepm=2sqgwrtiO_TQXFbYbrgtQOtFxMr_c8hSp9eorZ9ZAd4A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)  (Mahi Gurram <teckymahi@gmail.com>)
Ответы Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)  (Mahendranath Gurram <mahendranath@zohocorp.com>)
Список pgsql-hackers
On Sat, Jun 17, 2017 at 1:17 AM, Mahi Gurram <teckymahi@gmail.com> wrote:
>> 3.  Whether you are the backend that created it or a backend that
>> attached to it, I think you'll need to store the dsa_area in a global
>> variable for your UDFs to access.  Note that the dsa_area object will
>> be different in each backend: there is no point in storing that
>> address itself in shared memory, as you have it, as you certainly
>> can't use it in any other backend. In other words, each backend that
>> attached has its own dsa_area object that it can use to access the
>> common dynamic shared memory area.
>
>
> In case of forked processes, the OS actually does share the pages initially,
> because fork implements copy-on-write semantics. which means that provided
> none of the processes modifies the pages, they both points to same address
> and the same data.
>
> Based on above theory, assume i have created dsa_area object in postmaster
> process(_PG_Init) and is a global variable, all the backends/forked
> processes can able to access/share the same dsa_area object and it's
> members.
>
> Hence theoretically, the code should work with out any issues. But i'm sure
> why it is not working as expected :(
>
> I tried debugging by putting prints, and observed the below things:
> 1. dsa_area_control address is different among postmaster process and
> backends.
> 2. After restarting, they seems to be same and hence it is working after
> that.

Postgres extensions can't rely on backends inheriting the postmaster's
memory map like this (other than the main shared memory areas which
the core code looks after).  For one thing, new backends aren't
created with fork() on all platforms (mainly Windows AFAIK, but also
any build with EXEC_BACKEND defined).  The next problem is that dsa.c
and dsm.c work with reference counts that will be wrong if you try to
use memory map inheritance like this.  Another problem is that the
postmaster isn't allowed to create DSM segment: if it's working for
you then I think you must be building with asserts disabled?

I'm not sure exactly why you're seeing the symptoms you're seeing
(working on one flavour of Unix and not another, and then working
after a crash-restart -- I guess it has something to do with
coincidences of mapped address).  That's simply not how DSA is
designed to be used: you need to create DSA areas in a non-postmaster
backend, and then attach explicitly from every other backend that
wants to access the area.  Each backend needs to get its own dsa_area
object (either by creating or attaching).

-- 
Thomas Munro
http://www.enterprisedb.com



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Regression in join selectivity estimations when usingforeign keys
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table