Re: Initdb failure

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Initdb failure
Дата
Msg-id 32007.1564515012@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Initdb failure  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Initdb failure  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Allow table AM's to cache stuff in relcache
Следующее
От: Tom Lane
Дата:
Сообщение: Re: idea: log_statement_sample_rate - bottom limit for sampling