On Fri, Jun 9, 2023 at 12:23 PM Peter Geoghegan wrote:
> > I'm not sure there is that concensus (for me half the changes shouldn't be
> > done, the rest should be in 17), but in the end it doesn't matter that much.
I pushed this just now. I have also closed out the open item.
> > > --- a/src/inc
On Fri, Jun 9, 2023 at 9:40 PM Andres Freund wrote:
> I don't think minimizing heaprel being passed around is a worthwhile goal, the
> contrary actually: It just makes it painful to use heaprel anywhere, because
> it causes precisely these cascading changes of adding/removing the parameter
> to a
Hi,
On 2023-06-09 12:23:36 -0700, Peter Geoghegan wrote:
> On Fri, Jun 9, 2023 at 12:03 PM Andres Freund wrote:
> > > My new plan is to commit this tomorrow, since the clear consensus is
> > > that we should go ahead with this for 16.
> >
> > I'm not sure there is that concensus (for me half the
On Fri, Jun 9, 2023 at 12:03 PM Andres Freund wrote:
> From what I can tell it's largely consistent with other parameters of the
> respective function. E.g. btinsert(), _bt_doinsert() use camelCase for most
> parameters, so heapRel fits in. There are a few cases where it's not obvious
> what the
Hi,
On 2023-06-08 08:50:31 -0700, Peter Geoghegan wrote:
> On Thu, Jun 8, 2023 at 7:22 AM Alvaro Herrera wrote:
> > IMO this kind of change definitely does not have place in a post-beta1
> > restructuring patch. We rarely indulge in case-fixing exercises at any
> > other time, and I don't see an
On Thu, Jun 8, 2023 at 7:22 AM Alvaro Herrera wrote:
> IMO this kind of change definitely does not have place in a post-beta1
> restructuring patch. We rarely indulge in case-fixing exercises at any
> other time, and I don't see any good argument why post-beta1 is a better
> time for it.
There i
On 2023-Jun-07, Peter Geoghegan wrote:
> On Wed, Jun 7, 2023 at 5:12 PM Andres Freund wrote:
> > I don't really understand why the patch does s/heaprel/heapRel/.
>
> That has been the style used within nbtree for many years now.
IMO this kind of change definitely does not have place in a post-
On Wed, Jun 7, 2023 at 5:12 PM Andres Freund wrote:
> -1. For me separating the P_NEW path makes a lot of sense, but isn't 16
> material. I don't agree that it's a problem to have heaprel as a parameter in
> a bunch of places that don't strictly need it today.
As I've said, this is primarily abo
Hi,
On 2023-06-05 12:04:29 -0700, Peter Geoghegan wrote:
> On Sun, May 28, 2023 at 7:49 PM Heikki Linnakangas wrote:
> > IMO this makes sense for v16. These new arguments were introduced in
> > v16, so if we have second thoughts, now is the right time to change
> > them, before v16 is released. I
On 2023-Jun-05, Peter Geoghegan wrote:
> My current plan is to commit this later in the week, unless there are
> further objections. Wednesday or possibly Thursday.
I've added this as an open item for 16, with Peter and Andres as owners.
--
Álvaro Herrera PostgreSQL Developer — https:
On Sun, May 28, 2023 at 7:49 PM Heikki Linnakangas wrote:
> IMO this makes sense for v16. These new arguments were introduced in
> v16, so if we have second thoughts, now is the right time to change
> them, before v16 is released. It will reduce the backpatching effort in
> the future; if we apply
Hi,
On 5/26/23 7:28 PM, Peter Geoghegan wrote:
On Fri, May 26, 2023 at 1:56 AM Alvaro Herrera wrote:
I suppose you're not thinking of applying this to current master, but
instead just leave it for when pg17 opens, right? I mean, clearly it
seems far too invasive to put it in after beta1.
I
On 29/05/2023 03:31, Michael Paquier wrote:
On Fri, May 26, 2023 at 04:48:37PM -0700, Peter Geoghegan wrote:
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.
Hmm, okay. I was understanding that
On Fri, May 26, 2023 at 04:48:37PM -0700, Peter Geoghegan wrote:
> 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.
Hmm, okay. I was understanding that as something for v17, honestly.
> It's no
On Fri, May 26, 2023 at 4:05 PM Michael Paquier 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 refacto
On Fri, May 26, 2023 at 10:56:53AM +0200, Alvaro Herrera wrote:
> I suppose you're not thinking of applying this to current master, but
> instead just leave it for when pg17 opens, right? I mean, clearly it
> seems far too invasive to put it in after beta1. On the other hand,
> it's painful to kn
On Fri, May 26, 2023 at 2:49 PM Andres Freund wrote:
> What do we gain by not passing down the heap relation to those places?
Just clearer code, free from noisey changes. Easier when backpatching, too.
> If you're concerned about the efficiency of passing down the parameters,
> I doubt it will m
Hi,
On 2023-05-25 18:50:31 -0700, Peter Geoghegan wrote:
> Commit 61b313e4, which prepared index access method code for the
> logical decoding on standbys work, made quite a few mechanical
> changes. Many routines were revised in order to make sure that heaprel
> was available in _bt_getbuf()'s P_
On Fri, May 26, 2023 at 10:28 AM Peter Geoghegan wrote:
> I've added several defensive assertions that make it hard to get the
> details wrong. These will catch the issue much earlier than the main
> "heapRel != NULL" assertion in _bt_allocbuf(). So, the rules are
> reasonably straightforward and
On Fri, May 26, 2023 at 1:56 AM Alvaro Herrera wrote:
> I suppose you're not thinking of applying this to current master, but
> instead just leave it for when pg17 opens, right? I mean, clearly it
> seems far too invasive to put it in after beta1.
I was planning on targeting 16 with this. Althou
On Fri, May 26, 2023 at 12:46 AM Michael Paquier wrote:
> Nice cleanup overall.
Thanks.
To be clear, when I said "it would be nice to get rid of P_NEW", what
I meant was that it would be nice to go much further than what I've
done in the patch by getting rid of the general idea of P_NEW. So the
On 2023-May-25, Peter Geoghegan wrote:
> Attached patch completely removes the changes to _bt_getbuf()'s
> signature from 61b313e4.
I suppose you're not thinking of applying this to current master, but
instead just leave it for when pg17 opens, right? I mean, clearly it
seems far too invasive to
On Thu, May 25, 2023 at 06:50:31PM -0700, Peter Geoghegan wrote:
> It's possible that Bertand would have done it this way to begin with
> were it not for the admittedly pretty bad nbtree convention around
> P_NEW. It would be nice to get rid of P_NEW in the near future, too --
> I gather that there
23 matches
Mail list logo
