Hi also, On Sat, Mar 08, 2014 at 20:08:03 +0100, Christoph Berg wrote: [...] > > > /tmp is possibly still better than the data directory. > > > > Yes, indeed. Especially on machines with a reasonable amount of > > memory it is advisable to put /tmp/ on a tmpfs, and I guess many > > people do that (reduces battery usage, HD > > wakeups/wearout/fragmentation, and on servers to increase > > performance). > > I don't think we should put stuff into /tmp by default even if mkdir() > is safe.
As I understand it, we put the socket already there for non-postgres / non-admin-created clusters? > > > # Clusters created by normal users will need to change this > > > # option in postgresql.conf, because the directory will not > > > # be setup properly for them. > > > > No, I don't believe in configuring broken defaults. Then let's rather > > only configure this for owners which can actually write > > /var/run/postgres/, so that the status quo is kept for clusters of > > other owners. > > Right. I wouldn't want to put too much magic in createcluster.conf, > but "don't set this var if the dir isn't writable" is a good plan. We have three cases: 1. admin creates postgres-cluster --> Everything fine, whatever we do. 2. admin creates other-owned-cluster --> Also fine, because pg_ctlcluster precreates the directory. 3. non-admin creates cluster --> Problems, all around. >From a previous mail I understood, that (3) is not working properly currently anyway. Is this correct? If this is true, my patch makes the situation in (3) only a little bit worse than before. And then I'd suggest to apply my patch now and take a note of things being a little bit worse than before (but easy to fix for indivifual users). And then put brain power into fixing things for real. If this is not true, and/or we do not want to make things worse, there are two main options around: a) Use /tmp in this case (socket dir). This seems a little bit better than using the data directory, but has its own issues. b) Use the data dir (not setting the option at all). This is the works-always-default. For implementing (b), pg_createcluster could actually try the same install-d as pg_ctlcluster and if it fails, put a warning and drop the option from the newly created postgresql.conf. As my perl skills have degraded close to zero, I would hope you guys could do this, if it's wanted. Cheers Christian -- www.mad-protection.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org