RE: analyze-in-stages post upgrade questions

[Zechman, Derek S]

> > Well, that wouldn't explain why it doesn't work on partitioned tables.

> > I am under the impression that it should.

> >

> > Derek, can cou share the pg_stats entries for the partitioned table?

>

> There are no entries in pg_stats for the parent table until after I manually 
> run an analyze on it – Example below



You are right.  I looked at the code, and "vacuumdb" does not process

partitiond tables, even if --analyze-only is specified.  I find that

surprising, aince the SQL command ANALYZE (without a table name) will

also collect statistics for partitioned tables.



I think that it would be a good idea to change that behavior.

In particular, it makes a lot of sense to collect statistics for

partitioned tables after a "pg_upgrade".



Attached is a patch to make "vacuumdb --analyze-only" consider

partitioned tables as well.



Yours,

Laurenz Albe



Is there a plan to include this patch in future releases/patches of postgres?



Thanks,

(Derek) Sean

Re: Password Encryption and Connection Issues

[David G. Johnston]

On Wed, Jul 9, 2025 at 6:57 AM Alpaslan AKDAĞ 
wrote:

>
>1. In such a case, what would be the recommended approach or best
>practice to follow during upgrades in order to avoid this kind of issue?
>
> This is all described quite clearly in the documentation, including the
upgrade procedure in the final paragraph.

https://www.postgresql.org/docs/current/auth-password.html

Given that pg_hba.conf still uses md5 I'm a bit confused regarding the
claim of some people being unable to authenticate; but you've provided
insufficient data to diagnose.  In any case, hopefully you can just change
all passwords to use scram and move on.

David J.

Password Encryption and Connection Issues

[Alpaslan AKDAĞ]

Hello all

We have recently upgraded our PostgreSQL instances from version 13 to 16.
During the upgrade, we also changed the password_encryption setting in
postgresql.conf to scram-sha-256.

Before the upgrade, we used pg_dumpall --roles-only to export all users and
their MD5-hashed passwords. After the upgrade, we executed this SQL script
to restore the users, and all users with their MD5 hashes were recreated
successfully.

However, we observed that:

   -

   New users created under the scram-sha-256 encryption setting have
   passwords starting with SCRAM-SHA-256$4096: in pg_authid.
   -

   The imported users still have passwords in the MD5 format, e.g.,
   md5a33e074800fe59f4ec8a123d0085d0e9.
   -

   Our pg_hba.conf still uses md5 as the authentication method.

As a result, some users are able to connect, while others cannot.

My questions are:

   1.

   Is it expected behavior that users created with scram-sha-256 passwords
   can still connect via md5 in pg_hba.conf?
   2.

   Under the current settings, is it still possible to use MD5-style
   password hashes for user creation? How does PostgreSQL treat this
   compatibility?
   3. In such a case, what would be the recommended approach or best
   practice to follow during upgrades in order to avoid this kind of issue?

Thank you in advance for your support.

Best regards,

Alpaslan

Re: error “server process was terminated by signal 11: Segmentation fault” running pg_create_logical_replication_slot using pgoutput plugin

[Shlok Kyal]

On Wed, 9 Jul 2025 at 12:19, Shlok Kyal  wrote:
>
> On Wed, 9 Jul 2025 at 11:43, abrahim abrahao  wrote:
> >
> > I got error “server process was terminated by signal 11: Segmentation 
> > fault” using pg_create_logical_replication_slot with pgoutput plugin 
> > parameter and using test_decoding worked fine, any idea that is wrong?
> >
> > Note: I am using docker container and I also updated shm-size from 1024mb 
> > to 2g and I am using shared_buffers=1.5GB.
> > This is a test server and there is nothing else running. IT is the first 
> > time I am working with logical replication.
> >
> > See details below
> >
> > postgresql.conf file:
> > wal_level = logical
> > max_replication_slots = 10
> > max_wal_senders = 20
> > listen_addresses = '*'
> >
> >
> >
> >  psql -U postgres -h postgres -c "SELECT 
> > pg_create_logical_replication_slot('support7561_repslot', 'pgoutput');"
> > SSL SYSCALL error: EOF detected
> > connection to server was lost
> >
> >
> > < 2025-07-08 14:57:08.653 UTC psql postgres postgres 172.18.0.94(53414) 
> > SELECT 0 2025-07-08 14:57:07 UTC 1096 686d31c3.448 2025-07-08 
> > 14:57:08.653 UTC > LOG:  Initializing CDC decoder
> > < 2025-07-08 14:57:08.653 UTC psql postgres postgres 172.18.0.94(53414) 
> > SELECT 0 2025-07-08 14:57:07 UTC 1096 686d31c3.448 2025-07-08 
> > 14:57:08.653 UTC > STATEMENT:  SELECT 
> > pg_create_logical_replication_slot('support7561_repslot', 'pgoutput');
> > < 2025-07-08 14:57:08.821 UTC  0 2025-07-08 14:55:38 UTC 923 
> > 686d316a.39b 2025-07-08 14:57:08.821 UTC > LOG:  server process (PID 1096) 
> > was terminated by signal 11: Segmentation fault
> > < 2025-07-08 14:57:08.821 UTC  0 2025-07-08 14:55:38 UTC 923 
> > 686d316a.39b 2025-07-08 14:57:08.821 UTC > DETAIL:  Failed process was 
> > running: SELECT pg_create_logical_replication_slot('support7561_repslot', 
> > 'pgoutput');
> > < 2025-07-08 14:57:08.821 UTC  0 2025-07-08 14:55:38 UTC 923 
> > 686d316a.39b 2025-07-08 14:57:08.821 UTC > LOG:  terminating any other 
> > active server processes
> > < 2025-07-08 14:57:08.829 UTC  0 2025-07-08 14:55:38 UTC 923 
> > 686d316a.39b 2025-07-08 14:57:08.829 UTC > LOG:  all server processes 
> > terminated; reinitializing
> > < 2025-07-08 14:57:09.215 UTC  0 2025-07-08 14:57:09 UTC 1098 
> > 686d31c5.44a 2025-07-08 14:57:09.215 UTC > LOG:  database system was 
> > interrupted; last known up at 2025-07-08 14:55:39 UTC
> > < 2025-07-08 14:57:10.037 UTC [unknown] postgres postgres 
> > 172.18.0.217(33506)  57P03 2025-07-08 14:57:10 UTC 1101 686d31c6.44d 
> > 2025-07-08 14:57:10.037 UTC > FATAL:  the database system is in recovery 
> > mode
> > < 2025-07-08 14:57:10.437 UTC  0 2025-07-08 14:57:09 UTC 1098 
> > 686d31c5.44a 2025-07-08 14:57:10.437 UTC > LOG:  database system was not 
> > properly shut down; automatic recovery in progress
> > < 2025-07-08 14:57:10.450 UTC  0 2025-07-08 14:57:09 UTC 1098 
> > 686d31c5.44a 2025-07-08 14:57:10.450 UTC > LOG:  redo starts at 1FB9/CA0
> > < 2025-07-08 14:57:10.456 UTC  0 2025-07-08 14:57:09 UTC 1098 
> > 686d31c5.44a 2025-07-08 14:57:10.456 UTC > LOG:  invalid record length at 
> > 1FB9/C054DF8: wanted 24, got 0
> > < 2025-07-08 14:57:10.456 UTC  0 2025-07-08 14:57:09 UTC 1098 
> > 686d31c5.44a 2025-07-08 14:57:10.456 UTC > LOG:  redo done at 1FB9/C054DC0 
> > system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
> > < 2025-07-08 14:57:10.475 UTC  0 2025-07-08 14:57:09 UTC 1099 
> > 686d31c5.44b 2025-07-08 14:57:10.475 UTC > LOG:  checkpoint starting: 
> > end-of-recovery immediate wait
> > < 2025-07-08 14:57:10.501 UTC  0 2025-07-08 14:57:09 UTC 1099 
> > 686d31c5.44b 2025-07-08 14:57:10.501 UTC > LOG:  checkpoint complete: wrote 
> > 86 buffers (0.0%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.010 
> > s, sync=0.007 s, total=0.028 s; sync files=18, longest=0.003 s, 
> > average=0.001 s; distance=339 kB, estimate=339 kB
> > < 2025-07-08 14:57:10.510 UTC  0 2025-07-08 14:55:38 UTC 923 
> > 686d316a.39b 2025-07-08 14:57:10.510 UTC > LOG:  database system is ready 
> > to accept connections
> >
> >
> >  psql -U postgres -h postgres -c "SELECT 
> > pg_create_logical_replication_slot('support7561_repslot', 'test_decoding');"
> >  pg_create_logical_replication_slot
> > 
> >  (support7561_repslot,1FB9/C081668)
> > (1 row)
> >
> > postgres@support7560_postgres:/var/lib/postgresql/15/main$ psql -U postgres 
> > -h postgres -c "SELECT slot_name, plugin, slot_type, database, active, 
> > restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;"
> >   slot_name  |plugin | slot_type | database | active | 
> > restart_lsn  | confirmed_flush_lsn
> > -+---+---+--++--+-
> >  support7561_repslot | test_decoding | logical   | postgres | f  | 
> > 1FB9/C081630 | 1FB9/C08166

Re: Password Encryption and Connection Issues

[Greg Sabino Mullane]

On Wed, Jul 9, 2025 at 9:57 AM Alpaslan AKDAĞ 
wrote:

> Is it expected behavior that users created with scram-sha-256 passwords
> can still connect via md5 in pg_hba.conf?


Yes. From the docs:

> To ease transition from the md5 method to the newer SCRAM method, if md5 is
> specified as a method in pg_hba.conf but the user's password on the
> server is encrypted for SCRAM (see below), then SCRAM-based authentication
> will automatically be chosen instead.


You can think of "md5" inside pg_hba.conf as "md5 or better"

As a result, some users are able to connect, while others cannot.


Can you expand on this? Nothing you have done should be preventing logins,
as far as I can tell.

Best solution: Upgrade everyone to scram, then change md5 to scram in
pg_hba.conf and never look back.

-- 
Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

Re: Password Encryption and Connection Issues

[Ron Johnson]

On Wed, Jul 9, 2025 at 10:59 AM Greg Sabino Mullane 
wrote:

> On Wed, Jul 9, 2025 at 9:57 AM Alpaslan AKDAĞ 
> wrote:
>
>> Is it expected behavior that users created with scram-sha-256 passwords
>> can still connect via md5 in pg_hba.conf?
>
>
> Yes. From the docs:
>
>> To ease transition from the md5 method to the newer SCRAM method, if md5 is
>> specified as a method in pg_hba.conf but the user's password on the
>> server is encrypted for SCRAM (see below), then SCRAM-based authentication
>> will automatically be chosen instead.
>
>
> You can think of "md5" inside pg_hba.conf as "md5 or better"
>
> As a result, some users are able to connect, while others cannot.
>
>
> Can you expand on this? Nothing you have done should be preventing logins,
> as far as I can tell.
>
> Best solution: Upgrade everyone to scram, then change md5 to scram in
> pg_hba.conf and never look back.
>

That requires setting the password to null and then recreating the
password, no?  Otherwise IIRC, changing an md5 password leaves the new
password also in md5 format.

-- 
Death to , and butter sauce.
Don't boil me, I'm still alive.
 lobster!

Re: Password Encryption and Connection Issues

[Adrian Klaver]

On 7/9/25 06:56, Alpaslan AKDAĞ wrote:

Hello all




As a result, some users are able to connect, while others cannot.


What client is being used and what version of said client?



Best regards,

Alpaslan




--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Corrupt btree index includes rows that don't match

[Erik Johnston]

Hi again,

Thanks very much for the replies last week. We’ve been continuing to 
investigate this problem, and I thought I’d share an update on where we are.


To recap: the situation is that, looking at our backup from 2025-06-26 
via pageinspect, we have btree index rows which point to either 
non-existent heap TIDs, or to heap TIDs with data which does not 
correspond to the index row. In fact it looks like we have entire index 
pages which point only to non-existent heap TIDs.


(I previously said that these index rows were marked as ‘dead’ in the 
backup. We now suspect this is an artifact of the restore process: we 
believe they are live in the backup, but were marked as dead during the 
restore.)


Empirically, and surprisingly to us, when one does a SELECT from an 
index entry that points to a non-existent TID, the index entry is 
quietly ignored.


We therefore suspect that this index corruption has been present for 
some time (possibly years); more recently those non-existent heap TIDs 
have been recycled, and that is when we have noticed the effects of the 
problem.



As far as we can tell, the corruption only affects one index on one 
table, and only a specific region of that index/table. Specifically, it 
only appears to affect rows which would have been inserted between 2018 
and January 2021. At least 1B rows appear to be affected (the table as a 
whole has 29B rows).


One thing that surprised us is that ‘amcheck’ didn’t find any sign of 
the corruption. We’re not completely sure if this is because we are 
holding it wrong, or because it’s simply out of scope or unsupported for 
amcheck. Any advice on this, or suggestions for other tooling we could 
use to check the consistency of our other indexes, would be much 
appreciated.


We’re still very interested in trying to understand the root cause of 
the corruption, mostly to confirm that it’s not an ongoing problem. 
Thanks Tom for the suggestion of 
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=4934d3875. 
We agree with your assessment that this is unlikely. For one thing, it 
looks like that bug could only conceivably cause this corruption if it 
affected an UPDATE query, and we’re reasonably sure we never do any 
UPDATE queries on that table. (The table is mostly append-only. We do 
sometimes run cleanup/compression jobs which amount to large amounts of 
interleaved DELETEs and INSERTs, but no UPDATEs.)


Back in 2021, we were running Postgres 10.11. We’ve taken a pass through 
the release notes since then to see if we can find any likely-looking 
bugs. We found the one that causes BRIN index corruption (this is not a 
BRIN index), and the one that causes CREATE INDEX CONCURRENTLY to end up 
with too *few* entries (this one has the opposite problem), but no 
particularly likely candidate. Any other suggestions would be welcome here.


At the moment, a historical hardware-level problem seems like it might 
be the most likely culprit, though we are a bit mystified about how any 
hardware failure could have caused such widespread damage to a single 
index, whilst apparently leaving the rest of the database intact.



Any thoughts or suggestions are very much appreciated.

Thanks,
Erik


On 04/07/2025 15:59, Erik Johnston wrote:



On Fri, 4 Jul 2025, 15:38 Ron Johnson,  wrote:

On Fri, Jul 4, 2025 at 9:49 AM Erik Johnston  wrote:

Hi, a quick update:

- We have discovered that the corruption was present from
before libicu update.
- We ran `pg_amcheck --index state_groups_state_type_idx
--heapallindexed matrix`, which returned nothing
- We believe that means that (and matches what we see
sampling) the index has gained extra entries, i.e. that for a
given state group it does return all the relevant rows in the
table /plus/ extra rows.

We are also seeing old state groups starting to point at rows
that have only just been inserted. For example, querying for
353864583 on the primary it returns that row plus four rows
that have been inserted today, but on the backup from last
week an index only scan for 353864583 only returns one row.
This makes it feel like the corruption is ongoing? Nothing
should have modified that state group in the interim (they are
generally immutable).

This naively feels like when inserting a new row we sometimes
add the row to the index twice: once pointing from the correct
state group to the new row, and once from an old state group
to the new row?


Are checksums enabled in the instance?


Alas not.

We've also now found that the index on the backup does in fact point 
to those ctids after all, but they are marked as dead. So at some 
point between then and when we inserted the new row at that ctid today 
those entries were marked undead.

--
Element Logo

_Copyright © 2023 Element - All rights reserved. The Element name, l

Re: Password Encryption and Connection Issues

[Greg Sabino Mullane]

> Best solution: Upgrade everyone to scram, then change md5 to scram in
> pg_hba.conf and never look back.
>

To expand more on the "upgrade everyone to scram", that means force all
users to set a new password while using scram (which should be the
default). You can do it yourself by getting a list of users and changing
their passwords inside psql:

-- List all users still stuck in md5-land:
greg=# select rolname from pg_authid where rolpassword ~ '^md5'
alice
eve
mallory
(3 rows)

-- Just in case, force use of scram
greg=# set password_encryption = 'scram-sha-256';
SET

-- Reset each user's password to some strong password of your choice:
greg=# \password alice
Enter new password for user "alice":
Enter it again:

-- Repeat the above until this query returns no rows:
select rolname from pg_authid where rolpassword ~ '^md5'

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

Re: PostgresSQL Setup error

[Adrian Klaver]

On 7/9/25 07:06, Jordan Adams wrote:

Hi Team,

Hope this email finds you well,

Apologies as I am unaware if this is the correct mailing address.

I would however like to inquire about an issue currently being 
experienced with Postgres with one of our external clients.


When doing the setup and following the steps accordingly with regards to 
adding the details for PostgreSQL Unicode ODBC Driver and testing, I run 
into an error where it states the below.


*note - I was provided with the username and password .

"psql: FATAL: password authentication failed"


Was that the complete message?

Not something like:

psql: error: connection to server at "localhost" (127.0.0.1), port 5482 
failed: FATAL:  password authentication failed for user "aklaver"



Also provide:

1) Postgres version.

2) Client version.



Please advise if assistance can be provided?


Kind Regards

Jordan Adams

IT Support

iSquared Technologies (Pty) Ltd

021 671 5778

http://www.isquared.co.za 

206 Main Road, Claremont, Cape Town 7708



Please send all support emails to supp...@isquared.co.za 
 and not to an engineer directly as they 
cannot respond to these emails. Please send all procurement requests to 
procurem...@isquared.co.za  Thanks.




--
Adrian Klaver
adrian.kla...@aklaver.com

Re: analyze-in-stages post upgrade questions

[Laurenz Albe]

On Wed, 2025-07-09 at 17:37 +0100, Mircea Cadariu wrote:
> Just to let you know that I have added a review through the commitfest app. 

Thanks!

The patch is still in state "needs review".
If there is something that I should change, you should set it to
"waiting on author".  If you think that the patch is ready to go
as it is, please set it to "ready for committer".

Yours,
Laurenz Albe

Re: Password Encryption and Connection Issues

[Ron Johnson]

On Wed, Jul 9, 2025 at 11:11 AM Adrian Klaver 
wrote:

> On 7/9/25 06:56, Alpaslan AKDAĞ wrote:
> > Hello all
> >
>
> > As a result, some users are able to connect, while others cannot.
>
> What client is being used and what version of said client?
>

This is a salient point:clients from the pre-PG10 can only connect using
md5.  Thus, we have to use md5 hashes even in PG16. 😭

-- 
Death to , and butter sauce.
Don't boil me, I'm still alive.
 lobster!

Re: Password Encryption and Connection Issues

[David G. Johnston]

On Wed, Jul 9, 2025 at 8:09 AM Ron Johnson  wrote:

> That requires setting the password to null and then recreating the
> password, no?
>

You might want to verify that claim, and suggest a doc patch or bug fix if
you find it to be true - I sure don't see anything that remotely suggests
this.

David J.

Re: analyze-in-stages post upgrade questions

[Laurenz Albe]

On Wed, 2025-07-09 at 11:30 +, Zechman, Derek S wrote:
> > > There are no entries in pg_stats for the parent table until after I 
> > > manually run an analyze on it – Example below
> >
> > You are right.  I looked at the code, and "vacuumdb" does not process
> > partitiond tables, even if --analyze-only is specified.  I find that
> > surprising, aince the SQL command ANALYZE (without a table name) will
> > also collect statistics for partitioned tables.
> >
> > I think that it would be a good idea to change that behavior.
> > In particular, it makes a lot of sense to collect statistics for
> > partitioned tables after a "pg_upgrade".
> >
> > Attached is a patch to make "vacuumdb --analyze-only" consider
> > partitioned tables as well.
> 
> Is there a plan to include this patch in future releases/patches of postgres? 

I have added the patch to the current commitfest:
https://commitfest.postgresql.org/patch/5871/

So far, it has not got any peer review.  So yes, I'd like to include
the patch, but I cannot make it happen by myself.
Essentially, patches get applied if
a) they get peer review and
b) a committer applies them

If you want this to happen, the best thing you could do would be
to review the patch and see if it works for you, if it does what you
need and so on:
https://wiki.postgresql.org/wiki/Reviewing_a_Patch

Yours,
Laurenz Albe

Re: PostgresSQL Setup error

[Laurenz Albe]

On Wed, 2025-07-09 at 14:06 +, Jordan Adams wrote:
> "psql: FATAL: password authentication failed"
> 
> Please advise if assistance can be provided?

Possibly.  That error will cause an error message in the PostgreSQL
server log.  Ask your DBA to find that error message and tell you
what it says.

Usually, the message means that you provided the wrong password.

To figure out what is going on, one would have to know how exactly
you are trying to connect (the connect string, the data source
definition) and what is in the database server's "pg_hba.conf".

Yours,
Laurenz Albe

Re: Password Encryption and Connection Issues

[Laurenz Albe]

On Wed, 2025-07-09 at 11:09 -0400, Ron Johnson wrote:
> > Best solution: Upgrade everyone to scram, then change md5 to scram
> > in pg_hba.conf and never look back.
> 
> That requires setting the password to null and then recreating the
> password, no?  Otherwise IIRC, changing an md5 password leaves the
> new password also in md5 format.

No.  The hashing algorithm chosen depends only on the current
setting of "password_encryption", not on the hashing algorithm
chosen for the previous password.

Yours,
Laurenz Albe

Re: Corrupt btree index includes rows that don't match

[Peter Geoghegan]

On Wed, Jul 9, 2025 at 1:02 PM Erik Johnston  wrote:
> To recap: the situation is that, looking at our backup from 2025-06-26 via 
> pageinspect, we have btree index rows which point to either non-existent heap 
> TIDs, or to heap TIDs with data which does not correspond to the index row. 
> In fact it looks like we have entire index pages which point only to 
> non-existent heap TIDs.

This is a generic symptom of corruption. You can see this sort of
thing whenever (say) the storage lies about fsync having flushed
everything to disk. The index might still contain TIDs that point to
heap pages that existed before the crash, that didn't survive crash
recovery. It's quite likely that those same TIDs will be used for
wholly unrelated logical rows when the application inserts a little
more data.

> Empirically, and surprisingly to us, when one does a SELECT from an index 
> entry that points to a non-existent TID, the index entry is quietly ignored.
>
> We therefore suspect that this index corruption has been present for some 
> time (possibly years); more recently those non-existent heap TIDs have been 
> recycled, and that is when we have noticed the effects of the problem.

That sounds plausible.

-- 
Peter Geoghegan

Re: Password Encryption and Connection Issues

[Ron Johnson]

On Wed, Jul 9, 2025 at 11:26 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:

> On Wed, Jul 9, 2025 at 8:09 AM Ron Johnson 
> wrote:
>
>> That requires setting the password to null and then recreating the
>> password, no?
>>
>
> You might want to verify that claim, and suggest a doc patch or bug fix if
> you find it to be true - I sure don't see anything that remotely suggests
> this.
>

You're right: I didn't recall properly.

-- 
Death to , and butter sauce.
Don't boil me, I'm still alive.
 lobster!

PostgresSQL Setup error

[Jordan Adams]

Hi Team,

Hope this email finds you well,

Apologies as I am unaware if this is the correct mailing address.

I would however like to inquire about an issue currently being experienced with 
Postgres with one of our external clients.

When doing the setup and following the steps accordingly with regards to adding 
the details for PostgreSQL Unicode ODBC Driver and testing, I run into an error 
where it states the below.

*note - I was provided with the username and password .

"psql: FATAL: password authentication failed"

Please advise if assistance can be provided?



Kind Regards

Jordan Adams



IT Support

iSquared Technologies (Pty) Ltd

021 671 5778

http://www.isquared.co.za

206 Main Road, Claremont, Cape Town 7708



Please send all support emails to supp...@isquared.co.za and not to an engineer 
directly as they cannot respond to these emails. Please send all procurement 
requests to procurem...@isquared.co.za

Re: analyze-in-stages post upgrade questions

[Mircea Cadariu]

Hi Laurenz,

On 09/07/2025 16:26, Laurenz Albe wrote:

I have added the patch to the current commitfest:
https://commitfest.postgresql.org/patch/5871/


Just to let you know that I have added a review through the commitfest app.

You can see it here: 
https://www.postgresql.org/message-id/flat/175189219162.2200286.3306593311375985296.p...@coridan.postgresql.org


Kind regards,

Mircea Cadariu

RE: error “server process was terminated by signal 11: Segmentation fault” running pg_create_logical_replication_slot using pgoutput plugin

[Hayato Kuroda (Fujitsu)]

Dear Shlok, Abrahim,

> Also, I was going to the logs on found:
> > > < 2025-07-08 14:57:08.653 UTC psql postgres postgres 172.18.0.94(53414)
> SELECT 0 2025-07-08 14:57:07 UTC 1096 686d31c3.448 2025-07-08
> 14:57:08.653 UTC > LOG:  Initializing CDC decoder
> 
> This log is not present in Postgres source code. Why is this log appearing 
> here?

I found the output in Citus source code [1]. So, I'm afraid that you may load 
the
shared library provided by Citus when you created the replication slot.

If so, Citus community may be the better place to discuss the bug.
We can help if you can reproduce the bug by the PostgreSQL core codes.

[1]: 
https://github.com/citusdata/citus/blob/5deaf9a61673e10c183b6d4f13593f168e1c2c10/src/backend/distributed/cdc/cdc_decoder.c#L85

Best regards,
Hayato Kuroda
FUJITSU LIMITED