From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | dg(at)informix(dot)com (David Gould) |
Cc: | hackers(at)postgreSQL(dot)org (PostgreSQL-development) |
Subject: | Re: [HACKERS] postmaster locking issues. |
Date: | 1998-10-12 16:06:46 |
Message-ID: | 199810121606.MAA12310@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I strongly disagree. If we wish postgresql to please people, we do not want
> to start out by annoying them with the install. Specifically, some of us
> (I happen to be one), feel that the FHS is important and that packages
> should follow it.
>
> Also, /tmp is a security risk. Why make it harder for someone trying to
> use postgresql, say for a real application involving money or confidential
> information or something, to run a tightly nailed down system.
>
> This item should follow platform convention by default (ie, FHS on Linux
> and other "progressive" systems) but be configurable at install time.
OK, I agree, we should allow locks to be placed wherever people want
them, and the periodic cleaning of /tmp is a good argument.
Perhaps, rather than using OS-specific stuff, we can just test from
configure for various directories that are writeable, and choose the
best one. That seems nicer to me, and fewer configuration headaches.
I assume this would apply to lock and socket files? If so, each client
for unix-domain sockets would have to know about the location chosen at
configure time. That sounds messy. I am adding this item to the
TODO/Open Items list.
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew N. Dodd | 1998-10-12 16:18:13 | Re: [HACKERS] dynamic libraries |
Previous Message | Bruce Momjian | 1998-10-12 16:01:50 | Re: [HACKERS] dynamic libraries |