Re: StandbyAcquireAccessExclusiveLock doesn't necessarily

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: StandbyAcquireAccessExclusiveLock doesn't necessarily
Date: 2018-09-11 15:15:21
Message-ID: 25443.1536678921@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 11, 2018 at 5:54 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Please explain why you think that would be with no restart.

> Because the startup process will die, and if that happens, IIRC,
> there's no crash-and-restart loop. You're just done.

Unless we think that the startup process will never never ever throw
an error, that might be a behavior that needs discussion in itself.

Obviously an infinite crash-and-restart loop would be bad, but
perhaps the postmaster could have logic that would allow restarting
the startup process some small number of times. I think the hard
part would be in deciding whether a previous restart had succeeded
(ie made progress beyond the prior crash point), so that it should
no longer count against the retry limit.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Zakirov 2018-09-11 15:18:30 Re: [HACKERS] Bug in to_timestamp().
Previous Message Robert Haas 2018-09-11 15:11:29 Re: StandbyAcquireAccessExclusiveLock doesn't necessarily