Re: Potential ABI breakage in upcoming minor releases
От | Tom Lane |
---|---|
Тема | Re: Potential ABI breakage in upcoming minor releases |
Дата | |
Msg-id | 2443809.1731683394@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Potential ABI breakage in upcoming minor releases (Aleksander Alekseev <aleksander@timescale.com>) |
Ответы |
Re: Potential ABI breakage in upcoming minor releases
|
Список | pgsql-hackers |
Aleksander Alekseev <aleksander@timescale.com> writes: > Hi Macro, >> 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. Yeah, the array-stride problem seems extremely hard to work around, because whichever size it is, you can't get code compiled with the other size to work. I believe ResultRelInfo is the only node type we use arrays of, so this was a particularly unfortunate place to break ABI, but there it is. I'm starting to lean to the opinion that we need a re-wrap. Given that padding holes exist, the code changes shouldn't be big. regards, tom lane
В списке pgsql-hackers по дате отправления: