Thread: initdb --pwfile /dev/zero
Hi, A colleague tried PG 14 internally and it failed during cluster creation, when using the PGDG rpm packages. A bit of debugging shows that the problem is that the packaging script specifies the password using --pwfile /dev/zero. In 14+ this turns out to lead to an endless loop in pg_get_line_append(). The --pwfile /dev/zero was added in https://git.postgresql.org/gitweb/?p=pgrpms.git;a=commitdiff;h=8ca418709ef49a1781f0ea8e6166b139106135ff Devrim, what was the goal? Even in 13 this didn't achieve anything? While I don't think passing /dev/zero is a good idea (it mostly seems to circumvent ""password file \"%s\" is empty", without achieving anything, given the password will be empty). I think we still ought to make pg_get_line() a bit more resilient against '\0'? Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes: > A colleague tried PG 14 internally and it failed during cluster creation, when > using the PGDG rpm packages. A bit of debugging shows that the problem is > that the packaging script specifies the password using --pwfile /dev/zero. > In 14+ this turns out to lead to an endless loop in pg_get_line_append(). Well, that's because that file will source an infinite amount of stuff. > I think we still ought to make pg_get_line() a > bit more resilient against '\0'? I don't think '\0' is the problem. The only fix for this would be to re-introduce some fixed limit on how long a line we'll read, which I'm not too thrilled about. I think this is better classified as user error. regards, tom lane
Andres Freund <andres@anarazel.de> writes: > On 2021-09-17 14:48:42 -0400, Tom Lane wrote: >> I don't think '\0' is the problem. The only fix for this would be to >> re-introduce some fixed limit on how long a line we'll read, which >> I'm not too thrilled about. > Well, '\0' can be classified as the end of a line imo. So I don't think it'd > require a line lenght limit. Meh. Those functions are specified to act like fgets(), which does not think that \0 terminates a line AFAIK. regards, tom lane