On Wed, Nov 4, 2020 at 9:45 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Tue, 2020-11-03 at 09:42 -0600, Doug Whitfield wrote:
> > Unclear to me if this is a systemd bug or a Postgresql 12 bug, so I figured I would get some thoughts here before
reportingin detail.
> >
> > It is pretty simple to reproduce. If you start your standby server with incorrect username or password
> > using ’systemctl start postgresql-12’ then systemctl just “hangs”. The replication issues get logged,
> > and it isn’t hard to fix, but it doesn’t seem like the appropriate outcome. If you make a syntax error,
> > the systemctl knows that you failed. Of course, this is better than having a normal exit status and
> > moving on with life only to find out your replication isn’t working, but it doesn’t seem right.
> >
> > To be clear, I already fixed the issue. I am just wondering if people think this is a systemd bug
> > or a PostgresQL bug or it is just a garbage in, garbage out sort of situation not worth filing anywhere.
>
> That must be the "Type=notify" from the service file.
>
> PostgreSQL notifies systemd as soon as it has started up, which didn't happen in your case.
>
> The idea is that later services that depend on PostgreSQL can rely on it being available.
> I think that is a good thing to have.
> I am no systemd expert, but as far as I know services are started in parallel, so it
> shouldn't block your boot process for other services that don't depend on PostgreSQL.
>
I believe in a hot standby system, we will send the notification to
systemd once we have reached a consistent state and are "ready for
read only connections". If the system is not in that state, and cannot
connect to the primary, then it seems like indeed it gets stuck there
"forever".
I think one can argue whether that's good or bad :)
The PostgreSQL documentation at
https://www.postgresql.org/docs/13/server-start.html talks about this
behaviour, but only notes that crash recovery might be a reason to hit
this timeout. Maybe it needs to also mention replication (and probably
archive recovery)?
> The best place to discuss this would be the "pgsql-pkg-yum" list.
I don't think this is a packaging issue, all the RPMs did was enable
the functionality that's in core postgresql.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/