On Fri, Oct 31, 2025 at 01:19:50PM +0300, Олег Самойлов wrote:
Let me explain, why PostgreSQL in needed in fixed uid. PostgreSQL don't need it when it run in simple setup, but common practice is to create high availability cluster or other high availability solutions, when servers must exchange files between each other. And common practice is to use NFS for this purpose, why not? And in such case all files must be visible as belonged to user postgres on all servers. So there is two variants.
I have to say that I've never seen this in high-availability setups myself (I've never been more than a casual DBA, but I have 10+ years of experience developing applications on top of PostgreSQL, and most of that has been in environments that required minimizing downtime). https://www.postgresql.org/docs/current/continuous-archiving.html does mention it in passing, but personally I can't say I'd want to have NFS as a critical component of my database cluster's redundancy; its failure modes are just too annoying.
I typically prefer using logical streaming replication rather than WAL-shipping to keep replicas up to date with the primary. WAL-shipping is still useful for continuous backups with point-in-time recovery, and as a fallback. If your primary and replicas are close enough in network terms to make NFS viable, then arranging direct connectivity for streaming replication shouldn't normally be difficult.
But if your organization really wants to deal with keeping replicas up to date using WAL-shipping over NFS, I won't stand in your way!
1. NFS v.4 can resolve a text user name. But do it not by NFS server itself, by the external daemon "idmap", if I understand correctly, it can be abscent. v.3 don't work with text usernames at all, only with uid. Our sysadmins insists that our China NFS storage don't support text usernames. I don't believe them. Also they insist that rise and support idmap only for one user postgres is overengineering and just setup the same uid on all servers in cluster is much more simple and reliable solution. I agree with them here. 2. Okey, fixed uid. They choose fixed uid=418. I think this is incorrect and violate Debian Policy, fixed uid must be from the range 63000-64999. Or, from reserved range, for instance, 65432. But they insist, that fixed uid=418 is much more reliable solution if considering potential conflicts. So I just want to do things right. If you will reject I will not have a choice other then permit to violate Debian Policy. It just works.
It's true that this ID is within a range that the Debian Policy Manual specifies as being for dynamically-allocated system users and groups. However, Debian policy describes policy requirements for the Debian distribution and for creating Debian packages. A site can't violate Debian policy by the way in which it deploys Debian; that's just a category error.
You should also note that the Debian Policy Manual explicitly says "many sites allocate users and/or local system groups starting at 100", and anticipates that in its design.
When doing site-local allocation like this, you need to think the other way round from the text in the Debian Policy Manual: your consideration isn't "what may a package do to avoid conflicting with other packages and local policies", but rather "what can we do that a package won't conflict with by accident"? In practice, this means that it's important to use one of the dynamically-allocated ranges. Any of the ranges 100-999, 1000-59999, or (if your system can tolerate 32-bit user IDs) 65536-4294967293 is fine. 63000-64999 would not be fine; that's within a range (60000-64999) that's statically allocated by Debian, so your sysadmins are correct to say that they should not use it. I suppose 65432 would probably be OK, but I don't see any particular reason to prefer it over 418.
If your site wants to allocate a fixed ID for the postgres user, then I see no problem with that provided that it's in a dynamically-allocated range and is reliably created on each system before the PostgreSQL packages are installed. (Or, technically, before any packages outside the base system are installed; but for an ID as high as 418 this shouldn't be a problem in practice.) Debian packages doing dynamic ID allocation will notice that the ID already exists, and no Debian package should be hardcoding ID 418, so there's no conflict here.
Cheers, -- Colin Watson (he/him) [[email protected]] _______________________________________________ Pkg-shadow-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel
