Tom Lane wrote:
What was sort of in the back of my mind was to have every n'th AV worker
examine pg_database and report back to the launcher (probably through
shared memory) with an indication of the next few databases that should
be vacuumed and when. Not sure how inefficient that might be
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Is there a real downside to promoting the launcher to be a
pseudo-backend?
Aside from the fact that we don't have any pseudo-backend yet, I don't
see any ...
Well, I meant pseudo-backend in the sense of just like an AV
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Is there a real downside to promoting the launcher to be a
pseudo-backend?
Aside from the fact that we don't have any pseudo-backend yet, I don't
see any ...
Well, I meant pseudo-backend in the sense
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Well, I meant pseudo-backend in the sense of just like an AV worker.
We might not want it to show in pg_stat_activity, but otherwise I think
it'd be the same.
Hmm, to what database would it connect?
Well, it wouldn't. As of
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, to what database would it connect?
Well, it wouldn't. As of the patch I'm working on, it's okay to have
PGPROC entries showing zero in databaseId. Normally they'd be backends
that weren't done starting yet, but I see
Alvaro Herrera alvhe...@commandprompt.com writes:
Are you going to commit the current patch? We can remove the hacks that
support autovacuum later. I was thinking that InitPostgres could be
split in two, with the first half ending just after
RelationCacheInitializePhase2. Then workers could
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
(BTW I assume there is going to be an index on OID
available on pg_database after the shared relcache initialization?)
Yeah. That's not in the patch I sent last night, but the OID index has
to become nailed too in order
Alvaro Herrera alvhe...@commandprompt.com writes:
No, that's for the workers. The launcher needs all the entries anyway.
(I'm assuming it will be able to check visibility of tuples, correct?
Hmm, it will need to run transactions in order to do that ...)
No, you don't need to be in a
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
No, that's for the workers. The launcher needs all the entries anyway.
(I'm assuming it will be able to check visibility of tuples, correct?
Hmm, it will need to run transactions in order to do that ...)
I realize I'm jumping into the
In the discussion of bug #4919 I wrote:
In some sense this is a bootstrap problem: what does it take to get to
the point of being able to read pg_database and its indexes? That is
necessarily not dependent on the particular database we want to join.
Maybe we could solve it by having the
Tom Lane wrote:
I'd also like to look into getting rid of the pg_auth flat file.
That would be sad for many users of pgbouncer.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I'd also like to look into getting rid of the pg_auth flat file.
That would be sad for many users of pgbouncer.
Really? And how would pgbouncer be depending on that?
regards, tom lane
--
Sent via
On Wednesday 12 August 2009 02:30:53 Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I'd also like to look into getting rid of the pg_auth flat file.
That would be sad for many users of pgbouncer.
Really? And how would pgbouncer be depending on that?
One can
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I'd also like to look into getting rid of the pg_auth flat file.
That would be sad for many users of pgbouncer.
Really? And how would pgbouncer be depending on that?
auth_file
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Really? And how would pgbouncer be depending on that?
auth_file
The name of the file to load user names and passwords from. The file format
is the same as the PostgreSQL pg_auth/pg_pwd file, so this setting can be
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
To actually get rid of the pg_database flat file, we'd need to take the
further step of teaching the AV launcher to read pg_database for itself,
or else refactor things so that the AV workers can do that for it.
(Alvaro, any
Tom Lane wrote:
To actually get rid of the pg_database flat file, we'd need to take the
further step of teaching the AV launcher to read pg_database for itself,
or else refactor things so that the AV workers can do that for it.
(Alvaro, any comments about the best way to proceed there?)
Hmm.
17 matches
Mail list logo
