From: | Markus Schiltknecht <markus(at)bluegap(dot)ch> |
---|---|
To: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: autovacuum process handling |
Date: | 2007-01-27 13:13:21 |
Message-ID: | 45BB4FF1.4090602@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Alvaro Herrera wrote:
> I haven't done that yet, since the current incarnation does not need it.
> But I have considered using some signal like SIGUSR1 to mean "something
> changed in your processes, look into your shared memory". The
> autovacuum shared memory area would contain PIDs (or maybe PGPROC
> pointers?) of workers; so when the launcher goes to check that it
> notices that one worker is no longer there, meaning that it must have
> terminated its job.
Meaning the launcher must keep a list of currently known worker PIDs and
compare that to the list in shared memory. This is doable, but quite a
lot of code for something the postmaster gets for free (i.e. SIGCHLD).
> Sure you do -- they won't corrupt anything :-) Plus, what use are
> running backends in a multimaster environment, if they can't communicate
> with the outside? Much better would be, AFAICS, to shut everyone down
> so that the users can connect to a working node.
You are right here. I'll have to recheck my code and make sure I 'take
down' the postmaster in a decent way (i.e. make it terminate it's
children immediately, so that they can't commit anymore).
>> More involved with what? It does not touch shared memory, it mainly
>> keeps track of the backends states (by getting a notice from the
>> postmaster) and does all the necessary forwarding of messages between
>> the communication system and the backends. It's main loop is similar to
>> the postmasters, mainly consisting of a select().
>
> I meant "more complicated". And if it has to listen on a socket and
> forward messages to remote backends, it certainly is a lot more
> complicated than the current autovac launcher.
That may well be. My point was, that my replication manager is so
similar to the postmaster, that it is a real PITA to do that much coding
just to make it a separate process.
>> For sure, the replication manager needs to keep running during a
>> restarting cycle. And it needs to know the database's state, so as to be
>> able to decide if it can request workers or not.
>
> I think this would be pretty easy to do if you made the remote backends
> keep state in shared memory. The manager just needs to get a signal to
> know that it should check the shared memory. This can be arranged
> easily: just have the remote backends signal the postmaster, and have
> the postmaster signal the manager. Alternatively, have the manager PID
> stored in shared memory and have the remote backends signal (SIGUSR1 or
> some such) the manager. (bgwriter does this: it announces its PID in
> shared memory, and the backends signal it when they want a CHECKPOINT).
Sounds like we run out of signals, soon. ;-)
I also have to pass around data (writesets), which is why I've come up
with that IMessage stuff. It's a per process message queue in shared
memory, using a SIGUSR1 to signal new messages. Works, but as I said, I
found myself adding messages for all the postmaster events, so that I've
really began to question what to do in which process.
Again, thanks for your inputs.
Markus
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schiltknecht | 2007-01-27 13:27:00 | Re: Proposal: Change of pg_trigger.tg_enabled and adding |
Previous Message | Magnus Hagander | 2007-01-27 12:41:56 | Re: [HACKERS] Searching some sites explaing about PosgtreSQL |