Re: Initdb failure - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Initdb failure
Date
Msg-id 32007.1564515012@sss.pgh.pa.us
Whole thread Raw
In response to Re: Initdb failure  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Initdb failure  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Agreed, but I think we should just do nothing.  To actually fix this
> in general, we'd have to get rid of every instance of MAXPGPATH in the
> source tree:
> [rhaas pgsql]$ git grep MAXPGPATH | wc -l
>      611

I don't think it'd really be necessary to go that far.  One of the
reasons we chdir to the data directory at postmaster start is so that
(pretty nearly) all filenames that backends deal with are relative
pathnames of very predictable, short lengths.  So a lot of those
MAXPGPATH uses are probably perfectly safe, indeed likely overkill.

However, identifying which ones are not safe would still take looking
at every use case, so I agree there'd be a lot of work here.

Would there be any value in teaching initdb to do something similar,
ie chdir to the parent of the target datadir location?  Then the set
of places in initdb that have to deal with long pathnames would be
pretty well constrained.

On the whole though, I don't have a problem with the "do nothing"
answer.  There's no security risk here, and no issue that seems
likely to arise in actual use cases rather than try-to-break-it
test scripts.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Allow table AM's to cache stuff in relcache
Next
From: Tom Lane
Date:
Subject: Re: idea: log_statement_sample_rate - bottom limit for sampling