| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Replication protocol doc fix |
| Date: | 2021-07-02 12:44:36 |
| Message-ID: | CA+TgmoZa-3zTU1_2odkwWMvdhEfFyuz_XDzMxgKtW-VyWzQD_g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 2, 2021 at 1:55 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Wed, 2021-06-30 at 12:25 -0400, Robert Haas wrote:
> > I am not sure whether this works or not. Holding off cancel
> > interrupts
> > across possible network I/O seems like a non-starter. We have to be
> > able to kill off connections that have wedged.
>
> I was following a pattern that I saw in CopyGetData() and
> SocketBackend(). If I understand correctly, the idea is to avoid a
> cancel leaving part of a message unread, which would desync the
> protocol.
Right, that seems like a good goal. Thinking about this a little more,
it's only holding off *cancel* interrupts, not *all* interrupts, so
presumably you can still terminate the backend in this state. That's
not so bad, and it's not clear how we could do any better. So I
withdraw my previous complaint about this point.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | kuroda.hayato@fujitsu.com | 2021-07-02 12:53:02 | RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE |
| Previous Message | Laurenz Albe | 2021-07-02 12:40:52 | Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM |