| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, vignesh C <vignesh21(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Initdb failure |
| Date: | 2019-07-30 18:51:52 |
| Message-ID: | CA+TgmoaDdcDA9+gWAan4SVrB3xtN-yWYaUi3jCRis=dfywU0xA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jul 27, 2019 at 2:22 AM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> I think if you want to make this more robust, get rid of the fixed-size
> array, use dynamic allocation with PQExpBuffer, and let the operating
> system complain if it doesn't like the directory name length.
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
If somebody feels motivated to spend that amount of effort improving
this, I will stand back and cheer from the sidelines, but that's gonna
be a LOT of work for a problem that, as Tom says, is probably not
really affecting very many people.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2019-07-30 18:54:55 | Redacting information from logs |
| Previous Message | Melanie Plageman | 2019-07-30 18:46:59 | Re: Avoiding hash join batch explosions with extreme skew and weird stats |