Hello,

/var/log/postgresql has the sticky bit set, starting I think with
bullseye:

  # ls -lad /var/log/postgresql/
  drwxrwxr-t 2 root postgres 4096 Apr 27 23:11 /var/log/postgresql/

This causes some pain with file-based backups.  In particular, `rsync -a
--inplace` is affected.  Since the dir is sticky, rsync makes the backup
dir sticky.  But since the files are not owned by root on the backup
target, even root will be prevented from overwriting them.  A more
careful explanation can be found at [1].

Is the sticky bit really necessary here?  I've worked around this with
dpkg-statoverride, but I don't understand why this dir is +t anyhow.

Thanks,
Ross

[1] https://superuser.com/questions/1708317/rsync-permissions-errors-at-destination-even-though-root-possibly-due-to-sticky

After upgrading to bookworm, I was reminded of this bug when
/var/log/postgresql's sticky bit re-appeared.  So I dug a bit more.

postgresql-common's postinst unconditionally changes owners and modes on
/var/log/postgresql.  The patch below makes it respect dpkg-statoverride.

Thanks,
Ross

diff --git a/debian/postgresql-common.postinst b/debian/postgresql-common.postinst
old mode 100644
new mode 100755
index 545146a..638c8b8
--- a/debian/postgresql-common.postinst
+++ b/debian/postgresql-common.postinst
@@ -65,8 +65,10 @@ Please fix this and reinstall this package." >&2

     # nicer log directory permissions
     mkdir -p /var/log/postgresql
-    chmod 1775 /var/log/postgresql
-    chown root:postgres /var/log/postgresql
+    if ! dpkg-statoverride --list /var/log/postgresl > /dev/null; then
+        chmod "$LOG_MODE" /var/log/postgresql
+        chown root:postgres /var/log/postgresql
+    fi

     # create socket directory
     [ -d /var/run/postgresql ] || \