Postgresql 18beta1 and SPI changes
Dear members
We use are own version of DBmirror, we run our replication in a highly
fine grained manner. So every upgrade I have to make the code compile
and test. Up to PostgreSQL 17, I only got minor compilation problems
that I managed to resolve fairly easily. However this didn't prove to be
the case with PostgreSQL 18beta1, it proved harder to compile and as my
fears were verified, it has serious problems.
My question : is 18's SPI stabilized ? Can I start work on our version
of DBmirror ? Or wait for 18beta2 or -RC ?
Or is this not stabilized, which means there is a chance I found a
problem in postgresql's include system, so basically I contribute with
my test towards a 18beta2 or -RC ?
Sorry for not being more specific, my problems are far too many to start
asking more precise questions. After I get your opinion I will act
accordingly.
Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com> writes:
We use are own version of DBmirror, we run our replication in a highly
fine grained manner. So every upgrade I have to make the code compile
and test. Up to PostgreSQL 17, I only got minor compilation problems
that I managed to resolve fairly easily. However this didn't prove to be
the case with PostgreSQL 18beta1, it proved harder to compile and as my
fears were verified, it has serious problems.
My question : is 18's SPI stabilized ? Can I start work on our version
of DBmirror ? Or wait for 18beta2 or -RC ?
If you think there are changes we need to make, you'd better get
specific sooner not later. I'm not aware of any large fixes that
are pending, cf
https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
regards, tom lane
Dear All, Dear Tom
On 5/11/25 16:20, Tom Lane wrote:
Achilleas Mantzios<a.mantzios@cloud.gatewaynet.com> writes:
We use are own version of DBmirror, we run our replication in a highly
fine grained manner. So every upgrade I have to make the code compile
and test. Up to PostgreSQL 17, I only got minor compilation problems
that I managed to resolve fairly easily. However this didn't prove to be
the case with PostgreSQL 18beta1, it proved harder to compile and as my
fears were verified, it has serious problems.
My question : is 18's SPI stabilized ? Can I start work on our version
of DBmirror ? Or wait for 18beta2 or -RC ?If you think there are changes we need to make, you'd better get
specific sooner not later. I'm not aware of any large fixes that
are pending, cf
I attach
a) our old source (pending.c.orig), as of PostgreSQL 17 (tested for some
7 months, so pretty well tested),
b) the compilation errors when compiled against 18beta1, and
c) the patch that I came up with, which seems (in my minimal testing) to
yield correct results on 18beta1.
The majority of serious warnings have to do with de-toasting arrays and
the PK's int2vector , while the error has to do with getting column
details such as attisdropped and attname.
Please have a look, and share your thoughts. I haven't touched serious C
coding till I first wrote the above sometime in 2004 with a bunch of
additions some years ago.
Show quoted text
regards, tom lane
On 12/5/25 15:50, Achilleas Mantzios wrote:
Dear All, Dear Tom
On 5/11/25 16:20, Tom Lane wrote:
Achilleas Mantzios<a.mantzios@cloud.gatewaynet.com> writes:
We use are own version of DBmirror, we run our replication in a highly
fine grained manner. So every upgrade I have to make the code compile
and test. Up to PostgreSQL 17, I only got minor compilation problems
that I managed to resolve fairly easily. However this didn't prove to be
the case with PostgreSQL 18beta1, it proved harder to compile and as my
fears were verified, it has serious problems.
My question : is 18's SPI stabilized ? Can I start work on our version
of DBmirror ? Or wait for 18beta2 or -RC ?If you think there are changes we need to make, you'd better get
specific sooner not later. I'm not aware of any large fixes that
are pending, cfI attach
a) our old source (pending.c.orig), as of PostgreSQL 17 (tested for
some 7 months, so pretty well tested),b) the compilation errors when compiled against 18beta1, and
c) the patch that I came up with, which seems (in my minimal testing)
to yield correct results on 18beta1.The majority of serious warnings have to do with de-toasting arrays
and the PK's int2vector , while the error has to do with getting
column details such as attisdropped and attname.Please have a look, and share your thoughts. I haven't touched serious
C coding till I first wrote the above sometime in 2004 with a bunch of
additions some years ago.
Hi again
just to close this, it seems that the main issue for the compilation
fail was a change introduced in this commit :
d28dff3f6cd6a7562fb2c211ac0fb74a33ffd032 and had to do with access to
TupleDesc->attrs which does not exist anymore. Some browsing in the
contrib dir provided the hint I needed (to use : TupleDescAttr ).
The funny thing here is that deepseek spotted the issue before I even
pasted any piece of code, just mentioning. It would be nice if those SPI
level changes were mentioned somewhere.
Show quoted text
regards, tom lane