Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Nov 29, 2022 at 9:35 PM Chris Travers wrote: > My proposal would be to make the threshold configurable and start warning on > every transaction after that. There are a couple reasons to do that. > > The first is that noisy warnings are extremely easy to see. You get them in > cron emai

Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Nov 29, 2022 at 5:57 PM Bruce Momjian wrote: > On Tue, Nov 29, 2022 at 11:41:07AM -0500, Robert Haas wrote: > > My argument is that removing xidStopLimit is totally fine, because it > > only serves to stop the database. What to do about xidWarnLimit is a > > slightly more complex question

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, 28 Nov 2022 at 16:53, Peter Geoghegan wrote: > > Imagine if we actually had 64-bit XIDs -- let's assume for a moment > that it's a done deal. This raises a somewhat awkward question: do you > just let the system get further and further behind on freezing, > forever? We can all agree that

Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Nov 29, 2022 at 11:41:07AM -0500, Robert Haas wrote: > My argument is that removing xidStopLimit is totally fine, because it > only serves to stop the database. What to do about xidWarnLimit is a > slightly more complex question. Certainly it can't be left untouched, > because warning that

Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Nov 29, 2022 at 8:03 AM Chris Travers wrote: > To be clear, I never suggested shutting down the database. What I have > suggested is that repurposing the current approaching-xid-wraparound warnings > to start complaining loudly when a threshold is exceeded would be helpful. > I think

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 28, 2022 at 4:53 PM Peter Geoghegan wrote: > Imagine if we actually had 64-bit XIDs -- let's assume for a moment > that it's a done deal. This raises a somewhat awkward question: do you > just let the system get further and further behind on freezing, > forever? We can all agree that 2

Re: Add 64-bit XIDs into PostgreSQL 15

On 11/29/22 09:46, Bruce Momjian wrote: As far as I know, all our freeze values are focused on avoiding XID wraparound. If XID wraparound is no longer an issue, we might find that our freeze limits can be much higher than they are now. I'd be careful in that direction as the values together w

Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Nov 29, 2022 at 02:35:20PM +0100, Chris Travers wrote: > So I think the problem is that PostgreSQL is becoming more and more scalabile, > hardware is becoming more capable, and certain use cases are continuing to > scale up.  Over time, we tend to find ourselves approaching the end of the >

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 28, 2022 at 11:06 PM Peter Geoghegan wrote: > On Mon, Nov 28, 2022 at 1:52 PM Bruce Momjian wrote: > > I think the problem is that we still have bloat with 64-bit XIDs, > > specifically pg_xact and pg_multixact files. Yes, that bloat is less > > serious, but it is still an issue wor

Re: Add 64-bit XIDs into PostgreSQL 15

Hi; I suppose I must not have been clear in what I am suggesting we do and why. I will try to answer specific points below and then restate what I think the problem is, and what I think should be done about it. On Mon, Nov 28, 2022 at 5:53 PM Robert Haas wrote: > On Sat, Nov 26, 2022 at 4:08

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 28, 2022 at 1:52 PM Peter Geoghegan wrote: > I'm not claiming to know how to build this "better xidStopLimit > mechanism", by the way. I'm not seriously proposing it. Mostly I'm > just saying that the question "where do you draw the line if not at 2 > billion XIDs?" is a very pertinent

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 28, 2022 at 1:52 PM Bruce Momjian wrote: > I think the problem is that we still have bloat with 64-bit XIDs, > specifically pg_xact and pg_multixact files. Yes, that bloat is less > serious, but it is still an issue worth reporting in the server logs, > though not serious enough to st

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 28, 2022 at 1:30 PM Robert Haas wrote: > What is the purpose of using 64-bit XIDs, if not to avoid having to > stop the world when we run short of XIDs? I agree that the xidStopLimit mechanism was designed with the specific goal of preventing "true" physical XID wraparound that result

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 28, 2022 at 04:30:22PM -0500, Robert Haas wrote: > What is the purpose of using 64-bit XIDs, if not to avoid having to > stop the world when we run short of XIDs? > > I'd say that if this patch, or any patch with broadly similar goals, > fails to remove xidStopLimit, it might as well n

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 28, 2022 at 4:09 PM Peter Geoghegan wrote: > Granted, the specifics of the current XidStopLimit mechanism are > unlikely to directly carry over to 64-bit XIDs. XidStopLimit is > structured in a way that doesn't actually consider freeze debt in > units like unfrozen pages. Like Chris, I

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 28, 2022 at 8:53 AM Robert Haas wrote: > It is true that if the table is progressively bloating, it is likely > to be more bloated by the time you are 8 billion XIDs behind than it > was when you were 800 million XIDs behind. I don't see that as a very > good reason not to adopt this p

Re: Add 64-bit XIDs into PostgreSQL 15

On Sat, Nov 26, 2022 at 4:08 AM Chris Travers wrote: > I didn't see any changes to pg_upgrade to make this change possible on > upgrade. Is that also outside of the scope of your patch set? If so how is > that continuity supposed to be ensured? The scheme is documented in their 0006 patch, in

Re: Add 64-bit XIDs into PostgreSQL 15

Hi; Trying to discuss where we are talking past eachother. On Fri, Nov 25, 2022 at 9:38 AM Aleksander Alekseev < aleksan...@timescale.com> wrote: > Hi hackers, > > > I'm wondering whether the safest way to handle this is by creating a > > new TAM called "heap64", so that all storage changes

Re: Add 64-bit XIDs into PostgreSQL 15

Hi hackers, > I'm wondering whether the safest way to handle this is by creating a > new TAM called "heap64", so that all storage changes happens there. > Many current users see stability as one of the greatest strengths of > Postgres, so while I very much support this move, I wonder if this > gi

Re: Add 64-bit XIDs into PostgreSQL 15

On Sun, Nov 20, 2022 at 11:58 PM Chris Travers wrote: > I can start by saying I think it would be helpful (if the other issues are > approached reasonably) to have 64-bit xids, but there is an important piece > of context in reventing xid wraparounds that seems missing from this patch > unless

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, 21 Oct 2022 at 17:09, Maxim Orlov wrote: > Reviews and opinions are very welcome! I'm wondering whether the safest way to handle this is by creating a new TAM called "heap64", so that all storage changes happens there. (Obviously there are still many other changes in core, but they are m

Re: Add 64-bit XIDs into PostgreSQL 15

Hi Chris, > XID wraparound doesn't happen to healthy databases > If you disagree, I would like to hear why. Consider the case when you run a slow OLAP query that takes 12h to complete and 100K TPS of fast OLTP-type queries on the same system. The fast queries will consume all 32-bit XIDs in less

Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Nov 22, 2022 at 10:01 AM Aleksander Alekseev < aleksan...@timescale.com> wrote: > Hi Chris, > > > Right now the way things work is: > > 1. Database starts throwing warnings that xid wraparound is approaching > > 2. Database-owning team initiates an emergency response, may take > downtime

Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Nov 22, 2022 at 7:44 PM Aleksander Alekseev wrote: > > Hi hackers, > > [ Excluding my personal e-mail from cc:, not sure how it got there. > Please don't cc: to afis...@gmail.com, I'm not using it for reading > pgsql-hackers@. ] > > > I agree with Alexander, that notifications for DBA are

Re: Add 64-bit XIDs into PostgreSQL 15

Hi hackers, [ Excluding my personal e-mail from cc:, not sure how it got there. Please don't cc: to afis...@gmail.com, I'm not using it for reading pgsql-hackers@. ] > I agree with Alexander, that notifications for DBA are a little bit > outside the scope of the activity in this thread unless we'

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, Alexander! On Tue, 22 Nov 2022 at 13:01, Aleksander Alekseev wrote: > > Hi Chris, > > > Right now the way things work is: > > 1. Database starts throwing warnings that xid wraparound is approaching > > 2. Database-owning team initiates an emergency response, may take downtime > > or degrad

Re: Add 64-bit XIDs into PostgreSQL 15

Hi Chris, > Right now the way things work is: > 1. Database starts throwing warnings that xid wraparound is approaching > 2. Database-owning team initiates an emergency response, may take downtime > or degradation of services as a result > 3. People get frustrated with PostgreSQL because this

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 21, 2022 at 10:40 AM Pavel Borisov wrote: > > I have a very serious concern about the current patch set. as someone > who has faced transaction id wraparound in the past. > > > > I can start by saying I think it would be helpful (if the other issues > are approached reasonably) to hav

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Nov 21, 2022 at 12:25 PM Aleksander Alekseev < aleksan...@timescale.com> wrote: > Hi hackers, > > > > I have a very serious concern about the current patch set. as someone > who has faced transaction id wraparound in the past. > > > > [...] > > > > I had a similar stance when I started wor

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, On 2022-11-21 15:16:46 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2022-11-21 14:21:35 -0500, Tom Lane wrote: > >> pg_resetwal does seem like a better, more useful home for this; it'd > >> allow you to adjust these numbers after initial creation which might be > >> useful. I'm not

Re: Add 64-bit XIDs into PostgreSQL 15

Andres Freund writes: > On 2022-11-21 14:21:35 -0500, Tom Lane wrote: >> pg_resetwal does seem like a better, more useful home for this; it'd >> allow you to adjust these numbers after initial creation which might be >> useful. I'm not sure how flexible it is right now in terms of where >> you ca

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, On 2022-11-21 14:21:35 -0500, Tom Lane wrote: > Peter Eisentraut writes: > >> To date testing database cluster wraparund was not easy as initdb has > >> always > >> inited it with default xid/mxid/mxoff. The option to specify any valid > >> xid/mxid/mxoff at cluster startup will make these t

Re: Add 64-bit XIDs into PostgreSQL 15

Peter Eisentraut writes: >> To date testing database cluster wraparund was not easy as initdb has always >> inited it with default xid/mxid/mxoff. The option to specify any valid >> xid/mxid/mxoff at cluster startup will make these things easier. > Doesn't pg_resetwal already provide that functio

Re: Add 64-bit XIDs into PostgreSQL 15

Question about """ Subject: [PATCH v50 5/8] Add initdb option to initialize cluster with non-standard xid/mxid/mxoff. To date testing database cluster wraparund was not easy as initdb has always inited it with default xid/mxid/mxoff. The option to specify any valid xid/mxid/mxoff at cluster sta

Re: Add 64-bit XIDs into PostgreSQL 15

Hi hackers, > > I have a very serious concern about the current patch set. as someone who > > has faced transaction id wraparound in the past. > > [...] > > I had a similar stance when I started working on this patch. Of > course, it seemed horrible just to postpone the consequences of > inadequa

Re: Add 64-bit XIDs into PostgreSQL 15

> I have a very serious concern about the current patch set. as someone who has > faced transaction id wraparound in the past. > > I can start by saying I think it would be helpful (if the other issues are > approached reasonably) to have 64-bit xids, but there is an important piece > of context

Re: Add 64-bit XIDs into PostgreSQL 15

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested I have a very serious concern about the current patch set. as someone who has

Re: Add 64-bit XIDs into PostgreSQL 15

Hi hackers, > Dilip Kumar asked a good question in the thread about the 0001..0003 > subset [1]. I would like to duplicate it here to make sure it was not > missed by mistake: > > """ > Have we measured the WAL overhead because of this patch set? maybe > these particular patches will not impact bu

Re: Add 64-bit XIDs into PostgreSQL 15

Hi hackers, > Thanks, done! Dilip Kumar asked a good question in the thread about the 0001..0003 subset [1]. I would like to duplicate it here to make sure it was not missed by mistake: """ Have we measured the WAL overhead because of this patch set? maybe these particular patches will not impac

Re: Add 64-bit XIDs into PostgreSQL 15

On Thu, 3 Nov 2022 at 08:12, Maxim Orlov wrote: > > Hi! > >> I attach an additional V48-0009 patch as they are just comments, apply it if >> you want to. > > Big thank you for your review. I've applied your addition in the recent patch > set below. > > Besides, mentioned above, next changes are

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

2022年11月3日(木) 17:15 Maxim Orlov : > > Hi! > >> >> This entry was marked "Ready for committer" in the CommitFest app but cfbot >> reports the patch no longer applies. > > Thanks for the reminder. I think, this should work. Thanks for the quick update, cfbot reports no issues. I've set the CF entry

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Thu, Nov 3, 2022 at 1:46 PM Maxim Orlov wrote: > > Hi! > >> >> This entry was marked "Ready for committer" in the CommitFest app but cfbot >> reports the patch no longer applies. > > Thanks for the reminder. I think, this should work. Have we measured the WAL overhead because of this patch set

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

2022年10月10日(月) 18:16 Aleksander Alekseev : > > Hi hackers, > > > Sorry about that. > > No problem. > > > Thanks, Simon. Not 100% sure who exactly is invited to vote, but just > > in case here is +1 from me. These patches were "Ready for Committer" > > for several months now and are unlikely to get

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, On Oct 22, 2022, 00:09 +0800, Maxim Orlov , wrote: > > > > Done! Thanks! Here is the rebased version. > > > > This version has bug fix for multixact replication. Previous versions of > > the patch set does not write pd_multi_base in WAL. Thus, this field was set > > to 0 upon WAL reply on r

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, Oct 07, 2022 at 02:04:09PM +0300, Maxim Orlov wrote: > As always, reviews are very welcome! This patch set needs a rebase, as far as I can see. -- Michael signature.asc Description: PGP signature

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> > This is the wrong thread / CF entry. Please see > Yep, my fault. Sorry about that. -- Best regards, Maxim Orlov.

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Maxim, > Here is a rebased version of the patch set. This is the wrong thread / CF entry. Please see http://cfbot.cputube.org/ and https://commitfest.postgresql.org/ and the first email in the thread. -- Best regards, Aleksander Alekseev

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Tue, 26 Jul 2022 at 21:35, Simon Riggs wrote: > On Fri, 15 Jul 2022 at 12:29, Aleksander Alekseev > wrote: > > Personally I didn't expect that > > merging patches in this thread would take that long. They are in > > "Ready for Committer" state for a long time now and there are no known > > is

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, On Sep 20, 2022, 17:26 +0800, Justin Pryzby , wrote: > On Tue, Sep 20, 2022 at 03:37:47PM +0800, Zhang Mingli wrote: > > I want to have a look at these patches, but apply on master failed: > > Yeah, it's likely to break every week or more often. > > You have a few options: > > 0) resolve the co

Re: Add 64-bit XIDs into PostgreSQL 15

On Tue, Sep 20, 2022 at 03:37:47PM +0800, Zhang Mingli wrote: > I want to have a look at these patches, but apply on master failed: Yeah, it's likely to break every week or more often. You have a few options: 0) resolve the conflict yourself; 1) apply the patch to the commit that the authors se

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, With these patches, it seems that we don’t need to handle wraparound in GetNextLocalTransactionId() too, as LocalTransactionId is unit64 now. ``` LocalTransactionId GetNextLocalTransactionId(void) {     LocalTransactionId result;     /* loop to avoid returning InvalidLocalTransactionId at wr

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, Is this patch target to PG16 now? I want to have a look at these patches, but apply on master failed: Applying: Use 64-bit numbering of SLRU pages. Applying: Use 64-bit format to output XIDs Applying: Use 64-bit FullTransactionId instead of Epoch:xid Applying: Use 64-bit pages representation

Re: Add 64-bit XIDs into PostgreSQL 15

I have to say, to my embarrassment, after sending the previous email, I've notice minor imperfections in a patch set caused by the last rebase. These imperfections led to cf bot fail. I'll address this issue in the next iteration in order not to generate excessive flow. -- Best regards, Maxim Or

Re: Add 64-bit XIDs into PostgreSQL 15

On Sun, Sep 4, 2022 at 9:53 AM Dilip Kumar wrote: > > On Mon, Jul 18, 2022 at 2:54 PM Pavel Borisov wrote: > >> > >> > I can agree with you that sending rebased patches too often can be a > >> > little annoying. On the other hand, otherwise, it's just red in Cfbot. I > >> > suppose it's much ea

Re: Add 64-bit XIDs into PostgreSQL 15

On Mon, Jul 18, 2022 at 2:54 PM Pavel Borisov wrote: >> >> > I can agree with you that sending rebased patches too often can be a >> > little annoying. On the other hand, otherwise, it's just red in Cfbot. I >> > suppose it's much easier and more comfortable to review the patches that >> > at l

Re: Add 64-bit XIDs into PostgreSQL 15

On Wed, Jan 05, 2022 at 06:12:26PM -0600, Justin Pryzby wrote: > On Wed, Jan 05, 2022 at 06:51:37PM -0500, Bruce Momjian wrote: > > On Tue, Jan 4, 2022 at 10:22:50PM +, Finnerty, Jim wrote: > > > I'm concerned about the maintainability impact of having 2 new > > > on-disk page formats. It's al

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Fri, 15 Jul 2022 at 12:29, Aleksander Alekseev wrote: > Personally I didn't expect that > merging patches in this thread would take that long. They are in > "Ready for Committer" state for a long time now and there are no known > issues with them other than unit tests for SLRU [1] should be mer

Re: Add 64-bit XIDs into PostgreSQL 15

Hi hackers, > I can agree with you that sending rebased patches too often can be a little > annoying. On the other hand, otherwise, it's just red in Cfbot. I suppose > it's much easier and more comfortable to review the patches that at least > apply cleanly and pass all tests. So if Cfbot is re

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, 15 Jul 2022 at 16:17, Justin Pryzby wrote: > On Fri, Jul 15, 2022 at 03:23:29PM +0400, Pavel Borisov wrote: > > On Fri, 15 Jul 2022 at 15:20, Pavel Borisov > wrote: > > > Hi, hackers! > > > v42 stopped applying, so we rebased it to v43. Attached is a GitHub > link, > > > but I see Cfbot

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, Jul 15, 2022 at 03:23:29PM +0400, Pavel Borisov wrote: > On Fri, 15 Jul 2022 at 15:20, Pavel Borisov wrote: > > Hi, hackers! > > v42 stopped applying, so we rebased it to v43. Attached is a GitHub link, > > but I see Cfbot hasn't become green. Apparently, it hasn't seen changes in > > GitH

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Pavel, Justin, >> Is there any reason to continue with two separate threads and CF entries ? >> The original reason was to have a smaller patch for considerate late in v15. > I see the main goal of this split is to make discussion of this (easier) > thread separate to the discussion of a whole p

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, 15 Jul 2022 at 15:20, Pavel Borisov wrote: > Hi, hackers! > v42 stopped applying, so we rebased it to v43. Attached is a GitHub link, > but I see Cfbot hasn't become green. Apparently, it hasn't seen changes in > GitHub link relative to v42 attached as a patch. > Github link is as follow

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, hackers! v42 stopped applying, so we rebased it to v43. Attached is a GitHub link, but I see Cfbot hasn't become green. Apparently, it hasn't seen changes in GitHub link relative to v42 attached as a patch. -- Best regards, Pavel Borisov

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> > Is there any reason to continue with two separate threads and CF entries ? > The original reason was to have a smaller patch for considerate late in > v15. > > But right now, it just seems to cause every update to imply two email > messages > rather than one. > > Since the patch is split into 0

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Fri, May 13, 2022 at 04:21:29PM +0300, Maxim Orlov wrote: > We have posted an updated version v34 of the whole patchset in [1]. > Changes of patches 0001-0003 there are identical to v33. So, no update is > needed in this thread. Is there any reason to continue with two separate threads and CF e

Re: Add 64-bit XIDs into PostgreSQL 15

> > This seems to be causing cfbot/cirrusci to time out. > > Here's the build history > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/38/3594 > > https://cirrus-ci.com/task/4809278652416000 4 weeks ago on macos > https://cirrus-ci.com/task/5559884417597440 2 weeks ago on macos

Re: Add 64-bit XIDs into PostgreSQL 15

This seems to be causing cfbot/cirrusci to time out. Here's the build history https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/38/3594 https://cirrus-ci.com/task/4809278652416000 4 weeks ago on macos https://cirrus-ci.com/task/5559884417597440 2 weeks ago on macos https://cirru

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> here is the rebased v32 version of the patch. > > The patchset rotted a bit. Here is a rebased version. > We have posted an updated version v34 of the whole patchset in [1]. Changes of patches 0001-0003 there are identical to v33. So, no update is needed in this thread. [1] https://www.postgres

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi Peter, > That isn't really what I meant. When I said > > > At this point, I'm more concerned that code review is still finding > > bugs, and that we have no test coverage for any of this > > this meant especially the SLRU refactoring patch. Got it, and sorry for the confusion. I decided to

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On 29.03.22 15:09, Aleksander Alekseev wrote: Hi hackers, I took another look at the patchset. Personally I don't think it will get much better than it is now. I'm inclined to change the status of the CF entry to "Ready for Committer" unless anyone disagrees. About v25-0002-Use-64-bit-format

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi hackers, > I took another look at the patchset. Personally I don't think it will get much > better than it is now. I'm inclined to change the status of the CF entry to > "Ready for Committer" unless anyone disagrees. > > About v25-0002-Use-64-bit-format-to-output-XIDs.patch: > > I don't see th

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On 28.03.22 12:46, Aleksander Alekseev wrote: Personally I don't have a strong opinion here. Merging the patch sooner will allow us to move toward 64-bit XIDs faster (e.g. to gather the feedback from the early adopters, allow the translators to do their thing earlier, etc). Merging it later will

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi hackers, > Here is v30. I took another look at the patchset. Personally I don't think it will get much better than it is now. I'm inclined to change the status of the CF entry to "Ready for Committer" unless anyone disagrees. cfbot reports a problem with t/013_partition.pl but the test seems

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Just forgot to mention that answers in a previous message are describing the changes that are in v26. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi, Peter! Thanks for your review! About v25-0001-Use-unsigned-64-bit-numbering-of-SLRU-pages.patch: > > -static bool CLOGPagePrecedes(int page1, int page2); > +static bool CLOGPagePrecedes(uint64 page1, uint64 page2); > > You are changing the API from signed to unsigned. Is this intentional? > I

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On 23.03.22 10:51, Maxim Orlov wrote: Thanks for updating the patchs. I have a little comment on 0002. +                                errmsg_internal("found xmax %llu" " (infomask 0x%04x) not frozen, not multi, not normal", +

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Wed, 23 Mar 2022 at 01:22, Maxim Orlov wrote: > Hi! > > Here is v24. Changes are: > - correct commit messages for 0001 and 0002 > - use uint64 for SLRU page numbering instead of int64 in v23 > - fix code formatting and indent > - and minor fixes in slru.c > > Reviews are very welcome! > Than

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi hackers, > Here is v23. As was suggested by Alexander above, I've changed the order of > the patches and improved the commit message. Now, SLRU patch is the first. Many thanks! > There were proposals to make use of SLRU pages numbers that are in fact > unsigned and change from int to uint64

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> > > I think there needs to be a bit more soul searching here on how to > > handle that in the future and how to transition it. I don't think > > targeting this patch for PG15 is useful at this point. > > The patches can be reordered so that we are still able to deliver SLRU > refactoring in PG15

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi Peter, > I think there needs to be a bit more soul searching here on how to > handle that in the future and how to transition it. I don't think > targeting this patch for PG15 is useful at this point. The patches can be reordered so that we are still able to deliver SLRU refactoring in PG15.

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On 18.03.22 16:14, Maxim Orlov wrote: Here is v22. It addresses things mentioned by Tom and Kyotaro. Also added Aleksander's changes from v21. The v22-0002-Update-XID-formatting-in-the-.po-files.patch is not necessary. That is done by a separate procedure. I'm wondering about things like th

Re: Add 64-bit XIDs into PostgreSQL 15

> > > Do you know that you can test a branch on cirrus without using CF bot or > mailing the patch to the list ? See src/tools/ci/README > Yes, sure! The main reason to post updates of this patchset is for hackers that are interested in the progress have relevant version with updates. This patch

Re: Add 64-bit XIDs into PostgreSQL 15

On Fri, Mar 11, 2022 at 08:26:26PM +0300, Aleksander Alekseev wrote: > Hi hackers, > > > Here is a new version of the patchset. SLRU refactoring was moved to a > > separate patch. Both v14-0003 (XID_FMT macro) and v14-0004 (SLRU > > refactoring) can be delivered in PG15. > > Here is a new version

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> On 2022-03-18 18:14:52 +0300, Maxim Orlov wrote: > > Subject: [PATCH v22 3/6] Use 64-bit pages in SLRU > > > > This is one step toward 64-bit XIDs. > > I think this should explain in more detail why this move is done. Neither > the > commit message nor the rest of the thread does so afaics. It's

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, On 2022-03-18 18:22:00 +0300, Maxim Orlov wrote: > Here is v22 with following changes: > - use explicit unsigned long long cast for printf/elog XIDs instead of > macro XID_TYPE > - add *.po localization > - fix forgotten XIDs format changes in pg_resetwal.c > - 0006 patch refactoring FWIW, 00

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi, On 2022-03-18 18:14:52 +0300, Maxim Orlov wrote: > Subject: [PATCH v22 3/6] Use 64-bit pages in SLRU > > This is one step toward 64-bit XIDs. I think this should explain in more detail why this move is done. Neither the commit message nor the rest of the thread does so afaics. It's not too h

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, hackers! While working on the patchset I've noticed that FullTransactionId lost its semantics in its scope. TransactionId is supposed to be 64bit (default) and epoch approach becomes outdated. What do you think of fully removing FullTransactionId and its support functions and macro? -- Best

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> > > To me personally v21 looks almost OK. > > For some reason I didn't receive the recent e-mails from Tom and Kyotaro. > I've just discovered them accidentally by reading the thread through the > web interface. These comments were not addressed in v21. > Aleksander, as of now we're preparing a n

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi hackers, > Here is an new version with the following changes compared to v20: > [...] > To me personally v21 looks almost OK. For some reason I didn't receive the recent e-mails from Tom and Kyotaro. I've just discovered them accidentally by reading the thread through the web interface. These

Re: Add 64-bit XIDs into PostgreSQL 15

> I forked this thread as requested by several people in the discussion [1]. > > The new thread contains two patches that are targeting PG15. I replaced > the thread in the current CF to [1]. This thread was added to the next CF. > I suggest we continue discussing changes targeting PG >= 16 here. >

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> > On Thu, 17 Mar 2022 at 21:31, Alexander Korotkov > wrote: > > On Thu, Mar 17, 2022 at 4:23 PM Peter Eisentraut > > wrote: > >> On 17.03.22 14:12, Aleksander Alekseev wrote: > >> > v19-0001 changes the format string for XIDs from %u to XID_FMT. This > >> > refactoring allows us to switch to UI

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Japin Li writes: > Maybe, we should format it to string before for localization messages, > like the following code snippet comes from pg_backup_tar.c. > However, I do not think it is a good way. > snprintf(buf1, sizeof(buf1), INT64_FORMAT, (int64) len); > snprintf(buf2, sizeof(bu

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Thu, 17 Mar 2022 at 21:31, Alexander Korotkov wrote: > On Thu, Mar 17, 2022 at 4:23 PM Peter Eisentraut > wrote: >> On 17.03.22 14:12, Aleksander Alekseev wrote: >> > v19-0001 changes the format string for XIDs from %u to XID_FMT. This >> > refactoring allows us to switch to UINT64_FORMAT by

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Thu, Mar 17, 2022 at 4:23 PM Peter Eisentraut wrote: > On 17.03.22 14:12, Aleksander Alekseev wrote: > > v19-0001 changes the format string for XIDs from %u to XID_FMT. This > > refactoring allows us to switch to UINT64_FORMAT by changing one > > #define in the future patches. > > > > Kyotaro s

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On 17.03.22 14:12, Aleksander Alekseev wrote: v19-0001 changes the format string for XIDs from %u to XID_FMT. This refactoring allows us to switch to UINT64_FORMAT by changing one #define in the future patches. Kyotaro suggested using `errmsg("blah blah %lld ..", (long long) xid)` instead in or

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi, Aleksander! On Thu, Mar 17, 2022 at 4:12 PM Aleksander Alekseev wrote: > This thread is a fork of [1], created per request by several people in > the discussion. It includes two patches from the patchset that we > believe can be delivered in PG15. The rest of the patches are > targeting PG >=

Re: Add 64-bit XIDs into PostgreSQL 15

Hi hackers, I forked this thread as requested by several people in the discussion [1]. The new thread contains two patches that are targeting PG15. I replaced the thread in the current CF to [1]. This thread was added to the next CF. I suggest we continue discussing changes targeting PG >= 16 her

Re: Add 64-bit XIDs into PostgreSQL 15

At Tue, 15 Mar 2022 18:48:34 +0300, Maxim Orlov wrote in > Hi Kyotaro! > > 0001: > > > > The XID_FMT has quite bad impact on the translatability of error > > messages. 3286065651 has removed INT64_FORMAT from translatable > > texts for the reason. This re-introduces that in several places.

Re: Add 64-bit XIDs into PostgreSQL 15

Hi, On Mon, Mar 14, 2022 at 01:32:04PM +0300, Aleksander Alekseev wrote: > IMO v16-0001 and v16-0002 are in pretty good shape and are as much as > we are going to deliver in PG15. I'm going to change the status of the > CF entry to "Ready for Committer" somewhere this week unless someone > believe

Re: Add 64-bit XIDs into PostgreSQL 15

At Mon, 14 Mar 2022 19:43:40 +0400, Pavel Borisov wrote in > > I'd like to add a few quick notes on what's been done in v17. I have some commens by a quick look-through. Apologize in advance for wrong comments from the lack of the knowledge of the whole patch-set. > > Patches 0001 and 0002 th

<    1   2   3   >