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 und
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 fo
terial 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
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
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_NEW (new page allocation) path. But
this went further than it real
24 matches
Mail list logo
