Re: Initdb failure

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
Date: 2019-07-30 19:30:12
Message-ID: 32007.1564515012@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
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