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 PGP
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>>> For Postgres-R, I'm currently questioning if I shouldn't merge the
>>> replication manager process with the postmaster. Of course, that would
>>> violate the "postmaster does not touch shared memory" constraint.
>>
>> I
Markus Schiltknecht wrote:
> Hi,
>
> Alvaro Herrera wrote:
> >Yeah. For what I need, the launcher just needs to know when a worker
> >has finished and how many workers there are.
>
> Oh, so it's not all that less communication. My replication manager also
> needs to know when a worker dies. You
Hi,
Alvaro Herrera wrote:
Yeah. For what I need, the launcher just needs to know when a worker
has finished and how many workers there are.
Oh, so it's not all that less communication. My replication manager also
needs to know when a worker dies. You said you are using a signal from
manager
Markus Schiltknecht wrote:
Hi Markus,
>
> Alvaro Herrera wrote:
> >1. There will be two kinds of processes, "autovacuum launcher" and
> >"autovacuum worker".
>
> Sounds similar to what I do in Postgres-R: one replication manager and
> several "replication workers". Those are called "remote bac
Hi,
Alvaro Herrera wrote:
1. There will be two kinds of processes, "autovacuum launcher" and
"autovacuum worker".
Sounds similar to what I do in Postgres-R: one replication manager and
several "replication workers". Those are called "remote backends" (which
is somewhat of an unfortunate name
Jim C. Nasby wrote:
> On Mon, Jan 22, 2007 at 04:24:28PM -0300, Alvaro Herrera wrote:
> > 4. Launcher will be a continuously-running process, akin to bgwriter;
> > connected to shared memory
>
> So would it use up a database connection?
No. It's connected to shared memory and has access to pgst
On Mon, Jan 22, 2007 at 04:24:28PM -0300, Alvaro Herrera wrote:
> 4. Launcher will be a continuously-running process, akin to bgwriter;
> connected to shared memory
So would it use up a database connection?
> 5. Workers will be direct postmaster children; so postmaster will get
> SIGCHLD when wo
Alvaro Herrera wrote:
This is how I think autovacuum should change with an eye towards being
able to run multiple vacuums simultaneously:
[snip details]
Does this raise some red flags? It seems straightforward enough to me;
I'll submit a patch implementing this, so that scheduling will conti
Hi,
This is how I think autovacuum should change with an eye towards being
able to run multiple vacuums simultaneously:
1. There will be two kinds of processes, "autovacuum launcher" and
"autovacuum worker".
2. The launcher will be in charge of scheduling and will tell workers
what to do
3. The
10 matches
Mail list logo
