Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1rnx-005SeR-39 for pgsql-bugs@arkaria.postgresql.org; Wed, 02 Sep 2026 20:43:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1x1rnw-00EAfq-2L for pgsql-bugs@arkaria.postgresql.org; Wed, 02 Sep 2026 20:43:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1x1rnw-00EAfi-0Y for pgsql-bugs@lists.postgresql.org; Wed, 02 Sep 2026 20:43:32 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1x1rnq-00000003h4a-03M9 for pgsql-bugs@lists.postgresql.org; Wed, 02 Sep 2026 20:43:31 +0000 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-c253425b253so239739566b.1 for ; Wed, 02 Sep 2026 13:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=splendiddata-com.20251104.gappssmtp.com; s=20251104; t=1788381799; x=1788986599; darn=lists.postgresql.org; h=in-reply-to:organization:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:content-type:from :to:cc:subject:date:message-id:reply-to:content-type; bh=JGP3P0Hq06UbAqKY3zqfHIYjsZ5Ks9gZoRMpdCZC+aA=; b=OKlfQ9E8v9aNq+UQoXzE9nY/qNRjhpaVug9zQSufJUxQEqaccKFCyShO/JmbNlcX6Y pLJBQ9rSLVL8VX2VN63tuelOnHOGtwUDOkF65SwbOMvrlZxlVroxlx39TddEeTLQJx3k AlDVWDWA24scMBKN4qgavBiMpBBhIVmbpOm58z+2JM/RaQZ5HI3y2DO+vR+FiCXyKTpz G/WnjWJ9VWKHNUqdUrD1L80BCkPNnC70OJlqplKeb2oVWyeB+CjZsUJry5bhaag13TpQ qvuCWzjcQzRok5SWBSTuvuP3wRpzdbNeK0tbVFcn7l2txWQXYLC5WtGP59I4dk1FqxrD X4qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788381799; x=1788986599; h=in-reply-to:organization:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:content-type :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=JGP3P0Hq06UbAqKY3zqfHIYjsZ5Ks9gZoRMpdCZC+aA=; b=dbN0nOnaMP8qQXbcFswwIS3LGjGg+zzPvcSmxz+zD9ihV+GkxkIJH+3YQSX4fgWM6F 0RP71PUMN7TU7w4q8JOwwoPMedbiqjxJ22vVYcI1wJiCaVSY4txPi3TrIt03CKteOsz2 +/Gn36MRFinUNGKwSZ4G9pU7Y4ehjcOCo/ZEl2Cr8HJrOXgz+kJwU6elBGh6B8X+CNyj lxh84AsGIbrCiAAAGpwyqPC4g5w2Tzaj8gXYXMnrL304+SHvPWcFevmTSIMbNhonatE2 Ipg+6IruRipM7v7i0tN37ZUVxbK22M8N9pFvAjDi9r4kTGbRZw72Xf9zswLOcWywCpb6 W8MA== X-Gm-Message-State: AFuF++neo9Fv6v+tb0Fnj7lDIDgJdBqknzKsUKo3WHbB1IXQreEAbdNY TF+JvqVR6yTitKCG//fr/yC6v4WDxzkFvITcFGJpnxQMFk7Nal2h5DRd1iOPVP0a7ZM= X-Gm-Gg: AYBFou2Q2whIPfJ1yLVq13KFqSx1qMSlA4BjIBNg8zV2m3PlN9pSZ2YIalvqr5tc0XQ 7PtSvBRaTHHQLe08EELZi81XNJ2uDMjY2WsXeGSHIEEhIPLgdXpu52Qm0BByXvz6dHNsd3tkmsU cfcpf914hq15VtKkb1jME/mBNL3KeV35ziK09NZ/p3CtVnSJYqjDiYY44NXve0AfxvkMlkt3zBP JRqlbSpybeD6DAu5QtM3Zu9lpEzlW/Zd9PH92RzXUbQuUizNwFjtli6tQGD1hW43sq1u3xlVBLO E5jnkV2Y/8toRibDJLkSuPpemsAy536DsD5v5JrxNsQ5GDvcJqs+W9s26cXjuk99Fh41UHeSrd+ 8HY5MvTDbNQgsgsQeBTzAPt7KdOD+7g+2v8YuRsPw3Zl4nq9n79ilKjv4fMXwaCF5XjScBqzImS X9SPpT6OGcfSjE3agUX4vFbKgJhwQBHHtIkhY94EbRlyEGqXpw3BSA0sCxSr8sx3dsrZStriumq 46pOs1D+P2gtmipYO3zKu6foKlSHwo3jPK/slwOAjNmqQDpK1+2NGVfRfifsDO2cvbAJKUkkx2O v66jlUKtGDtV6iu94+fH1u2Iv7Y= X-Received: by 2002:a17:907:1c92:b0:c25:2fb9:b897 with SMTP id a640c23a62f3a-c25d5470752mr583101166b.18.1788381799155; Wed, 02 Sep 2026 13:43:19 -0700 (PDT) Received: from ?IPV6:2a02:a476:17ec:0:8b8:c455:28e3:45cf? (2a02-a476-17ec-0-8b8-c455-28e3-45cf.fixed6.kpn.net. [2a02:a476:17ec:0:8b8:c455:28e3:45cf]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c25f4244e45sm8696366b.60.2026.09.02.13.43.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2026 13:43:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------tFUx0qzgwlKwCopAoOm6n0b7" Message-ID: Date: Wed, 2 Sep 2026 22:43:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #19647: Difference in pg_basebackup behaviour between PostgreSQL <= 16 and >= 17 with pgactive extension To: Jacob Champion Cc: pgsql-bugs@lists.postgresql.org References: <19647-d18354ebe2134a6d@postgresql.org> Content-Language: en-US From: Edwin Polkerman Organization: Splendid Data Nederland B.V. In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------tFUx0qzgwlKwCopAoOm6n0b7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jacob, Yes, the 18.6 and 17.11 global/ directory contains this file as well. Doing a pg_checksums on the data directory gives exactly the same result as for the PostgreSQL 16.15, 15.19 and 14.24: pg_checksums -c /var/pgpure/postgres/18/cluster2/ pg_checksums: error: invalid segment number 0 in file name "/var/pgpure/postgres/18/cluster2//global/pgactive.stat" The file pgactive.stat is placed in the globals directory when the database server is stopped / started after installation of the extension and setup of the replication group. I think it is used for internal bookkeeping for replication statussen with the other node(s) in the replication group when the node is shutdown. Because of the difference in behaviour of pg_basebackup what dazzled me, it made me decide to create the issue in the pgql-bugs mailing list. Please let me know if it is not PostgreSQL related and if it should be created in github at AWS/pgactive Kind regards, Edwin On 9/2/26 20:51, Jacob Champion wrote: > On Tue, Sep 1, 2026 at 6:16 AM PG Bug reporting form > wrote: >> For PostgreSQL 18.6 and 17.11 the backup completes without any problems. > Do the global/ directories for the 17 and 18 clusters contain a > pgactive.stat file? > > Without knowing anything about pgactive in particular (it's a > third-party extension)... It sure looks like that extension, or else > something related to it, has put a random file into the DB internals > in a way that won't pass our checksum verification. It needs to go > somewhere else. > > --Jacob -- Splendid Data Nederland B.V. Binnenhof 62A 1412 LC NAARDEN +31 85 773 19 99 +31 6 5118 8231 *Follow us on LinkedIn * --------------tFUx0qzgwlKwCopAoOm6n0b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Jacob,

Yes, the 18.6 and 17.11 global/ directory contains this file as well.

Doing a pg_checksums on the data directory gives exactly the same result as for the PostgreSQL 16.15, 15.19 and 14.24:

pg_checksums -c /var/pgpure/postgres/18/cluster2/
pg_checksums: error: invalid segment number 0 in file name "/var/pgpure/postgres/18/cluster2//global/pgactive.stat"

The file pgactive.stat is placed in the globals directory when the database server is stopped / started after installation of the extension and setup of the replication group. I think it is used for internal bookkeeping for replication statussen with the other node(s) in the replication group when the node is shutdown.

Because of the difference in behaviour of pg_basebackup what dazzled me, it made me decide to create the issue in the pgql-bugs mailing list. Please let me know if it is not PostgreSQL related and if it should be created in github at AWS/pgactive

Kind regards,
Edwin 

On 9/2/26 20:51, Jacob Champion wrote:
On Tue, Sep 1, 2026 at 6:16 AM PG Bug reporting form
<noreply@postgresql.org> wrote:
For PostgreSQL 18.6 and 17.11 the backup completes without any problems.
Do the global/ directories for the 17 and 18 clusters contain a
pgactive.stat file?

Without knowing anything about pgactive in particular (it's a
third-party extension)... It sure looks like that extension, or else
something related to it, has put a random file into the DB internals
in a way that won't pass our checksum verification. It needs to go
somewhere else.

--Jacob
--

Splendid Data Nederland B.V.
Binnenhof 62A
1412 LC NAARDEN
+31 85 773 19 99
+31 6 5118 8231

Follow us on LinkedIn
--------------tFUx0qzgwlKwCopAoOm6n0b7--