| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] WAL logging problem in 9.4.3? |
| Date: | 2018-07-18 13:29:01 |
| Message-ID: | CA+Tgmob_aF_rQmczNDUXZz2z+MksFmCyP7-3KvuauuWoS9400g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 18, 2018 at 9:06 AM, Michael Paquier <michael(at)paquier(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-07-18 13:32:46 | Re: Alter index rename concurrently to |
| Previous Message | Dean Rasheed | 2018-07-18 13:07:44 | Re: PG 10: could not generate random cancel key |