Replace remaining getpwuid() calls with getpwuid_r()?

From: Steve Lau <stevelauc(at)outlook(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Replace remaining getpwuid() calls with getpwuid_r()?
Date: 2025-07-10 05:10:26
Message-ID: 24EDD099-AAD5-4173-8AB0-CC00E44802B9@outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers, when reading the source code, I noticed that Postgres is still using getpwuid(), which is not thread-safe since it returns a pointer to the static memory that can be overwritten by concurrent calls. Then I searched "getpwuid" in the mailing list[1], and there was a committed patch that refactored one such usage. So maybe we can clean up the remaining getpwuid() calls?

Then I realized that Postgres does not use threads but processes, so technically IMHO getpwuid() is safe to Postgres? But that patch mentioned that[2]:

> This is AFAICT the only call in the getpw*() family that needs to be dealt with. (There is also a getgrnam() call, but that is called very > early in the postmaster, before multiprocessing, so we can leave that as is.)

Which indeed confuses me. So my questions are:

1. Will the thread-safety issue of getpwuid() affect Postgres? Why?
2. If the answer to the first question is yes, should we clean up the remaining getpwuid() calls or not?

[1]: https://www.postgresql.org/search/?m=1&ln=pgsql-hackers&q=getpwuid
[2]: https://www.postgresql.org/message-id/5f293da9-ceb4-4937-8e52-82c25db8e4d3@eisentraut.org

Best regards,
Steve.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo Nagata 2025-07-10 05:11:29 Re: Extend ALTER DEFAULT PRIVILEGES for large objects
Previous Message Dilip Kumar 2025-07-10 05:04:28 Re: CHECKPOINT unlogged data