pgsql: Blind attempt at a Cygwin fix

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Blind attempt at a Cygwin fix

According to
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=brolga&amp;dt=2016-01-08%2014%3A51%3A27

brolga now tries to compile win32security.c, which it evidently was not
doing before, but the compile blows up; looks like it is missing #include
calls (which must exist in other places where this code lives ...)

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Tom Lane wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Blind attempt at a Cygwin fix

According to
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=brolga&amp;dt=2016-01-08%2014%3A51%3A27

brolga now tries to compile win32security.c, which it evidently was not
doing before, but the compile blows up; looks like it is missing #include
calls (which must exist in other places where this code lives ...)

Obviously this wasn't the best idea ever. Andrew suggests on IM to
revert this on Cygwin to just do the "isatty" check as originally.

I'm CC'ing Marco Atzeri, who has done Cygwin work lately. Maybe he can
spend some time getting this port fixed.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera wrote:

Tom Lane wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Blind attempt at a Cygwin fix

According to
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=brolga&amp;dt=2016-01-08%2014%3A51%3A27

brolga now tries to compile win32security.c, which it evidently was not
doing before, but the compile blows up; looks like it is missing #include
calls (which must exist in other places where this code lives ...)

Obviously this wasn't the best idea ever. Andrew suggests on IM to
revert this on Cygwin to just do the "isatty" check as originally.

Here's a proposed patch. Thoughts?

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

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Alvaro Herrera wrote:

Obviously this wasn't the best idea ever. Andrew suggests on IM to
revert this on Cygwin to just do the "isatty" check as originally.

Here's a proposed patch. Thoughts?

Ugly, but it will hold the fort until someone can debug the service
code for Cygwin.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 01/08/2016 11:17 AM, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Alvaro Herrera wrote:

Obviously this wasn't the best idea ever. Andrew suggests on IM to
revert this on Cygwin to just do the "isatty" check as originally.

Here's a proposed patch. Thoughts?

Ugly, but it will hold the fort until someone can debug the service
code for Cygwin.

I downloaded the official Cygwin packages into a Cygwin instance and
checked how they do things. As I rather expected, they do not use pg_ctl
at all to install or run as a service. Rather, they use the standard
Cygwin service utility cygrunsrv. This is all managed via a SYSV style
init script.

So if anything I'd be inclined to disable all the service-related code
in pg_ctl for Cygwin, and treat it just as we treat Unix.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Jan 10, 2016 at 2:00 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

I downloaded the official Cygwin packages into a Cygwin instance and checked
how they do things. As I rather expected, they do not use pg_ctl at all to
install or run as a service. Rather, they use the standard Cygwin service
utility cygrunsrv. This is all managed via a SYSV style init script.

Thanks for the investigation!

So if anything I'd be inclined to disable all the service-related code in
pg_ctl for Cygwin, and treat it just as we treat Unix.

We had better do the same for back branches then. Need of a patch?
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Jan 10, 2016 at 8:10 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

On Sun, Jan 10, 2016 at 2:00 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

I downloaded the official Cygwin packages into a Cygwin instance and checked
how they do things. As I rather expected, they do not use pg_ctl at all to
install or run as a service. Rather, they use the standard Cygwin service
utility cygrunsrv. This is all managed via a SYSV style init script.

Thanks for the investigation!

So if anything I'd be inclined to disable all the service-related code in
pg_ctl for Cygwin, and treat it just as we treat Unix.

We had better do the same for back branches then. Need of a patch?

OK, here is a patch to disable all the service-related code in pg_ctl
for cygwin. This time it is not a blind shot and this compiles
correctly. Changing the option layer is fine for me if this is
HEAD-only. For back-branches, I would suggest to do nothing, the
service-related code paths are not going to run anyway, any output
going to stderr.
--
Michael