Re: Curious about dead rows. - Mailing list pgsql-performance

From Andrew Sullivan
Subject Re: Curious about dead rows.
Date
Msg-id 20071113221028.GH11563@crankycanuck.ca
Whole thread Raw
In response to Re: Curious about dead rows.  (Andrew Sullivan <ajs@crankycanuck.ca>)
Responses Re: Curious about dead rows.  (Jean-David Beyer <jeandavid8@verizon.net>)
List pgsql-performance
I'm not a private support organisation; please send your replies to the
list, not me.

On Tue, Nov 13, 2007 at 04:57:23PM -0500, Jean-David Beyer wrote:
> What is it controlled by? The following are the non-default values in
> postgresql.conf:
>
> redirect_stderr = on
> log_directory = '/srv/dbms/dataB/pgsql/pg_log'
> log_filename = 'postgresql-%a.log'
> log_truncate_on_rotation = on
> log_rotation_age = 1440
> log_rotation_size = 0
> log_min_messages = debug2

This will certainly include error messages, then.  Or it ought to.  You do
see errors in the log when you create one, right?  (Try causing an error in
psql to make sure.)

> log_line_prefix = '%t '
> log_statement = 'none'   (this was 'mod', but it uses too much
>                           disk to leave it turned on -- only
>                           4 GBytes in that partition)
>
> >
> They are; they are the primary keys of two tables. But those are all done
> before the last VACUUM FULL ANALYZE runs, so the dead rows should have been
> eliminated. And the output of the sequence is the only way of generating a
> primary key, so it should be impossible anyhow.

I thought you were doing INSERTs?  It's not true that the output of the
sequence is the only way -- if you insert directly, it will happily insert
into that column.  But it should cause an error to show in the log, which is
what's puzzling me.

A

--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke

pgsql-performance by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Curious about dead rows.
Next
From: Jean-David Beyer
Date:
Subject: Re: Curious about dead rows.