MIME-Version: 1.0
References: 
 <TY0PR0101MB45861E76766D327D06FAACB08E1C9@TY0PR0101MB4586.apcprd01.prod.exchangelabs.com>
In-Reply-To: 
 <TY0PR0101MB45861E76766D327D06FAACB08E1C9@TY0PR0101MB4586.apcprd01.prod.exchangelabs.com>
From: Aleksander Alekseev <aleksander@timescale.com>
Date: Fri, 9 Dec 2022 15:49:18 +0300
Message-ID: 
 <CAJ7c6TMnFQwAwZwdY7TH+L_fUzqdBeUee8MoR3EJj9CTP7F09w@mail.gmail.com>
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
To: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Cc: adherent postgres <adherent_postgres@hotmail.com>,
 Chris Travers <chris.travers@gmail.com>,
	Chris Travers <chris@orioledata.com>, Bruce Momjian <bruce@momjian.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJ7c6TMnFQwAwZwdY7TH%2BL_fUzqdBeUee8MoR3EJj9CTP7F09w%40mail.gmail.com>
Precedence: bulk

Hi adherent,

>      Robertmhaas said that the project Zheap is dead=EF=BC=88https://twit=
ter.com/andy_pavlo/status/1590703943176589312=EF=BC=89, 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 still use p=
g_repack to handle, although pg_repack will cause wal log to increase drama=
tically and may take one or two days to handle a large table. During this t=
ime the database can be accessed by external users, but the xid wraparound =
will cause PostgreSQL to be down, which is a disaster for DBAs. Maybe you a=
re not a DBA, or your are from a small country, Database system tps is very=
 low, so xid32 is  enough for your database system ,  Oracle's scn was also=
 32bits, however, Oracle realized the issue and changed scn to 64 bits. The=
 transaction id in mysql is 48 bits. MySQL didn't fix the transaction id wr=
aparound problem because they think that 48 bits is enough for the transact=
ion id. This project has been running for almost 1 year and now it is comin=
g to an end. I strongly disagree with your idea of stopping this patch, and=
 I suspect you are a saboteur. I strongly disagree with your viewpoint, as =
it is not a fundamental way to solve the xid wraparound problem. The Postgr=
eSQL community urgently needs developers who solve problems like this, not =
bury one' head in the sand

This is not uncommon for people on the mailing list to have
disagreements. This is part of the process, we all are looking for
consensus. It's true that different people have different use cases in
mind and different backgrounds as well. It doesn't mean these use
cases are wrong and/or the experience is irrelevant and/or the
received feedback should be just discarded.

Although I also expressed my disagreement with Chris before, let's not
assume any bad intent and especially sabotage as you put it. (Unless
you have a strong proof of this of course which I doubt you have.) We
want all kinds of feedback to be welcomed here. I'm sure our goal here
is mutual, to make PostgreSQL even better than it is now. The only
problem is that the definition of "better" varies sometimes.

I see you believe that 64-bit XIDs are going to be useful. That's
great! Tell us more about your case and how the patch is going to help
with it. Also, maybe you could test your load with the applied
patchset and tell us whether it makes things better or worse?
Personally I would love hearing this from you.

--=20
Best regards,
Aleksander Alekseev