Re: Curious about dead rows.
От | Andrew Sullivan |
---|---|
Тема | Re: Curious about dead rows. |
Дата | |
Msg-id | 20071113221028.GH11563@crankycanuck.ca обсуждение исходный текст |
Ответ на | Re: Curious about dead rows. (Andrew Sullivan <ajs@crankycanuck.ca>) |
Ответы |
Re: Curious about dead rows.
|
Список | 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 по дате отправления: