Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
To: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: <20180704045912.GG1672@paquier.xyz>
 <df32e286-ae2b-f45a-8f2e-4fa02684300b@iki.fi>
 <20180711033241.GQ1661@paquier.xyz>
 <aac8e19b-9159-e473-77be-53f80b658190@2ndQuadrant.com>
 <08b11907-d0b2-c396-2978-ba5aac1972df@iki.fi>
 <CA+TgmoZGn7MmMGRu4NkfxyXKSCzmvq1JvqsWm=hN=GJDMTfTKg@mail.gmail.com>
 <026AD6A1-3396-47F4-B87E-77E3F139D166@iki.fi>
 <20180717000129.GA3388@paquier.xyz>
 <3c1cf991-8846-9a6f-c669-e21f8ea9a6a4@2ndQuadrant.com>
 <CA+TgmoZU9nBd6m3NQohzjpdvBNtw+6UGoz+uqoaawkXy76gYSg@mail.gmail.com>
 <20180718130622.GI8565@paquier.xyz>
 <CA+Tgmob_aF_rQmczNDUXZz2z+MksFmCyP7-3KvuauuWoS9400g@mail.gmail.com>
From: Heikki Linnakangas <hlinnaka@iki.fi>
Message-ID: <c7d2ca8a-d376-f19b-e95e-b879efc3b860@iki.fi>
Date: Wed, 18 Jul 2018 17:58:16 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
 <CA+Tgmob_aF_rQmczNDUXZz2z+MksFmCyP7-3KvuauuWoS9400g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 18/07/18 16:29, Robert Haas wrote:
> On Wed, Jul 18, 2018 at 9:06 AM, Michael Paquier <michael@paquier.xyz> wrote:
>>> What's wrong with the approach proposed in
>>> http://postgr.es/m/55AFC302.1060805@iki.fi ?
>>
>> For back-branches that's very invasive so that seems risky to me
>> particularly seeing the low number of complaints on the matter.
> 
> Hmm. I think that if you disable the optimization, you're betting that
> people won't mind losing performance in this case in a maintenance
> release.  If you back-patch Heikki's approach, you're betting that the
> committed version doesn't have any bugs that are worse than the status
> quo.  Personally, I'd rather take the latter bet.  Maybe the patch
> isn't all there yet, but that seems like something we can work
> towards.  If we just give up and disable the optimization, we won't
> know how many people we ticked off or how badly until after we've done
> it.

Yeah. I'm not happy about backpatching a big patch like what I proposed, 
and Kyotaro developed further. But I think it's the least bad option we 
have, the other options discussed seem even worse.

One way to review the patch is to look at what it changes, when 
wal_level is *not* set to minimal, i.e. what risk or overhead does it 
pose to users who are not affected by this bug? It seems pretty safe to me.

The other aspect is, how confident are we that this actually fixes the 
bug, with least impact to users using wal_level='minimal'? I think it's 
the best shot we have so far. All the other proposals either don't fully 
fix the bug, or hurt performance in some legit cases.

I'd suggest that we continue based on the patch that Kyotaro posted at 
https://www.postgresql.org/message-id/20180330.100646.86008470.horiguchi.kyotaro%40lab.ntt.co.jp.

- Heikki