From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical replication and PANIC during shutdown checkpoint in publisher |
Date: | 2017-06-01 22:05:18 |
Message-ID: | 20170601220518.553lfsh4l2wfjxnj@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-05-05 10:50:11 -0400, Peter Eisentraut wrote:
> On 5/5/17 01:26, Michael Paquier wrote:
> > The only code path doing HOT-pruning and generating WAL is
> > heap_page_prune(). Do you think that we need to worry about FPWs as
> > well?
> >
> > Attached is an updated patch, which also forbids the run of any
> > replication commands when the stopping state is reached.
>
> I have committed this without the HOT pruning change. That can be
> considered separately, and I think it could use another round of
> thinking about it.
I'm a unhappy how this is reusing SIGINT for WalSndLastCycleHandler.
Normally INT is used cancel interrupts, and since walsender is now also
working as a normal backend, this overlap is bad. Even for plain
walsender backend this seems bad, because now non-superusers replication
users will terminate replication connections when they do
pg_cancel_backend(). For replication=dbname users it's especially bad
because there can be completely legitimate uses of pg_cancel_backend().
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2017-06-01 22:05:27 | Re: [PATCH] quiet conversion warning in DatumGetFloat4 |
Previous Message | Thomas Munro | 2017-06-01 21:48:31 | Re: strcmp() tie-breaker for identical ICU-collated strings |