Thread: Re: pgsql: Enable Unix-domain sockets support on Windows

Re: pgsql: Enable Unix-domain sockets support on Windows

From
Amit Kapila
Date:
On Sat, Mar 28, 2020 at 7:37 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> Enable Unix-domain sockets support on Windows
>

+
+/*
+ * Windows headers don't define this structure, but you can define it yourself
+ * to use the functionality.
+ */
+struct sockaddr_un
+{
+   unsigned short sun_family;
+   char sun_path[108];
+};

I was going through this feature and reading about Windows support for
it.  I came across a few links which suggest that this structure is
defined in <afunix.h>.  Is there a reason for not using this via
afunix.h?

[1] - https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
[2] - https://gist.github.com/NZSmartie/079d8f894ee94f3035306cb23d49addc

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



Re: pgsql: Enable Unix-domain sockets support on Windows

From
Peter Eisentraut
Date:
On 2020-06-26 14:21, Amit Kapila wrote:
> On Sat, Mar 28, 2020 at 7:37 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>
>> Enable Unix-domain sockets support on Windows
>>
> 
> +
> +/*
> + * Windows headers don't define this structure, but you can define it yourself
> + * to use the functionality.
> + */
> +struct sockaddr_un
> +{
> +   unsigned short sun_family;
> +   char sun_path[108];
> +};
> 
> I was going through this feature and reading about Windows support for
> it.  I came across a few links which suggest that this structure is
> defined in <afunix.h>.  Is there a reason for not using this via
> afunix.h?
> 
> [1] - https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
> [2] - https://gist.github.com/NZSmartie/079d8f894ee94f3035306cb23d49addc

If we did it that way we'd have to write some kind of configuration-time 
check for the MSVC build, since not all Windows versions have that 
header.  Also, not all versions of MinGW have that header (possibly 
none).  So the current implementation is probably the most practical 
compromise.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: pgsql: Enable Unix-domain sockets support on Windows

From
Amit Kapila
Date:
On Sat, Jun 27, 2020 at 3:06 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-06-26 14:21, Amit Kapila wrote:
> > On Sat, Mar 28, 2020 at 7:37 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> >>
> >> Enable Unix-domain sockets support on Windows
> >>
> >
> > +
> > +/*
> > + * Windows headers don't define this structure, but you can define it yourself
> > + * to use the functionality.
> > + */
> > +struct sockaddr_un
> > +{
> > +   unsigned short sun_family;
> > +   char sun_path[108];
> > +};
> >
> > I was going through this feature and reading about Windows support for
> > it.  I came across a few links which suggest that this structure is
> > defined in <afunix.h>.  Is there a reason for not using this via
> > afunix.h?
> >
> > [1] - https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
> > [2] - https://gist.github.com/NZSmartie/079d8f894ee94f3035306cb23d49addc
>
> If we did it that way we'd have to write some kind of configuration-time
> check for the MSVC build, since not all Windows versions have that
> header.  Also, not all versions of MinGW have that header (possibly
> none).  So the current implementation is probably the most practical
> compromise.
>

Fair enough, but what should be the behavior in the Windows versions
(<10) where Unix-domain sockets are not supported?  BTW, in which
format the path needs to be specified for unix_socket_directories?  I
tried with '/c/tmp', 'c:/tmp', 'tmp' but nothing seems to be working,
it gives me errors like: "could not create lock file
"/c/tmp/.s.PGSQL.5432.lock": No such file or directory" on server
start.  I am trying this on Win7 just to check what is the behavior of
this feature on it.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



Re: pgsql: Enable Unix-domain sockets support on Windows

From
Peter Eisentraut
Date:
On 2020-06-27 13:57, Amit Kapila wrote:
> Fair enough, but what should be the behavior in the Windows versions
> (<10) where Unix-domain sockets are not supported?

You get an error about an unsupported address family, similar to trying 
to use IPv6 on a system that doesn't support it.

> BTW, in which
> format the path needs to be specified for unix_socket_directories?  I
> tried with '/c/tmp', 'c:/tmp', 'tmp' but nothing seems to be working,
> it gives me errors like: "could not create lock file
> "/c/tmp/.s.PGSQL.5432.lock": No such file or directory" on server
> start.  I am trying this on Win7 just to check what is the behavior of
> this feature on it.

Hmm, the only thing I remember about this now is that you need to use 
native Windows paths, meaning you can't just use /tmp under MSYS, but it 
needs to be something like C:\something.  But the error you have there 
is not even about the socket file but about the lock file, which is a 
normal file, so if that goes wrong, it might be an unrelated problem.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: pgsql: Enable Unix-domain sockets support on Windows

From
Amit Kapila
Date:
On Sun, Jun 28, 2020 at 2:03 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-06-27 13:57, Amit Kapila wrote:
> > BTW, in which
> > format the path needs to be specified for unix_socket_directories?  I
> > tried with '/c/tmp', 'c:/tmp', 'tmp' but nothing seems to be working,
> > it gives me errors like: "could not create lock file
> > "/c/tmp/.s.PGSQL.5432.lock": No such file or directory" on server
> > start.  I am trying this on Win7 just to check what is the behavior of
> > this feature on it.
>
> Hmm, the only thing I remember about this now is that you need to use
> native Windows paths, meaning you can't just use /tmp under MSYS, but it
> needs to be something like C:\something.
>

I have tried it by giving something like that.
After giving path as unix_socket_directories = 'C:\\akapila', I get
below errors on server start:
2020-06-29 08:19:13.174 IST [4460] LOG:  could not create Unix socket
for address "C:/akapila/.s.PGSQL.5432": An address incompatible with
the request
ed protocol was used.
2020-06-29 08:19:13.205 IST [4460] WARNING:  could not create
Unix-domain socket in directory "C:/akapila"
2020-06-29 08:19:13.205 IST [4460] FATAL:  could not create any
Unix-domain sockets
2020-06-29 08:19:13.221 IST [4460] LOG:  database system is shut down

After giving path as unix_socket_directories = 'C:\akapila', I get
below errors on server start:
2020-06-29 08:24:11.861 IST [4808] FATAL:  could not create lock file
"C:akapila/.s.PGSQL.5432.lock": No such file or directory
2020-06-29 08:24:11.877 IST [4808] LOG:  database system is shut down

>  But the error you have there
> is not even about the socket file but about the lock file, which is a
> normal file, so if that goes wrong, it might be an unrelated problem.
>

Yeah, but as I am trying this on Win7 machine, I was expecting an
error similar to what you were saying: "unsupported address family
...". It seems this error occurred after passing that phase.  I am not
sure what is going on here and maybe it is not important as well
because we don't support this feature on Win7 but probably an
appropriate error message would have been good.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



Re: pgsql: Enable Unix-domain sockets support on Windows

From
Amit Kapila
Date:
On Mon, Jun 29, 2020 at 8:48 PM Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:
>
>
> On 6/28/20 4:33 AM, Peter Eisentraut wrote:
> > On 2020-06-27 13:57, Amit Kapila wrote:
> >> Fair enough, but what should be the behavior in the Windows versions
> >> (<10) where Unix-domain sockets are not supported?
> >
> > You get an error about an unsupported address family, similar to
> > trying to use IPv6 on a system that doesn't support it.
> >
> >> BTW, in which
> >> format the path needs to be specified for unix_socket_directories?  I
> >> tried with '/c/tmp', 'c:/tmp', 'tmp' but nothing seems to be working,
> >> it gives me errors like: "could not create lock file
> >> "/c/tmp/.s.PGSQL.5432.lock": No such file or directory" on server
> >> start.  I am trying this on Win7 just to check what is the behavior of
> >> this feature on it.
> >
> > Hmm, the only thing I remember about this now is that you need to use
> > native Windows paths, meaning you can't just use /tmp under MSYS, but
> > it needs to be something like C:\something.  But the error you have
> > there is not even about the socket file but about the lock file, which
> > is a normal file, so if that goes wrong, it might be an unrelated
> > problem.
> >
>
>
> It needs to be a path from the Windows POV, not an Msys virtualized
> path. So c:/tmp or just /tmp should work, but /c/tmp or similar probably
> will not. The directory needs to exist. I just checked that this is
> working, both in postgresql.conf and on the psql command line.
>

Okay, thanks for the verification.  I was trying to see its behavior
on Win7 or a similar environment where this feature is not supported
to see if we get the appropriate error message.  If by any chance, you
have access to such an environment, then it might be worth trying on
such an environment once.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



Re: pgsql: Enable Unix-domain sockets support on Windows

From
Andrew Dunstan
Date:
On 6/30/20 12:13 AM, Amit Kapila wrote:
> On Mon, Jun 29, 2020 at 8:48 PM Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com> wrote:
>>
>>
>>
>> It needs to be a path from the Windows POV, not an Msys virtualized
>> path. So c:/tmp or just /tmp should work, but /c/tmp or similar probably
>> will not. The directory needs to exist. I just checked that this is
>> working, both in postgresql.conf and on the psql command line.
>>
> Okay, thanks for the verification.  I was trying to see its behavior
> on Win7 or a similar environment where this feature is not supported
> to see if we get the appropriate error message.  If by any chance, you
> have access to such an environment, then it might be worth trying on
> such an environment once.
>


I haven't had a working Windows 7 environment for quite some years.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services