Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without
От | Heikki Linnakangas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without |
Дата | |
Msg-id | 4B66AFB3.6040709@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an
operation without
|
Список | pgsql-hackers |
Heikki Linnakangas wrote: > Simon Riggs wrote: >> On Mon, 2010-02-01 at 12:11 +0200, Heikki Linnakangas wrote: >>> Simon Riggs wrote: >>>> On Mon, 2010-02-01 at 11:33 +0200, Heikki Linnakangas wrote: >>>>> Can you reproduce that? >>>> Every time >>> Ok, good :-). What I really meant was: How? >> As mentioned in first post: VACUUM FULL and CLUSTER. > > I'm asking because I couldn't reproduce it. I added an elog(LOG) to > XLogReportUnloggedStatement() so that I can see when an unlogged-record > is written. Then I ran: > > CREATE TEMPORARY TABLE foo (id int4); > VACUUM FULL foo; > > But XLogReportUnloggedStatement() was not executed. When I removed the > "TEMPORARY" and tried again, it was executed. No, hang on. When I run this: postgres=# CREATE TABLE foo (id int4); CREATE TABLE postgres=# vacuum full foo; VACUUM I get this in the log: LOG: Writing record: CLUSTER on "pg_temp_24677" STATEMENT: vacuum full foo; LOG: Writing record: heap inserts on "pg_temp_24677" STATEMENT: vacuum full foo; So you get those messages when the table is *not* a temporary table. I can see now what Fujii was trying to say. His patch seems Ok, though perhaps it would be better to move the responsibility of calling XLogReportUnloggedStatement() to the callers of heap_sync(). When I put it in heap_sync(), I didn't take into account that it's sometimes called just to flush buffers from buffer cache, not to fsync() non-WAL-logged operations. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: