Re: [HACKERS] Unlogged tables cleanup - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Unlogged tables cleanup
Date
Msg-id CAB7nPqTte6hQ5sKR3E1AwnsT7Ky_-6v6FZtL6QBTL37umZJj2Q@mail.gmail.com
Whole thread Raw
In response to Re: Unlogged tables cleanup  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Unlogged tables cleanup
List pgsql-hackers
On Fri, Dec 9, 2016 at 4:54 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Dec 7, 2016 at 11:20 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> OK, I rewrote a bit the patch as attached. What do you think?
>
> Committed and back-patched all the way back to 9.2.

Thanks!

>>> Right (I think).  If we set and clear delayChkpt around this work, we
>>> don't need the immediate sync.
>>
>> My point is a bit different than what you mean I think: the
>> transaction creating an unlogged relfilenode would not need to even
>> set delayChkpt in the empty() routines because other transactions
>> would not refer to it until this transaction has committed. So I am
>> arguing about just removing the sync phase.
>
> That doesn't sound right; see the comment for heap_create_init_fork.
> Suppose the transaction creating the unlogged table commits, a
> checkpoint happens, and then the operating system crashes.  Without
> the immediate sync, the operating system crash can cause the un-sync'd
> file to crash, and because of the checkpoint the WAL record that
> creates it isn't replayed either.  So the file's just gone.

Doh. That would have made sense if the checkpoint was actually
flushing the page if it was in shared buffers. But that's not the
case.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Proposal for changes to recovery.conf API
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: [HACKERS] Declarative partitioning - another take