Re: (docs): add missing info about ShareLocks
Ah thanks for pointing this out, I've moved it to the xact-locking page instead document-ShareLock-when-using-deferred-unique.patch Description: Binary data > Den 22. nov. 2025 kl. 13.07 skrev Laurenz Albe : > > On Sat, 2025-11-22 at 09:07 +0100, Alpha Shuro wrote: >> I had a production incident a few weeks ago while using deferred indexes, >> where >> the Postgres docs lead me down the wrong path of investigation due to >> missing details. >> Specifically, the docs implied that a `ShareLock` was only acquired when >> creating >> indexes, but only after looking at the code did I learn that this lock is >> also >> acquired when transactions are waiting for other transactions to complete. >> I think this would be helpful to someone who might find themselves on the >> same path >> in the future, and as I understand it this mailing list is the way to submit >> patches >> to the docs? > > No, that is wrong. This section is about table locks, and a lock on a > transaction ID > should, if anywhere, be documented elsewhere. Actually, there is already > something > about transaction ID locks in > https://www.postgresql.org/docs/current/xact-locking.html > > Perhaps you could improve that short documentation? > > Yours, > Laurenz Albe > > PS: There are also SHARE locks on rows.
Re: (docs): add missing info about ShareLocks
On Thu, 2025-11-27 at 12:33 +0100, Alpha Shuro wrote: > Ah thanks for pointing this out, I've moved it to the xact-locking page > instead I think that is too specific. You can see a session waiting for a SHARE lock on a transaction whenever it is waiting for a row lock, since row locks are not permanently stored in the shared memory lock table. Rather than adding a paragraph about the specific incident that happened to you, you should describe the general mechanism. Some reading material: https://www.cybertec-postgresql.com/en/row-locks-in-postgresql/ Yours, Laurenz Albe
Add Restart=on-failure To Example Systemd File
Hi, Currently the systemd file in the documentation does not specify a restart policy. By default systemd will not attempt to restart a service that has failed (killed by OOM-killer for example) [0]. The systemd docs recommends "Setting this to on-failure is the recommended choice for long-running services, in order to increase reliability by attempting automatic recovery from errors." I think that Postgres is probably a good example of a "long-running service". Pgbouncer for example also uses "Restart=on-failure" [1]. Wondering also if there are any factors that I am not considering here. Perhaps if this is the case that this is not good blanket guidance, it would be worth it to provide some guidance around Restart systemd parameter in the postgres docs. [0] https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html [1] https://github.com/pgbouncer/pgbouncer/blob/master/etc/pgbouncer.service Thanks, Andrew Jackson From 9a0885ecfccbe69d6704d0c0d69347ccc23cdddb Mon Sep 17 00:00:00 2001 From: Andrew Jackson Date: Thu, 27 Nov 2025 10:45:52 -0600 Subject: [PATCH] doc: Add restart on failure to example systemd file The documentation previously had a systemd unit file that would not attempt to recover from process failures such as OOM's, segfaults, etc. This commit adds `Restart=on-failure` which tells systemd to attempt to restart the process after failure. This is the recommended configuration per the systemd documentation: "Setting this to on-failure is the recommended choice for long-running services". Most postgres users will simply copy/paste what the postgres docs recommend and will probably do their own research and change the service file to restart on failure, so might as well set this as the default in the postgres docs. --- doc/src/sgml/runtime.sgml | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 0c60bafac63..dbb3b2ef53f 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -491,6 +491,7 @@ ExecReload=/bin/kill -HUP $MAINPID KillMode=mixed KillSignal=SIGINT TimeoutSec=infinity +Restart=on-failure [Install] WantedBy=multi-user.target -- 2.49.0
