Skip to content

Fix postgres-decoderbufs build against PostgreSQL 19.#34

Closed
devrimgunduz wants to merge 1 commit into
debezium:mainfrom
devrimgunduz:main
Closed

Fix postgres-decoderbufs build against PostgreSQL 19.#34
devrimgunduz wants to merge 1 commit into
debezium:mainfrom
devrimgunduz:main

Conversation

@devrimgunduz

Copy link
Copy Markdown

PG19 introduced several source-incompatible changes that this patch addresses in src/decoderbufs.c:

  1. AssertVariableIsOfType was renamed to StaticAssertVariableIsOfType (upstream commit "Rename AssertVariableIsOfType to StaticAssertVariableIsOfType"). The old name no longer exists, so _PG_output_plugin_init() originally failed with an implicit-declaration error.

    However, simply switching to StaticAssertVariableIsOfType() trades that error for a new one: PG19's c.h defines that macro in terms of the bare typeof keyword, which only exists under a GNU C dialect or C23 -- it is not available under strict -std=c11/-std=c17, which is the dialect PGXS's own CFLAGS select on this build. So the upstream macro itself fails to compile here ("unknown type name 'typeof'"), independent of anything in decoderbufs.

    Fixed by performing the same compile-time type check ourselves on PG19+, using the double-underscored __typeof__ GNU extension (which, unlike bare typeof, remains available in strict-ANSI modes on both gcc and clang) together with c.h's own StaticAssertDecl and __builtin_types_compatible_p. This check is purely a compile-time sanity check with no effect on behavior, so it is simply skipped (via an inner #if) on any toolchain lacking the builtin, rather than trying to fail the build.

  2. VARATT_IS_EXTERNAL_ONDISK() now takes a const void * instead of silently accepting a Datum. tuple_to_tuple_msg() was passing the raw Datum (origval), which is an integer type on this platform, causing "makes pointer from integer without a cast". Fixed by wrapping the argument with DatumGetPointer(), which is correct and a no-op change on all supported PG versions.

  3. ReorderBufferTXN no longer has an xact_time member. Upstream commit "Make some use of anonymous unions [reorderbuffer xact_time]" turned the xact_time union into an anonymous union embedded directly in ReorderBufferTXN, so commit_time (as well as prepare_time / abort_time) is once again accessed directly as txn->commit_time, the same way it was before PG15 introduced the named xact_time union. This affected pg_decode_begin_txn(), pg_decode_commit_txn(), and pg_decode_change(). Fixed by adding a PG_VERSION_NUM >= 190000 branch that uses txn->commit_time directly, while keeping the txn->xact_time.commit_time path for PG15-PG18 and the pre-PG15 txn->commit_time path unchanged.

No behavioral changes for PG15-PG18 or earlier; this is purely a compatibility fix so the extension builds on PG19 as well.

Hacked by Claude, tested by me.

Per pgdg-packaging/pgdg-rpms#213

PG19 introduced several source-incompatible changes that this patch
addresses in src/decoderbufs.c:

1. `AssertVariableIsOfType` was renamed to `StaticAssertVariableIsOfType`
   (upstream commit "Rename AssertVariableIsOfType to
   StaticAssertVariableIsOfType"). The old name no longer exists, so
   _PG_output_plugin_init() originally failed with an
   implicit-declaration error.

   However, simply switching to StaticAssertVariableIsOfType() trades
   that error for a new one: PG19's c.h defines that macro in terms of
   the bare `typeof` keyword, which only exists under a GNU C dialect
   or C23 -- it is not available under strict `-std=c11`/`-std=c17`,
   which is the dialect PGXS's own CFLAGS select on this build. So the
   upstream macro itself fails to compile here ("unknown type name
   'typeof'"), independent of anything in decoderbufs.

   Fixed by performing the same compile-time type check ourselves on
   PG19+, using the double-underscored `__typeof__` GNU extension
   (which, unlike bare `typeof`, remains available in strict-ANSI
   modes on both gcc and clang) together with c.h's own
   `StaticAssertDecl` and `__builtin_types_compatible_p`. This check is
   purely a compile-time sanity check with no effect on behavior, so it
   is simply skipped (via an inner #if) on any toolchain lacking the
   builtin, rather than trying to fail the build.

2. `VARATT_IS_EXTERNAL_ONDISK()` now takes a `const void *` instead of
   silently accepting a `Datum`. tuple_to_tuple_msg() was passing the
   raw Datum (`origval`), which is an integer type on this platform,
   causing "makes pointer from integer without a cast". Fixed by
   wrapping the argument with DatumGetPointer(), which is correct and
   a no-op change on all supported PG versions.

3. `ReorderBufferTXN` no longer has an `xact_time` member. Upstream
   commit "Make some use of anonymous unions [reorderbuffer xact_time]"
   turned the `xact_time` union into an anonymous union embedded
   directly in ReorderBufferTXN, so `commit_time` (as well as
   `prepare_time` / `abort_time`) is once again accessed directly as
   txn->commit_time, the same way it was before PG15 introduced the
   named `xact_time` union. This affected pg_decode_begin_txn(),
   pg_decode_commit_txn(), and pg_decode_change(). Fixed by adding a
   `PG_VERSION_NUM >= 190000` branch that uses txn->commit_time
   directly, while keeping the txn->xact_time.commit_time path for
   PG15-PG18 and the pre-PG15 txn->commit_time path unchanged.

No behavioral changes for PG15-PG18 or earlier; this is purely a
compatibility fix so the extension builds on PG19 as well.
@github-actions

Copy link
Copy Markdown

❌ Developer Certificate of Origin (DCO) check failed.

Hi @devrimgunduz, please sign off all commits with:

git commit -s

If pull request commits are not signed off, the pull request cannot be merged. For more information about why this is required, please see our blog about contribution requirement changes.

@devrimgunduz

Copy link
Copy Markdown
Author

Will submit another one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant