On Wed, Dec 13, 2023 at 5:56 PM Maxim Orlov wrote:
>
> Hi!
>
> Just to keep this thread up to date, here's a new version after recent
> changes in SLRU.
> I'm also change order of the patches in the set, to make adding initdb MOX
> options after the
> "core 64 xid" patch, since MOX patch is
Hi Pavel Borisov
Many thanks
Best whish
Pavel Borisov 于2023年12月15日周五 17:13写道：
> Hi, Wenhui!
>
> On Fri, 15 Dec 2023 at 05:52, wenhui qiu wrote:
>
>> Hi Maxim Orlov
>> Good news,xid64 has achieved a successful first phase,I tried to
>> change the path status
Hi, Wenhui!
On Fri, 15 Dec 2023 at 05:52, wenhui qiu wrote:
> Hi Maxim Orlov
> Good news,xid64 has achieved a successful first phase,I tried to
> change the path status (https://commitfest.postgresql.org/43/3594/) ,But
> it seems incorrect
>
> Maxim Orlov 于2023年12月13日周三 20:26写道：
>
>> Hi!
Hi Maxim Orlov
Good news,xid64 has achieved a successful first phase,I tried to change
the path status (https://commitfest.postgresql.org/43/3594/) ,But it seems
incorrect
Maxim Orlov 于2023年12月13日周三 20:26写道：
> Hi!
>
> Just to keep this thread up to date, here's a new version after recent
>
; Maxim Orlov ;
Aleksander Alekseev ; Postgres hackers
; Heikki Linnakangas ;
Japin Li ; Andres Freund ; Michael
Paquier ; Peter Eisentraut
主题: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into
PostgreSQL 15)
On Mon, Dec 4, 2023 at 3:12 PM Pavel Borisov wrote:
> I th
On Mon, Dec 4, 2023 at 3:12 PM Pavel Borisov wrote:
> I think this is complete and could be closed.
Done.
On Mon, 4 Dec 2023 at 10:34, John Naylor wrote:
> On Thu, Nov 30, 2023 at 4:37 PM Alexander Korotkov
> wrote:
> >
> > On Thu, Nov 30, 2023 at 10:29 AM Pavel Borisov
> wrote:
> > > Agree. The fix is attached.
> >
> > What an oversight.
> > Thank you, pushed!
>
> With that, is there any more
On Thu, Nov 30, 2023 at 4:37 PM Alexander Korotkov wrote:
>
> On Thu, Nov 30, 2023 at 10:29 AM Pavel Borisov wrote:
> > Agree. The fix is attached.
>
> What an oversight.
> Thank you, pushed!
With that, is there any more work pending, or can we close the CF entry?
On Thu, Nov 30, 2023 at 10:29 AM Pavel Borisov wrote:
> Agree. The fix is attached.
What an oversight.
Thank you, pushed!
--
Regards,
Alexander Korotkov
On Thu, 30 Nov 2023 at 08:03, Tom Lane wrote:
> Alexander Lakhin writes:
> > And a warning:
> > $ CC=gcc-12 CFLAGS="-Wall -Wextra -Wno-unused-parameter
> -Wno-sign-compare -Wno-clobbered
> > -Wno-missing-field-initializers" ./configure -q && make -s
> > slru.c:63:1: warning: ‘inline’ is not at
Alexander Lakhin writes:
> And a warning:
> $ CC=gcc-12 CFLAGS="-Wall -Wextra -Wno-unused-parameter -Wno-sign-compare
> -Wno-clobbered
> -Wno-missing-field-initializers" ./configure -q && make -s
> slru.c:63:1: warning: ‘inline’ is not at beginning of declaration
> [-Wold-style-declaration]
>
Андрей, привет!
Текущее положение у меня такое.
.
*pg_stats and range statisticsTracking statements entry timestamp in
pg_stat_statements*
Уже закоммичены.
*XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL
15)*
Если всё будет и замечаний не возникнет ок, завтра утром
Hello Alexander,
27.11.2023 02:43, Alexander Korotkov wrote:
v61 looks good to me. I'm going to push it as long as there are no objections.
I've looked at the patch set and found a typo:
occured
And a warning:
$ CC=gcc-12 CFLAGS="-Wall -Wextra -Wno-unused-parameter -Wno-sign-compare
Alexander, Maxim,
Thank you for revisions.
On Thu, Nov 9, 2023 at 6:22 PM Maxim Orlov wrote:
> Aleksander Alekseev,
>
> > Maxim,
> > I see both of us accounted for Alexanders feedback and submitted v59.
> > Your newer version seems to have issues on cfbot, so resubmitting the
> > previous
Aleksander Alekseev,
> Maxim,
> I see both of us accounted for Alexanders feedback and submitted v59.
> Your newer version seems to have issues on cfbot, so resubmitting the
> previous patchset that passes the tests. Please feel free to add
> changes.
For unknown reasons, I do not receive any of
Maxim,
I see both of us accounted for Alexanders feedback and submitted v59.
Your newer version seems to have issues on cfbot, so resubmitting the
previous patchset that passes the tests. Please feel free to add
changes.
> See SlruCorrectSegmentFilenameLength():
>
> ```
> if
On Mon, 6 Nov 2023 at 16:07, Alexander Korotkov
wrote:
> Hi!
>
> On Wed, Jul 5, 2023 at 4:46 PM Aleksander Alekseev <
> aleksan...@timescale.com> wrote:
> > PFE the corrected patchset v58.
>
> I'd like to revive this thread.
>
Hi! Great news!
> BTW, there is a typo in a word "exceeed".
>
Hi again,
> PFA the corrected patchset v59.
On second thought, I believe this Assert is incorrect:
```
+else
+{
+Assert(segno >= 0 && segno <= 0x);
+return snprintf(path, MAXPGPATH, "%s/%04X", (ctl)->Dir,
+(unsigned int) segno);
+}
```
Hi Alexander,
> -#define TransactionIdToCTsPage(xid) \
> - ((xid) / (TransactionId) COMMIT_TS_XACTS_PER_PAGE)
> +
> +/*
> + * Although we return an int64 the actual value can't currently exceeed
> 2**32.
> + */
> +static inline int64
> +TransactionIdToCTsPage(TransactionId xid)
> +{
> +
On Mon, Nov 6, 2023 at 4:38 PM Aleksander Alekseev
wrote:
> > > PFE the corrected patchset v58.
> >
> > I'd like to revive this thread.
>
> Many thanks for your comments and suggestions.
>
> > I think it worth adding asserts here to verify there is no overflow
making us mapping different segments
Alexander,
> > PFE the corrected patchset v58.
>
> I'd like to revive this thread.
Many thanks for your comments and suggestions.
> I think it worth adding asserts here to verify there is no overflow making us
> mapping different segments into the same files.
Sorry, I didn't understand this
Hi,
> > > If I remember right, the compiler will make equivalent code from
> > > inline functions and macros, and functions has an additional benefit:
> > > the compiler will report type mismatch if any. That was the only
> > > reason.
> >
> > Then it's OK to leave it as an inline function.
+1
On Mon, 6 Nov 2023 at 18:01, Alexander Korotkov wrote:
>
> On Mon, Nov 6, 2023 at 3:42 PM Pavel Borisov wrote:
> >
> > On Mon, 6 Nov 2023 at 17:07, Alexander Korotkov
> > wrote:
> > > On Wed, Jul 5, 2023 at 4:46 PM Aleksander Alekseev
> > > wrote:
> > > > PFE the corrected patchset v58.
> >
On Mon, Nov 6, 2023 at 3:42 PM Pavel Borisov wrote:
>
> On Mon, 6 Nov 2023 at 17:07, Alexander Korotkov wrote:
> > On Wed, Jul 5, 2023 at 4:46 PM Aleksander Alekseev
> > wrote:
> > > PFE the corrected patchset v58.
> >
> > I'd like to revive this thread.
> >
> > This patchset is extracted from
On Mon, 6 Nov 2023 at 17:07, Alexander Korotkov wrote:
>
> Hi!
>
> On Wed, Jul 5, 2023 at 4:46 PM Aleksander Alekseev
> wrote:
> > PFE the corrected patchset v58.
>
> I'd like to revive this thread.
>
> This patchset is extracted from a larger patchset implementing 64-bit xids.
> It converts
Hi!
On Wed, Jul 5, 2023 at 4:46 PM Aleksander Alekseev
wrote:
> PFE the corrected patchset v58.
I'd like to revive this thread.
This patchset is extracted from a larger patchset implementing 64-bit
xids. It converts page numbers in SLRUs into 64 bits. The most SLRUs save
the same file naming
___
发件人: Aleksander Alekseev
发送时间: 2023年9月4日 22:41
收件人: Postgres hackers
抄送: Heikki Linnakangas ; Maxim Orlov ;
Jacob Champion ; Japin Li ;
Andres Freund ; Michael Paquier ;
Pavel Borisov ; Peter Eisentraut
; Alexander Korotkov
主题: Re: XID formatting and SLRU refactorings (wa
Hi,
> > Reviewing this now. I think it's almost ready to be committed.
> >
> > There's another big effort going on to move SLRUs to the regular buffer
> > cache (https://commitfest.postgresql.org/43/3514/). I wonder how moving
> > to 64 bit page numbers will affect that. BlockNumber is still 32
Hi,
> Reviewing this now. I think it's almost ready to be committed.
>
> There's another big effort going on to move SLRUs to the regular buffer
> cache (https://commitfest.postgresql.org/43/3514/). I wonder how moving
> to 64 bit page numbers will affect that. BlockNumber is still 32 bits,
>
On 09/03/2023 17:21, Aleksander Alekseev wrote:
v57-0001-Index-SLRUs-by-64-bit-integers-rather-than-by-32.patch
Reviewing this now. I think it's almost ready to be committed.
There's another big effort going on to move SLRUs to the regular buffer
cache
Hi,
> This patch hasn't applied in quite some time, and the thread has moved to
> discussing higher lever items rather than the suggested patch, so I'm closing
> this as Returned with Feedback. Please feel free to resubmit when there is
> renewed interest and a concensus on how/what to proceed
This patch hasn't applied in quite some time, and the thread has moved to
discussing higher lever items rather than the suggested patch, so I'm closing
this as Returned with Feedback. Please feel free to resubmit when there is
renewed interest and a concensus on how/what to proceed with.
--
Hi,
> As suggested before by Heikki Linnakangas, I've added a patch for making 2PC
> transaction state 64-bit.
> At first, my intention was to rebuild all twophase interface to use
> FullTransactionId. But doing this in a proper
> manner would lead to switching from TransactionId to
Hi!
As suggested before by Heikki Linnakangas, I've added a patch for making
2PC transaction state 64-bit.
At first, my intention was to rebuild all twophase interface to use
FullTransactionId. But doing this in a proper
manner would lead to switching from TransactionId to FullTransactionId in
Hi,
> 1. Use internal 64 bit page numbers in SLRUs without changing segments naming.
> 2. Use the larger segment file names in async.c, to lift the current 8
> GB limit on the max number of pending notifications.
> [...]
>
> Where our main focus for PG16 is going to be 1 and 2, and we may try
>
On Tue, 7 Mar 2023 at 15:38, Heikki Linnakangas wrote:
>
> That is true for pg_multixact/offsets. We will indeed need to add an
> epoch and introduce the concept of FullMultiXactIds for that. However,
> we can change pg_multixact/members independently of that. We can extend
> MultiXactOffset
Hi,
> Here's how I see the development path for this [...]
> So, in my view, the plan should be [...]
> Thoughts?
The plan looks great! I would also explicitly include this:
> As we start to refactor these things, I also think it would be good to
> have more explicit tracking of the valid
On 07/03/2023 13:38, Maxim Orlov wrote:
As for making pg_multixact 64 bit, I spend the last couple of days to
make proper pg_upgrade for pg_multixact's and for pg_xact's
with wraparound and I've understood, that it is not a simple task
compare to pg_xact's. The problem is, we do not have epoch
On Tue, 17 Jan 2023 at 16:33, Aleksander Alekseev
wrote:
> Hi hackers,
>
> Maxim, perhaps you could share with us what your reasoning was here?
>
> I'm really sorry for late response, but better late than never. Yes, we
can not access shared memory without lock.
In this particular case, we use
On 01/03/2023 12:21, Aleksander Alekseev wrote:
Hi,
I'm surprised that these patches extend the page numbering to 64 bits,
but never actually uses the high bits. The XID "epoch" is not used, and
pg_xact still wraps around and the segment names are still reused. I
thought we could stop doing
Hi,
> I'm surprised that these patches extend the page numbering to 64 bits,
> but never actually uses the high bits. The XID "epoch" is not used, and
> pg_xact still wraps around and the segment names are still reused. I
> thought we could stop doing that.
To clarify, the idea is to let CLOG
On 28/02/2023 16:17, Maxim Orlov wrote:
Either I do not understand something, or the files from pg_commit_ts
directory are not copied.
Huh, yeah you're right, pg_upgrade doesn't copy pg_commit_ts.
- Heikki
On Mon, 27 Feb 2023 at 12:10, Heikki Linnakangas wrote:
> (CC list trimmed, gmail wouldn't let me send otherwise)
>
> That sounds right for pg_serial, pg_notify, and pg_subtrans. But not for
> pg_commit_ts and the pg_multixacts.
>
> This needs tests for pg_upgrading those SLRUs, after 0, 1 and N
(CC list trimmed, gmail wouldn't let me send otherwise)
On 22/02/2023 16:29, Maxim Orlov wrote:
On Tue, 21 Feb 2023 at 16:59, Aleksander Alekseev
mailto:aleksan...@timescale.com>> wrote:
One thing that still bothers me is that during the upgrade we only
migrate the CLOG segments (i.e.
On Tue, 21 Feb 2023 at 16:59, Aleksander Alekseev
wrote:
> Hi,
>
> One thing that still bothers me is that during the upgrade we only
> migrate the CLOG segments (i.e. pg_xact / pg_clog) and completely
> ignore all the rest of SLRUs:
>
> * pg_commit_ts
> * pg_multixact/offsets
> *
Hi,
> The convert_pg_xact_segments() function is still obviously
> overengineered. As I understand, all it has to do is simply renaming
> pg_xact/ to pg_xact/. Unfortunately I used up all the
> mana for today and have to take a long rest in order to continue.
PFA the corrected
Hi,
> OK, here is the patchset v53 where I mostly modified the commit
> messages. It is explicitly said that 0001 modifies the WAL records and
> why we decided to do it in this patch. Additionally any mention of
> 64-bit XIDs is removed since it is not guaranteed that the rest of the
> patches
Hi hackers,
> Yeah, pg_upgrade will briefly start and stop the old server to make
> sure all the WAL is replayed, and won't transfer any of the files
> over. AFAIK, major-version WAL changes are fine; it was the previous
> claim that we could do it in a minor version that I was unsure about.
OK,
On Wed, Jan 11, 2023 at 1:48 AM Aleksander Alekseev
wrote:
> After reading [1] carefully it looks like we shouldn't worry about
> this. The upgrade procedure explicitly requires to run `pg_ctl stop`
> during step 8 of the upgrade procedure, i.e. not in the immediate mode
> [2].
Yeah, pg_upgrade
Hi Maxim,
> Secondly, shouldn't we introduce a new WAL record type in order to
> make the code backward compatible with previous PG versions? I'm not
> 100% sure how the upgrade procedure works in all the details. If it
> requires the DBMS to be gracefully shut down before the upgrade then
> we
Hi Maxim,
> Here is a new patch set.
> I've added comments and make use GetClogDirName call in copy_subdir_files.
Jacob Champion pointed out (offlist, cc:'ed) that we may be wrong on this one:
> 0001 patch changes the SLRU internals without affecting the callers.
> 0001 - should make SLRU
Hi Maxim,
> Anyway. Let's discuss on-disk page format, shall we?
Here are my two cents.
> AFAICS, we have a following options:
> [...]
> 2. Put special in every page where base for XIDs are stored. This is what we
> have done in the current patch set.
The approach of using special space IMO
Hi!
Here is a new patch set.
I've added comments and make use GetClogDirName call in copy_subdir_files.
--
Best regards,
Maxim Orlov.
v52-0003-Make-pg_upgrade-from-32-bit-to-64-bit-SLRU.patch
Description: Binary data
v52-0002-Use-64-bit-pages-representation-in-SLRU-callers.patch
On Fri, 6 Jan 2023 at 09:51, Japin Li wrote:
>
> For v51-0003. We can use GetClogDirName instead of GET_MAJOR_VERSION in
> copy_subdir_files().
>
Of course! Tanks! I'll address this in the next iteration, v52.
--
Best regards,
Maxim Orlov.
Hi Andrey,
> Hi! I think that 64-bit xids are a very important feature and I want
> to help advance it. That's why I want to try to understand a patch
> better.
Thanks for your interest to the patchset!
> Do I get it right that the proposed v51 patchset only changes the SLRU
> filenames and
>
> Do I get it right that the proposed v51 patchset only changes the SLRU
> filenames and type of pageno representation? Is SLRU wraparound still
> exactly there after 0x byte?
>
After applying the whole patch set, SLRU will become 64–bit without a
wraparound. Thus, no wraparound
should
On Mon, 19 Dec 2022 at 22:40, Maxim Orlov wrote:
> Hi!
>
> As a result of discussion in the thread [0], Robert Haas proposed to focus
> on making SLRU 64 bit, as a first step towards 64 bit XIDs.
> Here is the patch set.
>
> In overall, code of this patch set is based on the existing code from
On Mon, Dec 19, 2022 at 6:41 AM Maxim Orlov wrote:
>
> As always, reviews and opinions are very welcome.
Hi! I think that 64-bit xids are a very important feature and I want
to help advance it. That's why I want to try to understand a patch
better.
Do I get it right that the proposed v51
n Knizhnik ;
Nikita Glukhov ; Yura Sokolov
; Simon Riggs
主题: Re: Add 64-bit XIDs into PostgreSQL 15
Hi!
I want to make a quick summary here.
1. An overall consensus has been reached: we shall focus on committing SLRU
changes first.
2. I've created an appropriate patch set here [0].
3. How
Hi!
I want to make a quick summary here.
1. An overall consensus has been reached: we shall focus on committing SLRU
changes first.
2. I've created an appropriate patch set here [0].
3. How [0] is waiting for a review. As always, all opinions will be welcome.
4. While discussing error/warning
Hi!
As a result of discussion in the thread [0], Robert Haas proposed to focus
on making SLRU 64 bit, as a first step towards 64 bit XIDs.
Here is the patch set.
In overall, code of this patch set is based on the existing code from [0]
and may be simplified, due to the fact, that
On Fri, 9 Dec 2022 at 16:54, adherent postgres <
adherent_postg...@hotmail.com> wrote:
> Hi Aleksander Alekseev
> I think the xids 32bit transformation project has been dragged on for too
> long. Huawei's openGauss referenced this patch to implement xids 64bit, and
> Postgrespro also implemented
opinion?
Best whish
发件人: Pavel Borisov
发送时间: 2022年12月9日 22:13
收件人: adherent postgres
抄送: Aleksander Alekseev ;
pgsql-hackers@lists.postgresql.org ; Chris
Travers ; Chris Travers ; Bruce
Momjian
主题: Re: Add 64-bit XIDs into PostgreSQL 15
Hi, Adherent!
On Fri, 9
Hi, Adherent!
On Fri, 9 Dec 2022 at 17:54, adherent postgres
wrote:
>
> Hi Aleksander Alekseev
> I think the xids 32bit transformation project has been dragged on for too
> long. Huawei's openGauss referenced this patch to implement xids 64bit, and
> Postgrespro also implemented xids 64bit,
> So I'd vote for an evolutionary approach and give my +1 for
> undertaking efforts to first committing [1] to 16.
>
> [1]:
> https://www.postgresql.org/message-id/CAFiTN-uudj2PY8GsUzFtLYFpBoq_rKegW3On_8ZHdxB1mVv3-A%40mail.gmail.com
>
> Kind regards,
> Pavel Borisov,
> Supabase.
>
+1 Totally
no reason not to implement xid 64
bit. What about your opinion?
Best whish
发件人: Aleksander Alekseev
发送时间: 2022年12月9日 20:49
收件人: pgsql-hackers@lists.postgresql.org
抄送: adherent postgres ; Chris Travers
; Chris Travers ; Bruce Momjian
主题: Re: Add 64-bit XIDs
Hi, Robert!
> Lest we miss the forest for the trees, there is an aspect of this
> patch that I find to be an extremely good idea and think we should try
> to get committed even if the rest of the patch set ends up in the
> rubbish bin. Specifically, there are a couple of patches in here that
>
Hi adherent,
> Robertmhaas said that the project Zheap is
> dead（https://twitter.com/andy_pavlo/status/1590703943176589312）, which means
> that we cannot use Zheap to deal with the issue of xid wraparound and dead
> tuples in tables. The dead tuple issue is not a big deal because I can
Haas
抄送: Chris Travers ; Bruce Momjian ;
Aleksander Alekseev ;
pgsql-hackers@lists.postgresql.org ; Chris
Travers ; Fedor Sigaev ; Alexander
Korotkov ; Konstantin Knizhnik ;
Nikita Glukhov ; Yura Sokolov
; Maxim Orlov ; Pavel Borisov
; Simon Riggs
主题: Re: Add 64-bit XIDs into PostgreSQL 15
On Wed, Dec 7, 2022 at 9:50 AM Andres Freund wrote:
> performing post-bootstrap initialization ...
> ../src/backend/access/transam/slru.c:1520:9: runtime error: load of
> misaligned address 0x7fff6362db8c for type 'int64', which requires 8 byte
> alignment
> 0x7fff6362db8c: note: pointer
Hi,
On 2022-12-07 11:40:08 +0300, Aleksander Alekseev wrote:
> Hi Michael,
>
> > The CF bot is showing some failures here. You may want to
> > double-check.
>
> Thanks! PFA v48.
This causes a lot of failures with ubsan:
https://cirrus-ci.com/task/6035600772431872
performing post-bootstrap
On Mon, Nov 21, 2022 at 12:21:09PM +0300, Aleksander Alekseev wrote:
> After merging 1489b1ce [1] the patchset needed a rebase. PFA v47.
>
> [1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=1489b1ce
The CF bot is showing some failures here. You may want to
double-check.
--
On Wed, Nov 30, 2022 at 8:13 AM Robert Haas wrote:
> I haven't checked the patches to see whether they look correct, and
> I'm concerned in particular about upgrade scenarios. But if there's a
> way we can get that part committed, I think it would be a clear win.
+1
--
Peter Geoghegan
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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,
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
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
>
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
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
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
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
>
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
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
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
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
1 - 100 of 223 matches
Mail list logo
