On Tue, Aug 25, 2026 at 10:02 AM Quan Zongliang <[email protected]> wrote:
>
>
>
> On 8/22/26 11:12 PM, cca5507 wrote:
> > Fix
> > ===
> >
> > Make sure that the walreceiver creates temp slot only once.
> >
> > Thoughts?
> I think there is nothing wrong with the code of this patch.
I also confirmed that the patch fixes the reported issue. But,
during that test, I found that pg_stat_wal_receiver.slot_name became
NULL after a timeline switch.
I think this can happen because RequestXLogStreaming() clears
walrcv->slotname when primary_slot_name is not configured.
The walreceiver then does not write the existing temporary slot name
back to shared memory because create_temp_slot is already false.
Then, streaming continues to use the temporary slot, but
pg_stat_wal_receiver.slot_name can show NULL.
The reported case could be covered easily by 004_timeline_switch.pl.
For example, we could enable wal_receiver_create_temp_slot without
setting primary_slot_name, switch the upstream to a new timeline,
check that the standby log does not contain "could not create replication
slot ... already exists", and verify that pg_stat_wal_receiver.slot_name
still reports a pg_walreceiver_% slot after the timeline switch.
Thought?
> Furthermore, if a log output is added before walrcv_create_slot(). This
> might make the log more clear.
>
> ereport(LOG, errmsg("creating replication slot \"%s\"", slotname));
I think this would be better discussed separately from the bug fix
as an improvement, since it isn't necessary for fixing the reported
issue.
BTW, as for the proposed logging, I'm not sure it would be an improvement.
If we decide to add it, though, I think DEBUG would be more appropriate
than LOG.
Regards,
--
Fujii Masao
