[COMMITTERS] pgsql: Get rid of useless global variable in pg_upgrade.

Get rid of useless global variable in pg_upgrade. Since the scandir() emulation was taken out of pg_upgrade, there's no longer any need for scandir_file_pattern to exist as a global variable. Replace it with a local in the one remaining function that was making use of it. Branch -- REL9_2_ST

[COMMITTERS] pgsql: Get rid of useless global variable in pg_upgrade.

Get rid of useless global variable in pg_upgrade. Since the scandir() emulation was taken out of pg_upgrade, there's no longer any need for scandir_file_pattern to exist as a global variable. Replace it with a local in the one remaining function that was making use of it. Branch -- master D

[COMMITTERS] pgsql: Improve pg_upgrade's load_directory() function.

Improve pg_upgrade's load_directory() function. Error out on out-of-memory, rather than returning -1, which the sole existing caller wasn't checking for anyway. There doesn't seem to be any use-case for making the caller check for failure here. Detect failure return from readdir(). Use a less p

[COMMITTERS] pgsql: Improve pg_upgrade's load_directory() function.

Improve pg_upgrade's load_directory() function. Error out on out-of-memory, rather than returning -1, which the sole existing caller wasn't checking for anyway. There doesn't seem to be any use-case for making the caller check for failure here. Detect failure return from readdir(). Use a less p

[COMMITTERS] pgsql: Improve coding around the fsync request queue.

Improve coding around the fsync request queue. In all branches back to 8.3, this patch fixes a questionable assumption in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are no uninitialized pad bytes in the request queue structs. This would only cause trouble if (a) there

[COMMITTERS] pgsql: Improve coding around the fsync request queue.

Improve coding around the fsync request queue. In all branches back to 8.3, this patch fixes a questionable assumption in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are no uninitialized pad bytes in the request queue structs. This would only cause trouble if (a) there

[COMMITTERS] pgsql: Improve coding around the fsync request queue.

Improve coding around the fsync request queue. In all branches back to 8.3, this patch fixes a questionable assumption in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are no uninitialized pad bytes in the request queue structs. This would only cause trouble if (a) there

[COMMITTERS] pgsql: Improve coding around the fsync request queue.

Improve coding around the fsync request queue. In all branches back to 8.3, this patch fixes a questionable assumption in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are no uninitialized pad bytes in the request queue structs. This would only cause trouble if (a) there

[COMMITTERS] pgsql: Improve coding around the fsync request queue.

Improve coding around the fsync request queue. In all branches back to 8.3, this patch fixes a questionable assumption in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are no uninitialized pad bytes in the request queue structs. This would only cause trouble if (a) there

[COMMITTERS] pgsql: Improve coding around the fsync request queue.

Improve coding around the fsync request queue. In all branches back to 8.3, this patch fixes a questionable assumption in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are no uninitialized pad bytes in the request queue structs. This would only cause trouble if (a) there

[COMMITTERS] pgsql: PL/Python: Remove PLy_result_ass_item

PL/Python: Remove PLy_result_ass_item It is apparently no longer used after the new slicing support was implemented (a97207b6908f1d4a7d19b37b818367bb0171039f), so let's remove the dead code and see if anything cares. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/71

[COMMITTERS] pgsql: Show step titles in the pg_upgrade man page

Show step titles in the pg_upgrade man page The upstream XSLT stylesheets missed that case. found by Álvaro Herrera Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d6ce58c01056fa0f475ea468f1633890f6a1d74c Modified Files -- doc/src/sgml/stylesheet-man.xs

[COMMITTERS] pgsql: Show step titles in the pg_upgrade man page

Show step titles in the pg_upgrade man page The upstream XSLT stylesheets missed that case. found by Álvaro Herrera Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/3d03c97a45b6904704e1ed2a4856a55396cb23b0 Modified Files -- doc/src/sgml/stylesheet

[COMMITTERS] pgsql: Remove recently added PL/Perl encoding tests

Remove recently added PL/Perl encoding tests These only pass cleanly on UTF8 and SQL_ASCII encodings, besides the Japanese encoding in which they were originally written, which is clearly not good enough. Since the functionality they test has not ever been tested from PL/Perl, the best answer see

[COMMITTERS] pgsql: Remove recently added PL/Perl encoding tests

Remove recently added PL/Perl encoding tests These only pass cleanly on UTF8 and SQL_ASCII encodings, besides the Japanese encoding in which they were originally written, which is clearly not good enough. Since the functionality they test has not ever been tested from PL/Perl, the best answer see

[COMMITTERS] pgsql: Remove recently added PL/Perl encoding tests

Remove recently added PL/Perl encoding tests These only pass cleanly on UTF8 and SQL_ASCII encodings, besides the Japanese encoding in which they were originally written, which is clearly not good enough. Since the functionality they test has not ever been tested from PL/Perl, the best answer see

Re: [COMMITTERS] pgsql: Introduce timeout handling framework

Peter Geoghegan writes: > Perhaps I'm asking a naive question, but wouldn't it be easier if > people had the opportunity to use the buildfarm without actually > committing something? Why? The whole point of the buildfarm is to break, as it were. I don't see the value of adding more bureaucracy i

Re: [COMMITTERS] pgsql: Introduce timeout handling framework

On 07/17/2012 11:08 AM, Peter Geoghegan wrote: On 17 July 2012 14:43, Andrew Dunstan wrote: This seems to have broken Windows builds. (And if people need reminding, cross-compiling is pretty easy:

Re: [COMMITTERS] pgsql: Introduce timeout handling framework

Alvaro Herrera writes: > Excerpts from Tom Lane's message of mar jul 17 10:07:53 -0400 2012: >> Yeah, my fault I think. I took out proc.h from postmaster.h, thinking >> it wasn't needed anymore, but the EXEC_BACKEND code needs it. > Will fix. Oh, I did it already. regar

Re: [COMMITTERS] pgsql: Introduce timeout handling framework

Excerpts from Tom Lane's message of mar jul 17 10:07:53 -0400 2012: > Andrew Dunstan writes: > > On 07/17/2012 12:03 AM, Alvaro Herrera wrote: > >> Introduce timeout handling framework > > > This seems to have broken Windows builds. > > Yeah, my fault I think. I took out proc.h from postmaster

Re: [COMMITTERS] pgsql: Introduce timeout handling framework

On 17 July 2012 14:43, Andrew Dunstan wrote: > This seems to have broken Windows builds. (And if people need reminding, > cross-compiling is pretty easy: > > ) Perhaps I'm asking a naiv

[COMMITTERS] pgsql: Put back storage/proc.h in postmaster.c.

Put back storage/proc.h in postmaster.c. I took this out thinking it wasn't needed anymore, but the EXEC_BACKEND code still needs it. Per buildfarm. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/57b9bdda39e05d127f6930045d289ffc9935c971 Modified Files

Re: [COMMITTERS] pgsql: Introduce timeout handling framework

Andrew Dunstan writes: > On 07/17/2012 12:03 AM, Alvaro Herrera wrote: >> Introduce timeout handling framework > This seems to have broken Windows builds. Yeah, my fault I think. I took out proc.h from postmaster.h, thinking it wasn't needed anymore, but the EXEC_BACKEND code needs it.

Re: [COMMITTERS] pgsql: Introduce timeout handling framework

On 07/17/2012 12:03 AM, Alvaro Herrera wrote: Introduce timeout handling framework This seems to have broken Windows builds. (And if people need reminding, cross-compiling is pretty easy: