pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Fix more holes with SLRU code in need of int64 for segment numbe
18+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2024-08-19 bd06cc338d b7935bc10b Fix more holes with SLRU code in need of int64 for segment numbers
* pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-07-26 22:24 Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 18+ messages in thread
From: Michael Paquier @ 2024-07-26 22:24 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix more holes with SLRU code in need of int64 for segment numbers
This is a continuation of 3937cadfd438, taking care of more areas I have
managed to miss previously.
Reported-by: Noah Misch
Reviewed-by: Noah Misch
Discussion: https://postgr.es/m/20240724130059.1f.nmisch@google.com
Backpatch-through: 17
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/e367a413b09fece55ce4e08872ce79f328941ddd
Modified Files
--------------
src/backend/access/transam/multixact.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
^ permalink raw reply [nested|flat] 18+ messages in thread
* pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-07-26 22:24 Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 18+ messages in thread
From: Michael Paquier @ 2024-07-26 22:24 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix more holes with SLRU code in need of int64 for segment numbers
This is a continuation of 3937cadfd438, taking care of more areas I have
managed to miss previously.
Reported-by: Noah Misch
Reviewed-by: Noah Misch
Discussion: https://postgr.es/m/20240724130059.1f.nmisch@google.com
Backpatch-through: 17
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/c9e24573905bef7fc3e4efb02bdb4d0cc8e43c51
Modified Files
--------------
src/backend/access/transam/multixact.c | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-07 09:07 Peter Eisentraut <peter@eisentraut.org>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 18+ messages in thread
From: Peter Eisentraut @ 2024-08-07 09:07 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; pgsql-committers@lists.postgresql.org
On 27.07.24 00:24, Michael Paquier wrote:
> Fix more holes with SLRU code in need of int64 for segment numbers
>
> This is a continuation of 3937cadfd438, taking care of more areas I have
> managed to miss previously.
>
> Reported-by: Noah Misch
> Reviewed-by: Noah Misch
> Discussion: https://postgr.es/m/20240724130059.1f.nmisch@google.com
> Backpatch-through: 17
>
> Branch
> ------
> master
>
> Details
> -------
> https://git.postgresql.org/pg/commitdiff/c9e24573905bef7fc3e4efb02bdb4d0cc8e43c51
I don't understand this patch. The previous patches that this
references changed various variables to int64 and made adjustments
following from that. But this patch takes variables and function
results that are of type int and casts them to unsigned long long before
printing. I don't see what that accomplishes, and it's not clear based
on just the explanation that this is a continuation of a previous patch
that doesn't do that. Is there a plan to change these things to int64
as well at some point?
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-07 15:53 Alexander Korotkov <aekorotkov@gmail.com>
parent: Peter Eisentraut <peter@eisentraut.org>
0 siblings, 1 reply; 18+ messages in thread
From: Alexander Korotkov @ 2024-08-07 15:53 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: Michael Paquier <michael@paquier.xyz>; pgsql-committers@lists.postgresql.org
On Wed, Aug 7, 2024 at 12:07 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 27.07.24 00:24, Michael Paquier wrote:
> > Fix more holes with SLRU code in need of int64 for segment numbers
> >
> > This is a continuation of 3937cadfd438, taking care of more areas I have
> > managed to miss previously.
> >
> > Reported-by: Noah Misch
> > Reviewed-by: Noah Misch
> > Discussion: https://postgr.es/m/20240724130059.1f.nmisch@google.com
> > Backpatch-through: 17
> >
> > Branch
> > ------
> > master
> >
> > Details
> > -------
> > https://git.postgresql.org/pg/commitdiff/c9e24573905bef7fc3e4efb02bdb4d0cc8e43c51
>
> I don't understand this patch. The previous patches that this
> references changed various variables to int64 and made adjustments
> following from that. But this patch takes variables and function
> results that are of type int and casts them to unsigned long long before
> printing. I don't see what that accomplishes, and it's not clear based
> on just the explanation that this is a continuation of a previous patch
> that doesn't do that. Is there a plan to change these things to int64
> as well at some point?
There is a plan indeed. The patchset [1] should include conversion
multixacts to 64-bit (It surely included that in earlier versions, I
didn't look the last versions though). I doubt this will be ready for
v18. So this commit might be quite preliminary. But I would prefer
to leave it there as soon as it has already landed. Opinions?
Links.
1. https://www.postgresql.org/message-id/CAJ7c6TND0bCnwU1SmxTsFewK4XJGBep343vf%2BT%2BGQ-a5S5hC0w%40mail...
------
Regards,
Alexander Korotkov
Supabase
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-07 19:52 Peter Eisentraut <peter@eisentraut.org>
parent: Alexander Korotkov <aekorotkov@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Peter Eisentraut @ 2024-08-07 19:52 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; pgsql-committers@lists.postgresql.org
On 07.08.24 17:53, Alexander Korotkov wrote:
> On Wed, Aug 7, 2024 at 12:07 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>> On 27.07.24 00:24, Michael Paquier wrote:
>>> Fix more holes with SLRU code in need of int64 for segment numbers
>>>
>>> This is a continuation of 3937cadfd438, taking care of more areas I have
>>> managed to miss previously.
>>>
>>> Reported-by: Noah Misch
>>> Reviewed-by: Noah Misch
>>> Discussion: https://postgr.es/m/20240724130059.1f.nmisch@google.com
>>> Backpatch-through: 17
>>>
>>> Branch
>>> ------
>>> master
>>>
>>> Details
>>> -------
>>> https://git.postgresql.org/pg/commitdiff/c9e24573905bef7fc3e4efb02bdb4d0cc8e43c51
>>
>> I don't understand this patch. The previous patches that this
>> references changed various variables to int64 and made adjustments
>> following from that. But this patch takes variables and function
>> results that are of type int and casts them to unsigned long long before
>> printing. I don't see what that accomplishes, and it's not clear based
>> on just the explanation that this is a continuation of a previous patch
>> that doesn't do that. Is there a plan to change these things to int64
>> as well at some point?
>
> There is a plan indeed. The patchset [1] should include conversion
> multixacts to 64-bit (It surely included that in earlier versions, I
> didn't look the last versions though). I doubt this will be ready for
> v18. So this commit might be quite preliminary. But I would prefer
> to leave it there as soon as it has already landed. Opinions?
I think you should change the output formats at the same time as you
change the variable types. That way the compiler can cross-check this.
Otherwise, if you later forget to change a variable, these casts will
hide it. Or if the future patches turn out differently, then we have
this useless code.
> Links.
> 1. https://www.postgresql.org/message-id/CAJ7c6TND0bCnwU1SmxTsFewK4XJGBep343vf%2BT%2BGQ-a5S5hC0w%40mail...
It looks like the commit I'm talking about here is a subset of v55-0001
from that thread? So why is some of this being committed now into v17?
But as I wrote above, I think this approach is a bad idea.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-07 20:04 Alexander Korotkov <aekorotkov@gmail.com>
parent: Peter Eisentraut <peter@eisentraut.org>
0 siblings, 0 replies; 18+ messages in thread
From: Alexander Korotkov @ 2024-08-07 20:04 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: Michael Paquier <michael@paquier.xyz>; pgsql-committers@lists.postgresql.org
On Wed, Aug 7, 2024 at 10:52 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 07.08.24 17:53, Alexander Korotkov wrote:
> > On Wed, Aug 7, 2024 at 12:07 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> >> On 27.07.24 00:24, Michael Paquier wrote:
> >>> Fix more holes with SLRU code in need of int64 for segment numbers
> >>>
> >>> This is a continuation of 3937cadfd438, taking care of more areas I have
> >>> managed to miss previously.
> >>>
> >>> Reported-by: Noah Misch
> >>> Reviewed-by: Noah Misch
> >>> Discussion: https://postgr.es/m/20240724130059.1f.nmisch@google.com
> >>> Backpatch-through: 17
> >>>
> >>> Branch
> >>> ------
> >>> master
> >>>
> >>> Details
> >>> -------
> >>> https://git.postgresql.org/pg/commitdiff/c9e24573905bef7fc3e4efb02bdb4d0cc8e43c51
> >>
> >> I don't understand this patch. The previous patches that this
> >> references changed various variables to int64 and made adjustments
> >> following from that. But this patch takes variables and function
> >> results that are of type int and casts them to unsigned long long before
> >> printing. I don't see what that accomplishes, and it's not clear based
> >> on just the explanation that this is a continuation of a previous patch
> >> that doesn't do that. Is there a plan to change these things to int64
> >> as well at some point?
> >
> > There is a plan indeed. The patchset [1] should include conversion
> > multixacts to 64-bit (It surely included that in earlier versions, I
> > didn't look the last versions though). I doubt this will be ready for
> > v18. So this commit might be quite preliminary. But I would prefer
> > to leave it there as soon as it has already landed. Opinions?
>
> I think you should change the output formats at the same time as you
> change the variable types. That way the compiler can cross-check this.
> Otherwise, if you later forget to change a variable, these casts will
> hide it. Or if the future patches turn out differently, then we have
> this useless code.
>
> > Links.
> > 1. https://www.postgresql.org/message-id/CAJ7c6TND0bCnwU1SmxTsFewK4XJGBep343vf%2BT%2BGQ-a5S5hC0w%40mail...
>
> It looks like the commit I'm talking about here is a subset of v55-0001
> from that thread?
Yes, looks like this.
> So why is some of this being committed now into v17?
> But as I wrote above, I think this approach is a bad idea.
OK, I agree that might look annoying. So, it's better to revert now.
Michael, what do you think?
------
Regards,
Alexander Korotkov
Supabase
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-07 23:15 Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 18+ messages in thread
From: Michael Paquier @ 2024-08-07 23:15 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
> On Aug 8, 2024, at 5:05, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Wed, Aug 7, 2024 at 10:52 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>> It looks like the commit I'm talking about here is a subset of v55-0001
>> from that thread?
>
> Yes, looks like this.
>
>> So why is some of this being committed now into v17?
>> But as I wrote above, I think this approach is a bad idea.
>
> OK, I agree that might look annoying. So, it's better to revert now.
> Michael, what do you think?
The argument is two-fold here. The point of this change is that we were forcibly doing a cast to int with int64 values returned, so this commit limits the risks of missing paths in the future, while being consistent with all the SLRU code marking segment numbers with int64 for short *and* long segment file names.
So at the end, I’d rather let the code as it is now, and keep a line of marking all the segment numbers with int64 and be consistent with what all the SLRU internals think what segment numbers should be. This is also the argument of Noah’s upthread as far as I understand (Noah, feel free to correct me if you think differently).
(I’m without laptop access for quite a few days)
--
Michael
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-09 13:08 Peter Eisentraut <peter@eisentraut.org>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 18+ messages in thread
From: Peter Eisentraut @ 2024-08-09 13:08 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Alexander Korotkov <aekorotkov@gmail.com>; +Cc: pgsql-committers@lists.postgresql.org
On 08.08.24 01:15, Michael Paquier wrote:
>
>> On Aug 8, 2024, at 5:05, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>> On Wed, Aug 7, 2024 at 10:52 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>> It looks like the commit I'm talking about here is a subset of v55-0001
>>> from that thread?
>>
>> Yes, looks like this.
>>
>>> So why is some of this being committed now into v17?
>>> But as I wrote above, I think this approach is a bad idea.
>>
>> OK, I agree that might look annoying. So, it's better to revert now.
>> Michael, what do you think?
>
> The argument is two-fold here. The point of this change is that we were forcibly doing a cast to int with int64 values returned, so this commit limits the risks of missing paths in the future, while being consistent with all the SLRU code marking segment numbers with int64 for short *and* long segment file names.
No, this is not what *this* patch does. (I suppose some of the related
patches might be doing that.) This patch just casts a few things that
are int to unsigned long long int before printing them.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-12 21:35 Alexander Korotkov <aekorotkov@gmail.com>
parent: Peter Eisentraut <peter@eisentraut.org>
0 siblings, 2 replies; 18+ messages in thread
From: Alexander Korotkov @ 2024-08-12 21:35 UTC (permalink / raw)
To: Peter Eisentraut <peter@eisentraut.org>; +Cc: Michael Paquier <michael@paquier.xyz>; pgsql-committers@lists.postgresql.org
On Fri, Aug 9, 2024 at 4:09 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 08.08.24 01:15, Michael Paquier wrote:
> >
> >> On Aug 8, 2024, at 5:05, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> >> On Wed, Aug 7, 2024 at 10:52 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> >>> It looks like the commit I'm talking about here is a subset of v55-0001
> >>> from that thread?
> >>
> >> Yes, looks like this.
> >>
> >>> So why is some of this being committed now into v17?
> >>> But as I wrote above, I think this approach is a bad idea.
> >>
> >> OK, I agree that might look annoying. So, it's better to revert now.
> >> Michael, what do you think?
> >
> > The argument is two-fold here. The point of this change is that we were forcibly doing a cast to int with int64 values returned, so this commit limits the risks of missing paths in the future, while being consistent with all the SLRU code marking segment numbers with int64 for short *and* long segment file names.
>
> No, this is not what *this* patch does. (I suppose some of the related
> patches might be doing that.) This patch just casts a few things that
> are int to unsigned long long int before printing them.
As pointed by Noah Misch [1], unlike the commit the patch [2] also
changed segment-returning functions to return int64. Thus, in the
patch output formats make much more sense, because they match the
input data types. Michael, are you intended to push the remaining
part of the patch [2]?
Links
1. https://www.postgresql.org/message-id/20240810175055.cd.nmisch%40google.com
2. https://www.postgresql.org/message-id/ZqGvzSbW5TGKqZcE%40paquier.xyz
------
Regards,
Alexander Korotkov
Supabase
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-12 22:30 Michael Paquier <michael@paquier.xyz>
parent: Alexander Korotkov <aekorotkov@gmail.com>
1 sibling, 1 reply; 18+ messages in thread
From: Michael Paquier @ 2024-08-12 22:30 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
> On Aug 13, 2024, at 6:35, Alexander Korotkov <aekorotkov@gmail.com> wrote:.
>
> As pointed by Noah Misch [1], unlike the commit the patch [2] also
> changed segment-returning functions to return int64. Thus, in the
> patch output formats make much more sense, because they match the
> input data types. Michael, are you intended to push the remaining
> part of the patch [2]?
Guess so. I could look at that next week, not before.
--
Michael
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-13 06:16 Peter Eisentraut <peter@eisentraut.org>
parent: Alexander Korotkov <aekorotkov@gmail.com>
1 sibling, 0 replies; 18+ messages in thread
From: Peter Eisentraut @ 2024-08-13 06:16 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; pgsql-committers@lists.postgresql.org
On 12.08.24 23:35, Alexander Korotkov wrote:
> On Fri, Aug 9, 2024 at 4:09 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>> On 08.08.24 01:15, Michael Paquier wrote:
>>>
>>>> On Aug 8, 2024, at 5:05, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>>>> On Wed, Aug 7, 2024 at 10:52 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>>>> It looks like the commit I'm talking about here is a subset of v55-0001
>>>>> from that thread?
>>>>
>>>> Yes, looks like this.
>>>>
>>>>> So why is some of this being committed now into v17?
>>>>> But as I wrote above, I think this approach is a bad idea.
>>>>
>>>> OK, I agree that might look annoying. So, it's better to revert now.
>>>> Michael, what do you think?
>>>
>>> The argument is two-fold here. The point of this change is that we were forcibly doing a cast to int with int64 values returned, so this commit limits the risks of missing paths in the future, while being consistent with all the SLRU code marking segment numbers with int64 for short *and* long segment file names.
>>
>> No, this is not what *this* patch does. (I suppose some of the related
>> patches might be doing that.) This patch just casts a few things that
>> are int to unsigned long long int before printing them.
>
> As pointed by Noah Misch [1], unlike the commit the patch [2] also
> changed segment-returning functions to return int64. Thus, in the
> patch output formats make much more sense, because they match the
> input data types. Michael, are you intended to push the remaining
> part of the patch [2]?
>
> Links
> 1. https://www.postgresql.org/message-id/20240810175055.cd.nmisch%40google.com
> 2. https://www.postgresql.org/message-id/ZqGvzSbW5TGKqZcE%40paquier.xyz
Ah yes, it makes sense together with [2].
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-14 02:13 Alexander Korotkov <aekorotkov@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 18+ messages in thread
From: Alexander Korotkov @ 2024-08-14 02:13 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Tue, Aug 13, 2024 at 1:30 AM Michael Paquier <michael@paquier.xyz> wrote:
> > On Aug 13, 2024, at 6:35, Alexander Korotkov <aekorotkov@gmail.com> wrote:.
> >
> > As pointed by Noah Misch [1], unlike the commit the patch [2] also
> > changed segment-returning functions to return int64. Thus, in the
> > patch output formats make much more sense, because they match the
> > input data types. Michael, are you intended to push the remaining
> > part of the patch [2]?
>
> Guess so. I could look at that next week, not before.
OK. I made an attached patch from the missing parts.
Do you mind if I push that? If yes, feel free to use it.
------
Regards,
Alexander Korotkov
Supabase
Attachments:
v1-0001-Fix-even-more-holes-with-SLRU-code-in-need-of-int.patch (application/octet-stream, 2.6K) download
From 3dd7c8d0de11b0da327b5e4050f8ffc0ff194781 Mon Sep 17 00:00:00 2001
From: Alexander Korotkov <akorotkov@postgresql.org>
Date: Wed, 14 Aug 2024 05:04:13 +0300
Subject: [PATCH v1] Fix even more holes with SLRU code in need of int64 for
segment numbers
This is a continuation of c9e24573905b, containing changes included into
a patch, but for some reason absent in c9e24573905b.
Discussion: https://postgr.es/m/20240810175055.cd.nmisch%40google.com
Discussion: https://postgr.es/m/92fe572d-638e-4162-aef6-1c42a2936f25%40eisentraut.org
Author: Michael Paquier
---
src/backend/access/transam/multixact.c | 12 ++++++------
src/backend/access/transam/slru.c | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index c601ff98a14..c33d5d8426d 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -120,7 +120,7 @@ MultiXactIdToOffsetEntry(MultiXactId multi)
return multi % MULTIXACT_OFFSETS_PER_PAGE;
}
-static inline int
+static inline int64
MultiXactIdToOffsetSegment(MultiXactId multi)
{
return MultiXactIdToOffsetPage(multi) / SLRU_PAGES_PER_SEGMENT;
@@ -174,7 +174,7 @@ MXOffsetToMemberPage(MultiXactOffset offset)
return offset / MULTIXACT_MEMBERS_PER_PAGE;
}
-static inline int
+static inline int64
MXOffsetToMemberSegment(MultiXactOffset offset)
{
return MXOffsetToMemberPage(offset) / SLRU_PAGES_PER_SEGMENT;
@@ -3039,10 +3039,10 @@ SlruScanDirCbFindEarliest(SlruCtl ctl, char *filename, int64 segpage, void *data
static void
PerformMembersTruncation(MultiXactOffset oldestOffset, MultiXactOffset newOldestOffset)
{
- const int maxsegment = MXOffsetToMemberSegment(MaxMultiXactOffset);
- int startsegment = MXOffsetToMemberSegment(oldestOffset);
- int endsegment = MXOffsetToMemberSegment(newOldestOffset);
- int segment = startsegment;
+ const int64 maxsegment = MXOffsetToMemberSegment(MaxMultiXactOffset);
+ int64 startsegment = MXOffsetToMemberSegment(oldestOffset);
+ int64 endsegment = MXOffsetToMemberSegment(newOldestOffset);
+ int64 segment = startsegment;
/*
* Delete all the segments but the last one. The last segment can still
diff --git a/src/backend/access/transam/slru.c b/src/backend/access/transam/slru.c
index 248aa1a6553..713d3bff3f9 100644
--- a/src/backend/access/transam/slru.c
+++ b/src/backend/access/transam/slru.c
@@ -1532,7 +1532,7 @@ restart:
did_write = false;
for (int slotno = 0; slotno < shared->num_slots; slotno++)
{
- int pagesegno;
+ int64 pagesegno;
int curbank = SlotGetBankNumber(slotno);
/*
--
2.39.3 (Apple Git-146)
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-14 21:26 Alexander Korotkov <aekorotkov@gmail.com>
parent: Alexander Korotkov <aekorotkov@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Alexander Korotkov @ 2024-08-14 21:26 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Wed, Aug 14, 2024 at 5:13 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Tue, Aug 13, 2024 at 1:30 AM Michael Paquier <michael@paquier.xyz> wrote:
> > > On Aug 13, 2024, at 6:35, Alexander Korotkov <aekorotkov@gmail.com> wrote:.
> > >
> > > As pointed by Noah Misch [1], unlike the commit the patch [2] also
> > > changed segment-returning functions to return int64. Thus, in the
> > > patch output formats make much more sense, because they match the
> > > input data types. Michael, are you intended to push the remaining
> > > part of the patch [2]?
> >
> > Guess so. I could look at that next week, not before.
>
> OK. I made an attached patch from the missing parts.
> Do you mind if I push that? If yes, feel free to use it.
I mean, I'd like to push it if you don't object.
If you object and like to push it yourself, feel free to use this patch.
------
Regards,
Alexander Korotkov
Supabase
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-14 23:07 Michael Paquier <michael@paquier.xyz>
parent: Alexander Korotkov <aekorotkov@gmail.com>
0 siblings, 1 reply; 18+ messages in thread
From: Michael Paquier @ 2024-08-14 23:07 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
> On Aug 15, 2024, at 6:26, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> I mean, I'd like to push it if you don't object.
> If you object and like to push it yourself, feel free to use this patch.
I’d like to take a look at what you have here to get an opinion. Could you wait for a few days?
--
Michael
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-15 00:40 Alexander Korotkov <aekorotkov@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 18+ messages in thread
From: Alexander Korotkov @ 2024-08-15 00:40 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Thu, Aug 15, 2024 at 2:07 AM Michael Paquier <michael@paquier.xyz> wrote:
> > On Aug 15, 2024, at 6:26, Alexander Korotkov <aekorotkov@gmail.com> wrote:
> > I mean, I'd like to push it if you don't object.
> > If you object and like to push it yourself, feel free to use this patch.
>
> I’d like to take a look at what you have here to get an opinion. Could you wait for a few days?
Sure, NP.
------
Regards,
Alexander Korotkov
Supabase
^ permalink raw reply [nested|flat] 18+ messages in thread
* pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-19 03:35 Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 18+ messages in thread
From: Michael Paquier @ 2024-08-19 03:35 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix more holes with SLRU code in need of int64 for segment numbers
This is a continuation of c9e24573905b, containing changes included into
the proposed patch that have been missed in the actual commit. I have
managed to miss these diffs while doing a rebase of the original patch.
Thanks to Noah Misch, Peter Eisentraut and Alexander Korotkov for the
pokes.
Discussion: https://postgr.es/m/92fe572d-638e-4162-aef6-1c42a2936f25@eisentraut.org
Discussion: https://postgr.es/m/20240810175055.cd.nmisch@google.com
Backpatch-through: 17
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/b7935bc10b78f3a44567d304df87fad3d53102dd
Modified Files
--------------
src/backend/access/transam/multixact.c | 12 ++++++------
src/backend/access/transam/slru.c | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 18+ messages in thread
* pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-19 03:35 Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 18+ messages in thread
From: Michael Paquier @ 2024-08-19 03:35 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Fix more holes with SLRU code in need of int64 for segment numbers
This is a continuation of c9e24573905b, containing changes included into
the proposed patch that have been missed in the actual commit. I have
managed to miss these diffs while doing a rebase of the original patch.
Thanks to Noah Misch, Peter Eisentraut and Alexander Korotkov for the
pokes.
Discussion: https://postgr.es/m/92fe572d-638e-4162-aef6-1c42a2936f25@eisentraut.org
Discussion: https://postgr.es/m/20240810175055.cd.nmisch@google.com
Backpatch-through: 17
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/bd06cc338d82fd0c56de6421fe5ef143ec79cf6e
Modified Files
--------------
src/backend/access/transam/multixact.c | 12 ++++++------
src/backend/access/transam/slru.c | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
@ 2024-08-19 03:37 Michael Paquier <michael@paquier.xyz>
parent: Alexander Korotkov <aekorotkov@gmail.com>
0 siblings, 0 replies; 18+ messages in thread
From: Michael Paquier @ 2024-08-19 03:37 UTC (permalink / raw)
To: Alexander Korotkov <aekorotkov@gmail.com>; +Cc: Peter Eisentraut <peter@eisentraut.org>; pgsql-committers@lists.postgresql.org
On Thu, Aug 15, 2024 at 03:40:12AM +0300, Alexander Korotkov wrote:
> On Thu, Aug 15, 2024 at 2:07 AM Michael Paquier <michael@paquier.xyz> wrote:
>> I’d like to take a look at what you have here to get an opinion. Could you wait for a few days?
>
> Sure, NP.
My apologies for the delay. I have double-checked my reflog history,
and I've messed up two `git add` while rebasing.
I've spent some time rechecking the whole area, and finished with the
same patch as what you have attached at [1]. As I'm responsible for
the mistake, I have handled that myself. Thanks for the pokes!
For the archives, Noah has mentioned the same here:
https://www.postgresql.org/message-id/20240810175055.cd.nmisch@google.com
[1]: https://www.postgresql.org/message-id/CAPpHfdui0-GmLd6V-H8RhcaytyLZfR2p6QG+E_LTsD_i=bQ6NA@mail.gmail...
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2024-08-19 03:37 UTC | newest]
Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-07-26 22:24 pgsql: Fix more holes with SLRU code in need of int64 for segment numbe Michael Paquier <michael@paquier.xyz>
2024-08-07 09:07 ` Peter Eisentraut <peter@eisentraut.org>
2024-08-07 15:53 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-08-07 19:52 ` Peter Eisentraut <peter@eisentraut.org>
2024-08-07 20:04 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-07-26 22:24 pgsql: Fix more holes with SLRU code in need of int64 for segment numbe Michael Paquier <michael@paquier.xyz>
2024-08-07 23:15 Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe Michael Paquier <michael@paquier.xyz>
2024-08-09 13:08 ` Peter Eisentraut <peter@eisentraut.org>
2024-08-12 21:35 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-08-12 22:30 ` Michael Paquier <michael@paquier.xyz>
2024-08-14 02:13 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-08-14 21:26 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-08-14 23:07 ` Michael Paquier <michael@paquier.xyz>
2024-08-15 00:40 ` Alexander Korotkov <aekorotkov@gmail.com>
2024-08-19 03:37 ` Michael Paquier <michael@paquier.xyz>
2024-08-13 06:16 ` Peter Eisentraut <peter@eisentraut.org>
2024-08-19 03:35 pgsql: Fix more holes with SLRU code in need of int64 for segment numbe Michael Paquier <michael@paquier.xyz>
2024-08-19 03:35 pgsql: Fix more holes with SLRU code in need of int64 for segment numbe Michael Paquier <michael@paquier.xyz>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox