Processes and caches in postgresql
Hi, hackers.
There's a couple of questions about processes.
I found EXEC_BACKEND flag, while reading the code.
As I understood, it exists because we have to emulate fork() on WIN32.
And also it allows to debug the same behavior on Linux.
Is it right? Are there any other use cases?
Another question is about "--fork" argument (see code below).
I didn't find it in documentation, so I'm a bit confused.
I wonder if it exists only for internal purposes?
#ifdef EXEC_BACKEND
if (argc > 1 && strncmp(argv[1], "--fork", 6) == 0)
SubPostmasterMain(argc, argv); /* does not return */
#endif
And the last, but not least. Do we have any
presentations/articles/READMEs/whatever
about caches (src/backend/utils/cache/*) in postgresql?
I found nothing, besides comments in the code.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 27, 2016 at 7:07 AM, Anastasia Lubennikova
<a.lubennikova@postgrespro.ru> wrote:
Hi, hackers.
There's a couple of questions about processes.I found EXEC_BACKEND flag, while reading the code.
As I understood, it exists because we have to emulate fork() on WIN32.
And also it allows to debug the same behavior on Linux.
Is it right? Are there any other use cases?
Right. Or, more precisely, we can't really emulate fork(), so we have
to make due with what's available on Windows, which is basically
exec().
Another question is about "--fork" argument (see code below).
I didn't find it in documentation, so I'm a bit confused.
I wonder if it exists only for internal purposes?
Correct. Just for internal purposes only - definitely not intended
for users to invoke directly.
And the last, but not least. Do we have any
presentations/articles/READMEs/whatever
about caches (src/backend/utils/cache/*) in postgresql?
I found nothing, besides comments in the code.
Nothing specific comes to mind.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 2, 2016 at 7:36 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Apr 27, 2016 at 7:07 AM, Anastasia Lubennikova
<a.lubennikova@postgrespro.ru> wrote:Hi, hackers.
There's a couple of questions about processes.I found EXEC_BACKEND flag, while reading the code.
As I understood, it exists because we have to emulate fork() on WIN32.
And also it allows to debug the same behavior on Linux.
Is it right? Are there any other use cases?Right. Or, more precisely, we can't really emulate fork(), so we have
to make due with what's available on Windows, which is basically
exec().
There is library out there, unfortunately GPL licensed, that attempts
to fully implement posix including fork(): http://midipix.org/. One
of these days I'd like to have a go at porting postgres to it. Maybe
one day we can get rid of all that exec backend stuff :-).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3 May 2016 at 21:37, Merlin Moncure <mmoncure@gmail.com> wrote:
There is library out there, unfortunately GPL licensed, that attempts
to fully implement posix including fork(): http://midipix.org/. One
of these days I'd like to have a go at porting postgres to it.
... and here I thought you'd be keen to instead remove all use of globals
and 'static' locals to allow thread-safe state tracking, remove use of
shmem, introduce threaded backends, replace use of signals, and release
ThreadedPostgres.
Sounds fun, right? :p
More seriously, shouldn't Microsoft's new (or at least re-blessed and
re-released with a new paint job) Linux/POSIX support offer us some options
here? I suspect not - they're probably restricted to ELF binaries that
won't be able to link to native Windows DLLs to get support for things like
SSPI auth, native Windows SSL API use, etc. But it's worth keeping the
possibility in mind.
Frankly, a library that implements fork() might cause exciting explosions
when using native Windows services, too.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 03/05/16 16:35, Craig Ringer wrote:
On 3 May 2016 at 21:37, Merlin Moncure <mmoncure@gmail.com
<mailto:mmoncure@gmail.com>> wrote:There is library out there, unfortunately GPL licensed, that attempts
to fully implement posix including fork(): http://midipix.org/. One
of these days I'd like to have a go at porting postgres to it.... and here I thought you'd be keen to instead remove all use of
globals and 'static' locals to allow thread-safe state tracking, remove
use of shmem, introduce threaded backends, replace use of signals, and
release ThreadedPostgres.Sounds fun, right? :p
More seriously, shouldn't Microsoft's new (or at least re-blessed and
re-released with a new paint job) Linux/POSIX support offer us some
options here? I suspect not - they're probably restricted to ELF
binaries that won't be able to link to native Windows DLLs to get
support for things like SSPI auth, native Windows SSL API use, etc. But
it's worth keeping the possibility in mind.
Yes the linux emulation is restricted to it's own world, it can't access
any windows native binaries.
The other thing is that MS repeatedly said that they plan this as purely
developer feature and you should not use it for deploying anything.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers