From: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit kapila <amit(dot)kapila(at)huawei(dot)com>, 'Robert Haas' <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Date: | 2013-01-18 21:07:40 |
Message-ID: | 50F9B99C.5040206@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2013-01-18 21:48 keltezéssel, Boszormenyi Zoltan írta:
> 2013-01-18 21:32 keltezéssel, Tom Lane írta:
>> Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
>>> 2013-01-18 11:05 keltezéssel, Amit kapila írta:
>>>> On using mktemp, linux compilation gives below warning
>>>> warning: the use of `mktemp' is dangerous, better use `mkstemp'
>>>>
>>>> So I planned to use mkstemp.
>>> Good.
>> On my HPUX box, the man page disapproves of both, calling them obsolete
>> (and this man page is old enough to vote, I believe...)
Then we have to at least consider what this old {p|s}age says... ;-)
>>
>> Everywhere else that we need to do something like this, we just use our
>> own PID to disambiguate, ie
>> sprintf(tempfilename, "/path/to/file.%d", (int) getpid());
>> There is no need to deviate from that pattern or introduce portability
>> issues, since we can reasonably assume that no non-Postgres programs are
>> creating files in this directory.
>
> Thanks for the enlightenment, I will post a new version soon.
Here it is.
Best regards,
Zoltán Böszörményi
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/
Attachment | Content-Type | Size |
---|---|---|
set_persistent_v7.patch.gz | application/x-tar | 11.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-01-18 21:13:18 | Re: foreign key locks |
Previous Message | Tom Lane | 2013-01-18 21:01:18 | Re: foreign key locks |