| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Cleaning up nbtree after logical decoding on standby work |
| Date: | 2023-05-26 23:48:37 |
| Message-ID: | CAH2-WzkX-RAhGbkzgLLxCeOGtb1_Fr-GeSr=ijdnHC1Gb2SF+Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 26, 2023 at 4:05 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Fri, May 26, 2023 at 10:56:53AM +0200, Alvaro Herrera wrote:
> > I can't make up my mind about this. What do others think?
>
> When I looked at the patch yesterday, my impression was that this
> would be material for v17 as it is refactoring work, not v16.
I'd have thought the subject line "Cleaning up nbtree after logical
decoding on standby work" made it quite clear that this patch was
targeting 16.
It's not refactoring work -- not really. The whole idea of outright
removing the use of P_NEW in nbtree was where I landed with this after
a couple of hours of work. In fact I almost posted a version without
that, though that was worse in every way to my final approach.
I first voiced concerns about this whole area way back on April 4,
which is only 3 days after commit 61b313e4 went in:
https://postgr.es/m/CAH2-Wz=jGryxWm74G1khSt0zNPUNhezYJnvSjNo2t3Jswtb8ww@mail.gmail.com
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2023-05-27 00:35:24 | Re: Implement generalized sub routine find_in_log for tap test |
| Previous Message | Jeff Davis | 2023-05-26 23:21:50 | Fix search_path for all maintenance commands |