On Mon, Aug 31, 2009 at 21:49, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Well, I'm not sure the average user knows or cares about the difference
>>> between the launcher and the workers. The thing that was in the back of
>>> my mind was that we would now have the option to h
Hi,
Tom Lane writes:
>> The user may not care about the difference, but there's a point in
>> having the limit be the simpler concept of "this is the maximum amount
>> of processes running vacuum at any time". The launcher is very
>> uninteresting to users.
Adding to this, the launcher will not
Alvaro Herrera writes:
> Tom Lane wrote:
>> Well, I'm not sure the average user knows or cares about the difference
>> between the launcher and the workers. The thing that was in the back of
>> my mind was that we would now have the option to have the launcher show
>> up in pg_stat_activity. If
Alvaro Herrera writes:
> The only thing I'm aware is missing from this patch is fixing up
> avlauncher's signal handling, and adding a bit more commentary; also I
> haven't tested it under EXEC_BACKEND yet.
I did the signal handling work and fixed a couple of small oversights,
and applied it. I'
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> I wonder if it would be cleaner to include the launcher in
> >> the autovacuum_max_workers parameter, and increase the min/default
> >> values of that by one.
>
> > Huh, yeah, sorry about that -- fixed here. I think the name of th
Tom Lane wrote:
> Actually, there is a better way to do this: if we move up the
> RelationCacheInitializePhase2 call, then we can have the AV launcher
> case just fall out *before* the transaction start. It can do
> GetTransactionSnapshot inside its own transaction that reads
> pg_database. This
Alvaro Herrera writes:
> Tom Lane wrote:
>> While I was looking at this I wondered whether
>> RelationCacheInitializePhase2 really needs to be inside the startup
>> transaction at all. I think it could probably be moved up before
>> that. However, if the AV launcher has to do GetTransactionSnaps
Alvaro Herrera writes:
> Tom Lane wrote:
>> I wonder if it would be cleaner to include the launcher in
>> the autovacuum_max_workers parameter, and increase the min/default
>> values of that by one.
> Huh, yeah, sorry about that -- fixed here. I think the name of the
> param, which includes "wor
Tom Lane wrote:
> Alvaro Herrera writes:
> > How about this?
>
> I think the accounting for the AV launcher in shmem allocation is a bit
> confused yet --- for instance, isn't MaxBackends already including the
> launcher? I wonder if it would be cleaner to include the launcher in
> the autovacuu
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> I quite like the idea of splitting initialization into two phases, one
>> that let's you access shared catalogs, and one to bind to a database. I
>> didn't look into the details, though.
> The problem is that it only gives you access to pg_dat
Alvaro Herrera writes:
> How about this?
I think the accounting for the AV launcher in shmem allocation is a bit
confused yet --- for instance, isn't MaxBackends already including the
launcher? I wonder if it would be cleaner to include the launcher in
the autovacuum_max_workers parameter, and i
Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Tom Lane wrote:
> >>> This just seems truly messy :-(. Let me see if I can find something
> >>> cleaner.
>
> I quite like the idea of splitting initialization into two phases, one
> that let's you access shared catalogs,
Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> This just seems truly messy :-(. Let me see if I can find something
>>> cleaner.
I quite like the idea of splitting initialization into two phases, one
that let's you access shared catalogs, and one to bind to a database. I
didn't l
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> This just seems truly messy :-(. Let me see if I can find something
> >> cleaner.
>
> > I was considering having InitPostgres be an umbrella function, so that
> > extant callers stay as today, but the various underlying pieces are
Alvaro Herrera writes:
> Tom Lane wrote:
>> This just seems truly messy :-(. Let me see if I can find something
>> cleaner.
> I was considering having InitPostgres be an umbrella function, so that
> extant callers stay as today, but the various underlying pieces are
> skipped depending on who's
Tom Lane wrote:
> Alvaro Herrera writes:
> > To this end, InitPostgres has been split in two. The launcher only
> > calls the first half, the rest of the callers have been patched to
> > invoke the second half.
>
> This just seems truly messy :-(. Let me see if I can find something
> cleaner.
Alvaro Herrera writes:
> To this end, InitPostgres has been split in two. The launcher only
> calls the first half, the rest of the callers have been patched to
> invoke the second half.
This just seems truly messy :-(. Let me see if I can find something
cleaner.
BTW, is it *really* the case t
Hi,
This seems to be the last holdup for flatfiles.c. This patch removes
usage of that code in autovacuum launcher, instead making it go through
the most basic relcache initialization so that it is able to read
pg_database.
To this end, InitPostgres has been split in two. The launcher only
call
18 matches
Mail list logo
