| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken old server |
| Date: | 2026-07-06 23:46:10 |
| Message-ID: | 8185e4371a3b2f4590ec18246cec473363b35700.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2026-06-29 at 09:57 +0530, Amit Kapila wrote:
> wrconn = walrcv_connect(conninfo, true, true, must_use_password,
> subname, &err);
...
> So, if the connection is not successful then we simply return without
> checking tablesync slots (when slotname is NONE) whereas with FDW
> server connection, the ERROR will be raised from
> construct_subserver_conninfo->ForeignServerConnectionString(). Isn't
> that different from current situation?
It's easier to cause an error in ForeignServerConnectionString(); but
walrcv_connect() can throw errors, too. Also, a network connection is a
side-effect that you may not want to have for whatever reason.
I think it's better to have an escape that prevents any connection to
the publisher, as the documentation says, to deal with these kinds of
edge cases.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2026-07-06 23:52:03 | Re: JSON_VALUE/JSON_TABLE DEFAULT expression ignores RETURNING typmod |
| Previous Message | surya poondla | 2026-07-06 23:43:53 | Re: Use HostsFileName everywhere |