Re: pg_upgrade bugs - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pg_upgrade bugs
Date
Msg-id 1346642709-sup-3843@alvh.no-ip.org
Whole thread Raw
In response to pg_upgrade bugs  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_upgrade bugs
List pgsql-hackers
Excerpts from Andrew Dunstan's message of dom sep 02 22:11:42 -0300 2012:
>
> I have been wrestling for a couple of days trying to get pg_upgrade
> testing working on Windows, with a view to having it tested on the
> buildfarm. The test script has its own issues, which I'll deal with
> separately, but there are two issues in pg_upgrade's exec.c that make me
> suspect that if pg_upgrade has ever worked at all on Windows it is a
> matter of sheer luck. The attached patch fixes these. The first issue is
> a plain miscall to stlcpy(), where the length argument is wrong. The
> second is where exec_prog tries to open a log file after the system call
> returns. This will fail if the command was a 'pg_ctl start', as the
> running postmaster will have the log file open, so I have simply
> #ifdef'd it out for the Windows case, as the code does nothing except
> add a couple of line feeds to the log, missing which won't affect
> anything much.

The first issue was clearly introduced by me in
088c065ce8e405fafbfa966937184ece9defcf20.  The other one is probably
also my fault.  Bruce has tested this on Windows previously and fixed
some previous bugs also introduced by me in the same area; so we know it
works.

Maybe, to reduce future backpatching pain, we could backpatch the change
to exec_prog() API now that you have fixed the implementation?

> Barring objection I will commit this before long.

Thanks.

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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Andrew Dunstan
Date:
Subject: pg_upgrade test mods for Windows/Mingw