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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
