From: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Forbid the use of invalidated physical slots in streaming replication. |
Date: | 2023-12-06 12:55:29 |
Message-ID: | OS0PR01MB5716A626A4AF5814E057CEE39484A@OS0PR01MB5716.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
When testing streaming replication with a physical slot. I found an unexpected
behavior that the walsender could use an invalidated physical slot for
streaming.
This occurs when the primary slot is invalidated due to reaching the
max_slot_wal_keep_size before initializing the streaming replication
(e.g. before creating the standby). Attach a draft script(test_invalidated_slot.sh)
which can reproduce this.
Once the slot is invalidated, it can no longer protect the WALs and
Rows, as these invalidated slots are not considered in functions like
ReplicationSlotsComputeRequiredXmin().
Besides, the walsender could advance the restart_lsn of an invalidated slot,
then user won't be able to know that if the slot is actually validated or not,
because the 'conflicting' of view pg_replication_slot could be set back to
null.
So, I think it's a bug and one idea to fix is to check the validity of the physical slot in
StartReplication() after acquiring the slot like what the attachment does,
what do you think ?
Best Regards,
Hou Zhijie
Attachment | Content-Type | Size |
---|---|---|
0001-Forbid-the-use-of-invalidated-slot-in-streaming-repl.patch | application/octet-stream | 1.9 KB |
test_invalidated_slot.sh | application/octet-stream | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nazir Bilal Yavuz | 2023-12-06 13:03:57 | Add missing error codes to PANIC/FATAL error reports in xlog.c and relcache.c |
Previous Message | Euler Taveira | 2023-12-06 12:46:09 | Re: Is WAL_DEBUG related code still relevant today? |