| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'Fujii Masao' <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: logical apply worker's lock waits in subscriber can stall checkpointer in publisher |
| Date: | 2026-02-05 04:19:48 |
| Message-ID: | OS9PR01MB12149CD6D9C1C83AD7395F636F599A@OS9PR01MB12149.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dear Fujii-san,
> > One concern for me is that the WALs might be more likely to be missed for
> > streaming replication case. What if the case walreceiver is bit busy thus send
> > buffer becomes full for a while?
> > Are there no issues because switchover after the walsender exits with FATAL is
> > not recommended?
>
> I don't think this is problematic, since PostgreSQL has never guaranteed that
> WAL data already in the send buffer will actually be delivered to the client
> at walsender FATAL exit case. But do you see this differently?
Then it might be OK. I did not recognize the policy that it's not guaranteed at FATAL.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-02-05 04:37:19 | Re: pg_upgrade: fix memory leak in SLRU I/O code |
| Previous Message | Japin Li | 2026-02-05 04:06:45 | Re: Make wal_receiver_timeout configurable per subscription |