Postgres Pro
Downloads
Home   >   mailing lists

Re: StandbyAcquireAccessExclusiveLock doesn't necessarily - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: StandbyAcquireAccessExclusiveLock doesn't necessarily
Date
Msg-id CANP8+jLttaWVs+Dn+inyrqB4attSKaywavFEkOCO5eQN91DT8A@mail.gmail.com
Whole thread Raw
In response to Re: StandbyAcquireAccessExclusiveLock doesn't necessarily  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: StandbyAcquireAccessExclusiveLock doesn't necessarily  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: StandbyAcquireAccessExclusiveLock doesn't necessarily  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Tree view
On 10 September 2018 at 19:16, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Sep 7, 2018 at 6:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So my inclination is to remove the reportMemoryError = false parameter,
> and just let an error happen in the unlikely situation that we hit OOM
> for the lock table.

Wouldn't that take down the entire cluster with no restart?

Please explain why you think that would be with no restart. 

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: Query is over 2x slower with jit=on
Next
From: Aleksandr Parfenov
Date:
Subject: Re: Flexible configuration for full-text search