Slony1 PostgreSQL Replication

Author

Some win32 bits

Andreas Pflug

2005-03-30, 7:35 pm

I got some minutes to test CVS HEAD under win32 mingw, and the result is
unfortunately a regression from what 1.05 gives.

../configure will fail because it checks for sigaction, which is used in
slon.c for SIGHUP handling. win32 doesn't provide sigaction(), only
signal() which is probably sufficient for win32 anyway. Maybe configure
can implement a fallback to signal() if sigaction() isn't present?

After this configure error, I don't get Makefiles so I couldn't execute
more tests. Still, I have some information to share.

In schedule.c and slon.c, pthread_self() result is compared with a
pthread_t variable, which isn't the recommended way to check for
equality; instead pthread_equal should be used. Under win32 this fails,
because pthread_t isn't a simple value. The attached file provides a
patch for this, and should make this portable for all pthread_t platforms.

The backend/xxid makefiles I provided some time ago (now located in the
Win32 subdirectory) were meant as portable replacement for the current
versions for *all* platforms, not only mingw. They don't need
../configure to be created (just as typical pgsql/contrib makefiles).
They work successfully on Linux, and I would expect them to do so on any
pgsql supported platform.

Regards,
Andreas

Christopher Browne

2005-03-30, 7:35 pm

Andreas Pflug wrote:

> I got some minutes to test CVS HEAD under win32 mingw, and the result
> is unfortunately a regression from what 1.05 gives.
>
> ./configure will fail because it checks for sigaction, which is used
> in slon.c for SIGHUP handling. win32 doesn't provide sigaction(), only
> signal() which is probably sufficient for win32 anyway. Maybe
> configure can implement a fallback to signal() if sigaction() isn't
> present?
>
Maybe; I have evaded knowledge of configure thus far, deferring this to
Darcy. Darcy, does this seem sensible to you?

There is only one reference to sigaction(), that in slon.c, so I would
hope this wouldn't be too difficult to deal with...

> After this configure error, I don't get Makefiles so I couldn't
> execute more tests. Still, I have some information to share.
>
> In schedule.c and slon.c, pthread_self() result is compared with a
> pthread_t variable, which isn't the recommended way to check for
> equality; instead pthread_equal should be used. Under win32 this
> fails, because pthread_t isn't a simple value. The attached file
> provides a patch for this, and should make this portable for all
> pthread_t platforms.

This change seems good; I'm trying it out on AIX as well, to get some
further testing in.

> The backend/xxid makefiles I provided some time ago (now located in
> the Win32 subdirectory) were meant as portable replacement for the
> current versions for *all* platforms, not only mingw. They don't need
> ./configure to be created (just as typical pgsql/contrib makefiles).
> They work successfully on Linux, and I would expect them to do so on
> any pgsql supported platform.

These don't seem to replace the existing makefiles; are they supposed to
just replace certain parts of the existing ones?

pgadmin-fm2TWiLXNCrrZyGJdb+2erNAH6kLmebB@public.gm

2005-03-30, 7:35 pm

>
> These don't seem to replace the existing makefiles; are they supposed t=
o
> just replace certain parts of the existing ones?

No, it should replace all parts, what do you miss? The contrib master
makefile should do all the jobs. I checked make, make install, make clean=
..

Regards,
Andreas

Jan Wieck

2005-03-30, 7:35 pm

On 3/21/2005 12:40 PM, pgadmin- fm2TWiLXNCrrZyGJdb+2
erNAH6kLmebB@public.gmane.org wrote:

>
> No, it should replace all parts, what do you miss? The contrib master
> makefile should do all the jobs. I checked make, make install, make clean.

What "contrib master makefile" ?

Jan

--
#===================
====================
====================
===========#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#===================
====================
=========== JanWieck- bwPqjjyvM7QAvxtiuMwx
3w@public.gmane.org #

Darcy Buskermolen

2005-03-30, 7:35 pm

On Monday 21 March 2005 08:27, Christopher Browne wrote:
> Andreas Pflug wrote:
>
> Maybe; I have evaded knowledge of configure thus far, deferring this to
> Darcy. Darcy, does this seem sensible to you?

Yes this seams senceable, however I have no win32 box to test this on,
Andreas, if you are able to provide a patch, or other details on signal()
under win32 that would be helpful.

>
> There is only one reference to sigaction(), that in slon.c, so I would
> hope this wouldn't be too difficult to deal with...
>
>
> This change seems good; I'm trying it out on AIX as well, to get some
> further testing in.
>
>
> These don't seem to replace the existing makefiles; are they supposed to
> just replace certain parts of the existing ones?
> ____________________
____________________
_______
> Slony1-general mailing list
> Slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
> http://gborg.postgresql.org/mailman.../slony1-general

Andreas Pflug

2005-03-30, 7:35 pm

Darcy Buskermolen wrote:
>
> Yes this seams senceable, however I have no win32 box to test this on,
> Andreas, if you are able to provide a patch, or other details on signal()
> under win32 that would be helpful.

I could, if configure and link problems are solved; I don't have the
time to dive into these topics (other people do this for me in pgadmin :-).
I'd probably be able to provide patches for signal, alarm and further
yet unknown issues for win32.

Regards,
Andreas

Andreas Pflug

2005-03-30, 7:35 pm

Jan Wieck wrote:
> On 3/21/2005 12:40 PM, pgadmin- fm2TWiLXNCrrZyGJdb+2
erNAH6kLmebB@public.gmane.org wrote:
>
>
>
> What "contrib master makefile" ?

contrib/contrib-global.mk and src/Makefile.global

Regards,
Andreas

Jan Wieck

2005-03-30, 7:35 pm

On 3/21/2005 6:30 PM, Andreas Pflug wrote:
> Jan Wieck wrote:
>
> contrib/contrib-global.mk and src/Makefile.global
>
> Regards,
> Andreas

I must have missed when Slony became part of the contrib directory. Or
do you mean that the PG contrib directory must be available to build
Slony for Win32?

Jan

--
#===================
====================
====================
===========#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#===================
====================
=========== JanWieck- bwPqjjyvM7QAvxtiuMwx
3w@public.gmane.org #

Andreas Pflug

2005-03-30, 7:35 pm

Jan Wieck wrote:
>
> I must have missed when Slony became part of the contrib directory. Or
> do you mean that the PG contrib directory must be available to build
> Slony for Win32?

Slony-I is certainly *not* part of contrib, but it can compile fine
using that infrastructure; that's what the makefiles I provided do. The
only reference into the contrib subdir is contrib/contrib-global.mk,
which could be bypassed too.

Regards,
Andreas

Darcy Buskermolen

2005-03-30, 7:35 pm

On Wednesday 23 March 2005 01:33, Andreas Pflug wrote:
> Jan Wieck wrote:
>
> Slony-I is certainly *not* part of contrib, but it can compile fine
> using that infrastructure; that's what the makefiles I provided do. The
> only reference into the contrib subdir is contrib/contrib-global.mk,
> which could be bypassed too.

Andreas the makefiles you provided are for the -STABLE tree only best I can
tell. I've made chages in -HEAD to address your signal()/sigaction() request,
but I lack a win32 development environment to test on. If you could check
this under cvs -HEAD and report your findings.

>
> Regards,
> Andreas
> ____________________
____________________
_______
> Slony1-general mailing list
> Slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
> http://gborg.postgresql.org/mailman.../slony1-general

--
Darcy Buskermolen
Wavefire Technologies Corp.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759

Andreas Pflug

2005-03-30, 7:35 pm

Darcy Buskermolen wrote:

>I've made chages in -HEAD to address your signal()/sigaction() request,
>but I lack a win32 development environment to test on. If you could check
>this under cvs -HEAD and report your findings.
>
>

See attached some fixes to the current CVS HEAD.
Apparently, you took CYGWIN as macro name to distinguish the signal code
paths. I'm not using CYGWIN, but MINGW, so the macro WIN32 is predefined
and can be used. After these changes, xxid and slony1_funcs compile ok.

slon.c won't compile until
#include "libpq/pqsignal.h"
is included because sighandler isn't defined.

After that, linkage fails from alarm, fork, pipe, wait, getppid symbols.

alarm isn't surprising, it failed from that in the 1.0.5 branch too.
This has to be implemented differently in win32, which wouldn't be too
complicated.

Unfortunately, the latest invention of the fork code is much more
incompatible. Not only that fork() isn't available, the communication
stuff is implemented in a unix only way (pipes are files in win32, not
sockets).

Actually, all stuff that handles with processes and signals should be
implemented for win32 in a completely different way. Currently, this is
not easily done because the config/worker code is interwoven with
process/signal code. I'd propose to separate these sections, so a win32
specific implementation can be added later (V1.1.1?).

FYI:
In win32, I wouldn't implement a watchdog at all. The slon process would
be under control of the win32 service manager, which handles this. Same
for SIGHUP and SIGALRM.

Regards,
Andreas

Sponsored Links