On Sun, Oct 19, 2008 at 10:15:22PM -0400, Tom Lane wrote:
> Eric Haszlakiewicz <erh@swapsimple.com> writes:
> > On Sat, Oct 18, 2008 at 12:48:13PM -0400, Tom Lane wrote:
> >> That's already documented not to work, and not for any hidden
> >> implementation reason: you'd have a conflict on the Unix-domain socket
> >> name.
>
> > er.. but I didn't get any kind of error about a conflict on a unix domain
> > socket, I got an error about shmget. I don't even think it's possible
> > to have a conflict like that since the two servers were running in
> > different chroot directories.
>
> Well, different chroot would do it, but you didn't mention that ;-)
er.. why does a chroot matter? I don't see any mention of chroot in
the docs.
> Anyway, I still think that the proposed documentation patches are wrong,
> because the code ought to work as long as you don't have a direct
> conflict on TCP or Unix sockets. It's true that the port number is used
I don't understand how the configuration I have contains a conflict. Because
of the chroot, the unix socket can't conflict, and because I set different
IP addresses the tcp socket shouldn't conflict either.
> as a seed for picking shmem keys, but it should try the next key if it
> hits an already-in-use shmem segment. Can you poke at it a bit more
> closely and see what's happening? What platform is this, anyway?
I'm running on NetBSD 4.
Well, it seems that something doesn't work right with the "try the next key"
code when the userid are the same. I'm not really sure what I should try
here.
eric