Re: Unlogged tables cleanup

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unlogged tables cleanup
Date: 2016-11-17 03:09:46
Message-ID: CA+Tgmoawk+XaWk9yKWJY2vUgbCBnOBODAjurbZQBcyoxg+N5Zg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 16, 2016 at 3:54 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Nov 16, 2016 at 11:45 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> The header comment for heap_create_init_fork() says this:
>>
>> /*
>> * Set up an init fork for an unlogged table so that it can be correctly
>> * reinitialized on restart. Since we're going to do an immediate sync, we
>> * only need to xlog this if archiving or streaming is enabled. And the
>> * immediate sync is required, because otherwise there's no guarantee that
>> * this will hit the disk before the next checkpoint moves the redo pointer.
>> */
>>
>> Your patch causes the code not to match the comment any more. And the
>> comment explains why at the time I wrote this code I thought it was OK
>> to have the XLogIsNeeded() test in there, so it clearly needs
>> updating.
>
> Indeed I missed this comment block. Please let me suggest the following instead:
> /*
> * Set up an init fork for an unlogged table so that it can be correctly
> - * reinitialized on restart. Since we're going to do an immediate sync, we
> - * only need to xlog this if archiving or streaming is enabled. And the
> - * immediate sync is required, because otherwise there's no guarantee that
> - * this will hit the disk before the next checkpoint moves the redo pointer.
> + * reinitialized on restart. An immediate sync is required even if the
> + * page has been logged, because the write did not go through
> + * shared_buffers and therefore a concurrent checkpoint may have moved
> + * the redo pointer past our xlog record.
> */

Hmm. Well, that deletes the comment that's no longer true, but it
doesn't replace it with any explanation of why we also need to WAL-log
it unconditionally, and I think that explanation is not entirely
trivial?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-11-17 03:14:47 Re: pg_dump versus rules, once again
Previous Message Robert Haas 2016-11-17 03:06:43 Re: pg_dump versus rules, once again