On Thu, Oct 24, 2013 at 1:13 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
Would this make sense as a configure-time check, rather than initdb, to
try blocking SIGSYS and checking f
On 2013-10-24 13:13:23 -0400, Tom Lane wrote:
> Stephen Frost writes:
> The above patch ignores SIGSYS throughout initdb. We could narrow the
> possible side-effects by only disabling SIGSYS around the shm_open call,
> but I'm not sure there's any value in that. It seems likely to me that
> the
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
>>> Would this make sense as a configure-time check, rather than initdb, to
>>> try blocking SIGSYS and checking for an ENOSYS from shm_open()? Seems
>>> preferrable to
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
> > Would this make sense as a configure-time check, rather than initdb, to
> > try blocking SIGSYS and checking for an ENOSYS from shm_open()? Seems
> > preferrable to do that in a configure che
On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I agree with Robert that it's odd and obnoxious that the call doesn't just
>> return with errno = ENOSYS. However, looking in the archives turns up
>> this interesting historical info:
>> http://www
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I agree with Robert that it's odd and obnoxious that the call doesn't just
> return with errno = ENOSYS. However, looking in the archives turns up
> this interesting historical info:
> http://www.postgresql.org/message-id/25564.962066...@sss.pgh.pa.us
Wow,
Stephen Frost writes:
> I'm going to guess this idea is a non-starter, but any hope there's some
> other system call which would tell us we're on a platform where
> shm_open() will hit us with SIGSYS? What happens when shm_unlink() is
> called on this platform? Or mmap()?
For context's sake, th
* Robert Haas (robertmh...@gmail.com) wrote:
> I don't think a configure-time test is a good idea because there's no
> guarantee that the configure-time machine and the run-time machine
> have the same behavior. But having initdb fork a child process to run
> the test seems like a reasonable way f
Robert Haas writes:
> On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane wrote:
>> selecting dynamic shared memory implementation ... Bad system call(coredump)
> Well, geez. That's obnoxious.
I quite agree :-(. If it were just this old HPUX version, maybe we could
write it off as something we don't c
On Tue, Oct 22, 2013 at 10:07 PM, Tom Lane wrote:
> initdb.c quoth:
>
> * ... but the fact that a platform has shm_open
> * doesn't guarantee that that call will succeed when attempted.
>
> Indeed:
>
> $ initdb
> The files belonging to this database system will be owned by user "postgres".
> Thi
initdb.c quoth:
* ... but the fact that a platform has shm_open
* doesn't guarantee that that call will succeed when attempted.
Indeed:
$ initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will
11 matches
Mail list logo
