Brent Wood wrote:
I haven't checked to follow this up, but it seems like the sort of announcement
one might expect on 1 April.
I know that the announcement wasn't serious, but I still took it as an
opportunity to suggest in seriousness that something of value was lost when QUEL
was dropped f
Tomas Vondra writes:
> Dne 3.4.2011 02:45, Tom Lane napsal(a):
>> I wonder whether the discrepancy relates to having to produce
>> full-page-image WAL entries during the first touch of a page during the
>> pgbench run, versus having already done so in initialization. If you
>> force a checkpoint
Dne 3.4.2011 02:45, Tom Lane napsal(a):
> Tomas Vondra writes:
>> I've been playing with various wal_level settings, mainly to find out
>> what is the overhead of hot standby, and I've noticed a strange thing.
>> In some cases the wal_level=minimal produces signigicantly more xlog
>> data than wal
I haven't checked to follow this up, but it seems like the sort of announcement
one might expect on 1 April.
Brent Wood
DBA/GIS consultant
NIWA, Wellington
New Zealand
>>> Darren Duncan 04/02/11 3:01 PM >>>
I was under the impression that QUEL was actually a good language in some ways,
and that
Tomas Vondra writes:
> I've been playing with various wal_level settings, mainly to find out
> what is the overhead of hot standby, and I've noticed a strange thing.
> In some cases the wal_level=minimal produces signigicantly more xlog
> data than wal_level=archive (and hot_standby).
> ...
> Whic
Hi everyone,
I've been playing with various wal_level settings, mainly to find out
what is the overhead of hot standby, and I've noticed a strange thing.
In some cases the wal_level=minimal produces signigicantly more xlog
data than wal_level=archive (and hot_standby).
===
Scott Marlowe writes:
> On Sat, Apr 2, 2011 at 11:26 AM, Henry C. wrote:
>> Sadly, in my case, the db is so busy that autovac processes run for weeks and
>> never catch up (insufficient h/w for the app quite frankly - the addition of
>> some more SSD drives have already helped).
> Have you tried
On Sat, April 2, 2011 21:26, Scott Marlowe wrote:
> On Sat, Apr 2, 2011 at 11:26 AM, Henry C. wrote:
>
>> On Sat, April 2, 2011 14:17, Jens Wilke wrote:
>>
>>> Nevertheless since at least 8.4 IMO there's no need to bother with
>>> manual vacuum any more.
>>
>> Sadly, in my case, the db is so busy
On Samstag, 2. April 2011, Henry C. wrote:
> Sadly, in my case, the db is so busy that autovac processes run
> for weeks and never catch up
Increase the cost_limit and the HW and/or check your application, if
it's possible to reduce the amount of deletes and/or updates.
Regards, Jens
--
Sent
On Sat, Apr 2, 2011 at 11:26 AM, Henry C. wrote:
> On Sat, April 2, 2011 14:17, Jens Wilke wrote:
>> Nevertheless since at least 8.4 IMO there's no need to bother with
>> manual vacuum any more.
>
> Sadly, in my case, the db is so busy that autovac processes run for weeks and
> never catch up (ins
On Sat, April 2, 2011 14:17, Jens Wilke wrote:
> Nevertheless since at least 8.4 IMO there's no need to bother with
> manual vacuum any more.
Sadly, in my case, the db is so busy that autovac processes run for weeks and
never catch up (insufficient h/w for the app quite frankly - the addition of
s
Forgot to mention: I'm using 9.0.3
> Usually a manual vacuum cancels a running autovacuum task.
Not in my case - however, the autovac does seem to be in a waiting state.
> You should find a notice about the cancelation in th logfile.
>
> > current_query | vacuum analyze
> > age | 11:
Hi!
The pg_index, and pg_indexes is good for I get the index names, and types.
I have two indexes on test table "a":
CREATE INDEX ix1
ON a
USING btree
(a);
CREATE UNIQUE INDEX x2
ON a
USING btree
(a DESC, b);
From this I can recognize the type (unique or normal) of the index, but
Le 02/04/2011 16:06, Sven Haag a écrit :
>
> Original-Nachricht
>> Datum: Sat, 2 Apr 2011 14:17:37 +0200
>> Von: Jens Wilke
>> An: pgsql-general@postgresql.org
>> Betreff: Re: [GENERAL] Autovacuum firing up during my manual vacuum on same
>> table
>
>> On Samstag, 2. April 201
Original-Nachricht
> Datum: Sat, 2 Apr 2011 14:17:37 +0200
> Von: Jens Wilke
> An: pgsql-general@postgresql.org
> Betreff: Re: [GENERAL] Autovacuum firing up during my manual vacuum on same
> table
> On Samstag, 2. April 2011, Henry C. wrote:
>
> > I just noticed something od
On Samstag, 2. April 2011, Henry C. wrote:
> I just noticed something odd: I'm busy with a manual vacuum on a
> table and an autovacuum keeps firing up as well.
Usually a manual vacuum cancels a running autovacuum task.
You should find a notice about the cancelation in th logfile.
> current_qu
Jerry Sievers writes:
> "Sven Haag" writes:
>
>> hello pg fans,
>>
>> we have an application that communicates via ODBC directly to the
>> postgres database.
>>
>> if i'm trying to add an additional column to a table in pgadmin while
>> clients are logged in, pgadmin hangs. only if all cients ar
> Anyway, is that autovac duplicating work or locked out and waiting?
Impolitely responding to my own post: a quick strace confirms the autovac
process is indeed locked out and waiting it's turn to work.
Presumably when my manual vacuum finishes, it will then proceed and
*hopefully* not re-vacu
"Sven Haag" writes:
> hello pg fans,
>
> we have an application that communicates via ODBC directly to the
> postgres database.
>
> if i'm trying to add an additional column to a table in pgadmin while
> clients are logged in, pgadmin hangs. only if all cients are logged
> out it returns to the n
Greets,
I just noticed something odd: I'm busy with a manual vacuum on a table and an
autovacuum keeps firing up as well. Thinking this looks rather weird, I
pg_cancel_backend() the autovacuum process:
current_query | vacuum analyze page_citation_text;
age | 11:34:10.759279
...
curren
Sven Haag wrote on 02.04.2011 12:13:
if i'm trying to add an additional column to a table in pgadmin
while
clients are logged in, pgadmin hangs. only if all cients are logged
out it returns to the normal state. according to our consultant of
the application this behavior doesn't appear in oracle
yes i saw that in the documentation too. i guess it doesn't matter what kind of
lock level the odbc driver is using (row-lock)?
but how can it be, that in oracle and sqlserver this is not happening?
Original-Nachricht
> Datum: Sat, 02 Apr 2011 11:38:29 +0200
> Von: Guillaume
Le 02/04/2011 11:09, Sven Haag a écrit :
> hello pg fans,
>
> we have an application that communicates via ODBC directly to the postgres
> database.
>
> if i'm trying to add an additional column to a table in pgadmin while clients
> are logged in, pgadmin hangs. only if all cients are logged ou
hello pg fans,
we have an application that communicates via ODBC directly to the postgres
database.
if i'm trying to add an additional column to a table in pgadmin while clients
are logged in, pgadmin hangs. only if all cients are logged out it returns to
the normal state. according to our con
24 matches
Mail list logo
