| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, 9erthalion6(at)gmail(dot)com, andrew(dot)dunstan(at)2ndquadrant(dot)com, hlinnaka(at)iki(dot)fi |
| Subject: | Re: [HACKERS] WAL logging problem in 9.4.3? |
| Date: | 2020-03-30 07:43:00 |
| Message-ID: | 20200330074300.GD43995@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Mar 29, 2020 at 09:41:01PM -0700, Noah Misch wrote:
> I think attached v41nm is ready for commit. Would anyone like to vote against
> back-patching this? It's hard to justify lack of back-patch for a data-loss
> bug, but this is atypically invasive. (I'm repeating the question, since some
> folks missed my 2020-02-18 question.) Otherwise, I'll push this on Saturday.
The invasiveness of the patch is a concern. Have you considered a
different strategy? For example, we are soon going to be in beta for
13, so you could consider committing the patch only on HEAD first.
If there are issues to take care of, you can then leverage the beta
testing to address any issues found. Finally, once some dust has
settled on the concept and we have gained enough confidence, we could
consider a back-patch. In short, my point is just that even if this
stuff is discussed for years, I see no urgency in back-patching per
the lack of complains we have in -bugs or such.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2020-03-30 07:43:04 | Re: proposal - psql output file write mode |
| Previous Message | Masahiko Sawada | 2020-03-30 07:01:18 | Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch) |