|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Initdb failure|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Robert Haas <robertmhaas(at)gmail(dot)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
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
regards, tom lane
|Next Message||Tom Lane||2019-07-30 19:43:58||Re: idea: log_statement_sample_rate - bottom limit for sampling|
|Previous Message||Heikki Linnakangas||2019-07-30 19:19:34||Re: Allow table AM's to cache stuff in relcache|