From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Marco Slot <marco(dot)slot(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christoph Berg <myon(at)debian(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Subject: | Re: Potential ABI breakage in upcoming minor releases |
Date: | 2024-11-15 12:03:21 |
Message-ID: | CAJ7c6TMCc85YoiSKex5Sztz6bEmV-0YqL7FY=_MxxcyoMGTDfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Macro,
> I looked a bit at this out of interest. I see an assert failure in the
> lines below when running tests with TimescaleDB compiled against 17.0
> with 17.1 installed. Without the assertion it would anyway segfault
> below.
>
> /*
> * Usually, mt_lastResultIndex matches the target rel. If it happens not
> * to, we can get the index the hard way with an integer division.
> */
> whichrel = mtstate->mt_lastResultIndex;
> if (resultRelInfo != mtstate->resultRelInfo + whichrel)
> {
> whichrel = resultRelInfo - mtstate->resultRelInfo;
> Assert(whichrel >= 0 && whichrel < mtstate->mt_nrels);
> }
>
> updateColnos = (List *) list_nth(node->updateColnosLists, whichrel);
>
> The problem here is that because TimescaleDB compiled against 17.0
> assumes a struct size of 376 (on my laptop) while PostgreSQL allocated
> the array with a struct size of 384, so the pointer math no longer
> holds and the whichrel value becomes nonsense. (1736263376 for
> whatever reason)
Thanks for reporting. Yes, the code assumed fixed
sizeof(ResultRelInfo) within a given PG major release branch which
turned out not to be the case. We will investigate whether it can be
easily fixed on TimescaleDB side.
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | Man Zeng | 2024-11-15 12:06:41 | Re: [PATCH] Fixed assertion issues in "pg_get_viewdef" |
Previous Message | Maxim Orlov | 2024-11-15 11:59:00 | Re: Improve error messages for database object stats manipulation functions during recovery |