>>> On Sat, Mar 25, 2006 at 8:40 pm, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Jerry Sievers <[EMAIL PROTECTED]> writes:
>> At any rate; I'm wondering what possible causes might be
responsible
>> for pg_stat_activity's underlying functions to lose track of the
valid
>>
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> Is there any way to tweak this in favor of more accurate information,
> even if has a performance cost? We're finding that during normal
> operations we're not seeing most connections added to the
> pg_stat_activity table. We would like to be able to
adey wrote:
> > 2) Can vacuum full not be redesigned to run online without locking tables
> > and users,
This is already done. See non-FULL VACUUM.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
> | Do you see any problem in the current approach ?
> | i have seen it working fine till now.
>
> I do, to be honest. The WAL location counter accounts for 4294967295
> positions and while I'm certain that's WAY more than the average number
> of transactions that go into a WAL, quite a number of
Hello all,
I've been trying to figure a few things lately but I could not so I'm
asking on the list. I need to programmatically (through JDBC):
1. Figure out if the currently logged in user can create a schema
2. Figure out if a role has USAGE privileges on a schema
3. Figure out if a role has
Milen Dzhumerov <[EMAIL PROTECTED]> writes:
> I've been trying to figure a few things lately but I could not so I'm
> asking on the list. I need to programmatically (through JDBC):
> 1. Figure out if the currently logged in user can create a schema
> 2. Figure out if a role has USAGE privileges o
On Mar 31, 2006, at 5:45 PM, Matthew T. O'Connor wrote:
I think the closest approximation of disabling autovacuum on a
per database basis is to connect to the database in question and
perform:
update pg_autovacuum set enabled = 'false';
This will prevent autovacuum from vacuuming or analyzi
On Mar 31, 2006, at 9:29 PM, Tom Lane wrote:
"Matthew T. O'Connor" writes:
I think the closest approximation of disabling autovacuum on a per
database basis is to connect to the database in question and perform:
update pg_autovacuum set enabled = 'false';
Not really gonna help unless you ins
On Apr 2, 2006, at 11:39 PM, Tom Lane wrote:
I don't think we will see much people losing data to Xid wraparound
anymore, now that the server refuses to work when the wraparound is
imminent.
Well, how about the second or third time we get sued by someone whose
"must be up 24x7" database shuts
Jim Nasby <[EMAIL PROTECTED]> writes:
> The problem with that is unless I missed a change in 8.1, autovac
> knows absolutely nothing about when manual vacuums have been run.
It knows perfectly well about full-database vacuums (because those
set pg_database.datvacuumxid), and by the end of the we
John DeSoi <[EMAIL PROTECTED]> writes:
> My reason for wanting to turn it off is that every time it would run
> the fans on my development system would rev up.
Well, I have an equally lame reason for wanting to not run autovac:
it'll interfere with profiling because the autovac daemon will drop
>>> On Mon, Apr 3, 2006 at 11:52 am, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Is there any way to tweak this in favor of more accurate
information,
>> even if has a performance cost? We're finding that during normal
>> o
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> It is probably related to something we've been seeing in the PostgreSQL
> logs on the Windows servers:
> [2006-04-03 08:28:25.990 ] 2072 FATAL: could not read from statistics
> collector pipe: No error
> [2006-04-03 08:28:26.068 ] 2012 LOG: statisti
13 matches
Mail list logo
