Re: BUG #16016: deadlock with startup process, AccessExclusiveLock on pg_statistic's toast table

From: Alexey Ermakov <alexey(dot)ermakov(at)dataegret(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16016: deadlock with startup process, AccessExclusiveLock on pg_statistic's toast table
Date: 2019-11-02 17:30:45
Message-ID: 5DBDBD45.1020406@dataegret.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 11/2/19 21:10, Tom Lane wrote:
> This does not look like a deadlock: the startup process is just biding
> its time until the standby delay timeout elapses, after which it's
> gonna kill the conflicting queries.
>
> It is, perhaps, arguable that it's a damn bad idea to allow
> max_standby_streaming_delay or max_standby_archive_delay to be
> set to "forever".
>
>

I agree, allowing max_standby_streaming_delay be set to -1 is perhaps
not a good idea. there is although case when such setting could be used
now, see "BUG #14044: Queries immediately conflict with recovery when
recovery_min_apply_delay is used". [1]

[1] https://postgr.es/m/20160324204550.2920.87946%40wrigleys.postgresql.org

--
Alexey Ermakov

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-11-02 21:14:20 Re: BUG #16059: Tab-completion of filenames in COPY commands removes required quotes
Previous Message Tom Lane 2019-11-02 16:04:19 Re: ALTER TABLE results in "ERROR: could not open relation with OID 43707388"