| From: | Quan Zongliang <quanzongliang(at)yeah(dot)net> |
|---|---|
| To: | cca5507 <cca5507(at)qq(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Walreceiver create temp slot more than once when timeline switch |
| Date: | 2026-08-26 03:10:02 |
| Message-ID: | 38dbe816-9bdd-4199-bb6e-d189a7155dc6@yeah.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 8/25/26 9:43 PM, cca5507 wrote:
>> 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.
>
> Good catch, fixed.
>
v2 can show the correct slot_name.
Perform TAP tests using the original and v1 versions of walreceiver.c
along with 004_timeline_switch.pl. Both issues (creation error and NULL
slot_name) were reported correctly.
--
Quan Zongliang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-08-26 03:24:55 | Re: Row pattern recognition |
| Previous Message | William Bernbaum | 2026-08-26 03:02:18 | Plan a filtering inner join as a semijoin |