On Wed, Nov 4, 2020 at 9:45 AM Laurenz Albe <laurenz.albe@xxxxxxxxxxx> 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 reporting in 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/
