Re: ci: namespace ccache by PostgreSQL major version

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: ci: namespace ccache by PostgreSQL major version
Date: 2026-07-06 07:52:19
Message-ID: 71837b73-768c-4f58-b799-a4462ef0e102@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03.07.26 16:26, Nazir Bilal Yavuz wrote:
> Hi,
>
> When the Postgres major version is updated, CI fails with [1]:
>
> 2026-07-02 17:01:01.938 UTC [828] FATAL: incompatible library
> "D:/a/postgresql/postgresql/build/tmp_install/usr/local/pgsql/lib/utf8_and_win.dll":
> version mismatch
> 2026-07-02 17:01:01.938 UTC [828] DETAIL: Server is version 20,
> library is version 19.
>
> This happens because the GitHub Actions ccache is restored across a
> version bump, so objects built against the previous version can be
> reused, producing libraries that no longer match the server version.
>
> Here is an attempt to solve this problem by namespacing ccache by
> Postgres major version. I added a 'PG_MAJOR_VERSION' variable to the
> CI file and used that as a prefix to ccache key. I made this
> 'PG_MAJOR_VERSION' variable automatically updated by
> 'version_stamp.pl' script.
>
> Another solution could be reading the version from build files (e.g
> meson.build), but then this read needs to be done at each CI run.

I'm suspicious about this direction. The major version is not the only
piece of data that determines ABI compatibility between the server and
extensions. This would only be a partial information. The ABI
information exists in the code, and so changes should be visible to
ccache. Maybe we are using ccache in the wrong mode or something (see
"depend mode", "direct mode", etc.).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message JoongHyuk Shin 2026-07-06 07:53:44 Re: [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks
Previous Message Dilip Kumar 2026-07-06 07:44:27 Re: Proposal: Conflict log history table for Logical Replication