[HACKERS] Re: [COMMITTERS] pgsql: Process variadic arguments consistently in json functions

On 10/26/2017 12:12 AM, Michael Paquier wrote: > On Wed, Oct 25, 2017 at 5:24 AM, Andrew Dunstan <and...@dunslane.net> wrote: >> Process variadic arguments consistently in json functions >> >> json_build_object and json_build_array and the jsonb equivalents did not &g

[HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

On 10/22/2017 04:35 PM, Michael Paquier wrote: > On Mon, Oct 23, 2017 at 1:44 AM, Andrew Dunstan > <andrew.duns...@2ndquadrant.com> wrote: > >> here's a patch that works that way, based on Michael's code. > Patch not attached :) > I still have a patch half-cooked, t

[HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

On 10/22/2017 12:11 PM, Andrew Dunstan wrote: > > On 10/21/2017 07:33 PM, Michael Paquier wrote: >> On Sun, Oct 22, 2017 at 1:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I don't think collecting all the arguments is particularly special --- >>> for

Re: [HACKERS] Continuous integration on Windows?

On 10/13/2017 08:09 AM, Thomas Munro wrote: > On Fri, Oct 13, 2017 at 1:42 PM, Andrew Dunstan > <andrew.duns...@2ndquadrant.com> wrote: >> Well, as you can see here the appveyor.yml file can live outside the >> tree that's being built. > Here's a Wiki page wher

Re: [HACKERS] Still another race condition in recovery TAP tests

> > Not everyone has cpanminus installed either. My approach in the buildfarm code is to lean over backwards in order to avoid non-standard modules. For the problem at hand we use cp/xcopy, but the tree being copied is stable so we don't run into the disappearing/changing file problem. cheers

Re: [HACKERS] Continuous integration on Windows?

On 10/12/2017 06:46 PM, Thomas Munro wrote: > On Fri, Oct 13, 2017 at 10:57 AM, Andrew Dunstan > <andrew.duns...@2ndquadrant.com> wrote: >> Actually, that didn't take too long. >> >> No testing yet, but this runs a build successfully: >&g

Re: [HACKERS] Continuous integration on Windows?

On 10/12/2017 04:14 PM, Andrew Dunstan wrote: > > On 10/11/2017 11:04 PM, Thomas Munro wrote: >> Hi hackers, >> >> I don't use Windows myself, but I'd rather avoid submitting patches >> that fail to build, build with horrible warnings or blow up on that >

Re: [HACKERS] Continuous integration on Windows?

k. A couple of things not in their pre-built images that we'll need are flex and bison. We might be able to overcome that with chocolatey, which is installed, haven't tested yet. getting a working appveyor.yml will take a little while, though. cheers andrew -- Andrew Dunstanhttps

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/27/2017 02:52 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> At this stage on reflection I agree it should be pulled :-( > That seems to be the consensus, so I'll go make it happen. > >> I'm not happy about the idea o

Re: [HACKERS] datetime.h defines like PM conflict with external libraries

On 10/03/2017 04:43 PM, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2017-10-03 16:34:38 -0400, Andrew Dunstan wrote: >>> AFAICT at a quick glance these are only used in a couple of files. Maybe >>> the defs need to be floated off to a d

Re: [HACKERS] datetime.h defines like PM conflict with external libraries

only used in a couple of files. Maybe the defs need to be floated off to a different header with more limited inclusion? cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mail

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 10/01/2017 04:48 PM, Andres Freund wrote: > On 2017-10-01 16:42:44 -0400, Tom Lane wrote: >> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>> On 09/30/2017 10:32 PM, Andres Freund wrote: >>>> Heh. I'm inclined to take it out. We could add a --us

[HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 09/30/2017 10:32 PM, Andres Freund wrote: > Hi, > > On 2017-09-30 22:28:39 -0400, Andrew Dunstan wrote: >>>> But even after fixing that, there unfortunately is: >>>> >>>> static void >>>> set_sig(char *signame) >>>&g

Re: [HACKERS] alter server for foreign table

up properly with DROPs as the first > options. > > I assume the proposal is to allow changing to a different server using the same FDW. I can see all sorts of odd things happening if we allow changing to a server of a different FDW. cheers andrew -- Andrew Dunstan

Re: [HACKERS] Arrays of domains

On 09/29/2017 01:10 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 09/28/2017 05:44 PM, Tom Lane wrote: >>> Assuming that that's going to happen for v11, I'm inclined to leave the >>> optimization problem until the dust sett

Re: [HACKERS] Arrays of domains

'm Ok with it as long as we don't forget to revisit this. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Domains and arrays and composites, oh my

so there would be less danger of a PL just treating it as an unconstrained base type as it might do if it saw TYPEFUNC_COMPOSITE. Maybe I'm wrong, but I have a strong suspicion that of we leave it like this now we'll regret it in the future. cheers andrew -- Andrew Dunstanhttps://

Re: [HACKERS] Arrays of domains

> how to benchmark. > > Some case where we only expect the current code to produce a single ArrayCoerceExpr, I guess. say doing text[] -> int[] ? cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, T

Re: [HACKERS] crash-recovery test vs windows

On 09/28/2017 12:29 PM, Andrew Dunstan wrote: > The new crash-recovery check is failing pretty reliably on jacana. It's > already excluded on MSVC machines, so I'm inclined to exclude it on Msys > as well. > > Sorry, I meant crash-restart cheers andrew -- Andrew Dunstan

[HACKERS] crash-recovery test vs windows

The new crash-recovery check is failing pretty reliably on jacana. It's already excluded on MSVC machines, so I'm inclined to exclude it on Msys as well. Thoughts? cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA

Re: [HACKERS] Domains and arrays and composites, oh my

nice patch, and very small indeed all things considered. From a code point of view I have no criticism, although maybe we need to be a bit more emphatic in the header file comments about the unwisdom of using get_expr_result_tupdesc(). I do think that treating a function returning a domain-over-composite

Re: [HACKERS] Arrays of domains

does the one thing stated above - there's just a lot of housekeeping that goes along with that. I couldn't see any obvious problems with the implementation. I wonder if we need to do any benchmarking to assure ourselves that the changes to ArrayCoerceExpr don't have a significant performance impa

[HACKERS] Re: ALTER enums (was Re: [COMMITTERS] pgsql: doc: first draft of Postgres 10 release notes)

On 09/27/2017 06:05 AM, Alvaro Herrera wrote: > Bruce Momjian wrote: >> doc: first draft of Postgres 10 release notes > I noticed that this item > > + > + > +Reduce locking required for adding values to enum types (Andrew Dunstan, > +Tom Lane) > + > + > + &g

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/26/2017 06:04 PM, Andrew Dunstan wrote: > > On 09/26/2017 05:45 PM, Stephen Frost wrote: >> I've not been following along very closely- are we sure that ripping >> this out won't be worse than dealing with it in-place? Will pulling it >> out also require a

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

unction signatures weren't changed. cheers andrew -- Andrew Dunstanhttps://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: htt

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

t be turning off parallel mode if the hash exists, but I'm unclear how that would work. cheers andrew -- Andrew Dunstanhttps://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

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/25/2017 01:34 PM, David E. Wheeler wrote: > On Sep 25, 2017, at 10:55, Andrew Dunstan <andrew.duns...@2ndquadrant.com> > wrote: > >> Let's ask a couple of users who I think are or have been actually >> hurting on this point. Christophe and David, any opinions?

Re: [HACKERS] Built-in plugin for logical decoding output

do something that is, indeed, more general, > i.e., that supports high-performance scenarios too? > > >    A general purpose lower bandwidth plugin might one supporting Protocol Buffers. The downside is that unlike json it's not self-contained, you need the message definitions to interpret the

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/25/2017 10:42 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 09/25/2017 10:14 AM, Tom Lane wrote: >>> Oh ... I did not think we were on the same page, because your patch >>> didn't include removal of the same-transaction

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/25/2017 10:14 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 09/24/2017 07:06 PM, Tom Lane wrote: >>> So I think we should just stop with the blacklist test for v10, >>> and then see if we still get complaints (and e

Re: [HACKERS] visual studio 2017 build support

. > > Thanks, committed and backpatched to 9.6 It would be nice to get buildfarm members going supporting  VS2015 and VS2017 cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-h

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

ere in previous releases, and ahead of > where we'd be if we end up reverting the patch altogether. > > That's pretty much what I was saying. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Se

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/24/2017 04:37 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> OK, here's the finished patch. It has a pretty small footprint all >> things considered, and I think it guarantees that nothing that could be >> done in this area in 9.

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/23/2017 06:06 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> OK, I think I'm convinced. Here's is the WIP code I put together for the >> blacklist. I'm was looking for a place to put the init call, but since >> it's possibly n

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/23/2017 03:52 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 09/23/2017 02:00 PM, Tom Lane wrote: >>> So I'm back to not being sure about the path forward. Maybe it would be >>> all right to say "the value added

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/23/2017 02:00 PM, Tom Lane wrote: > I wrote: >> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>> I see what you're saying, but my idea was slightly different. We would >>> only add to the hashtable I had in mind at the bottom AddEnumLabel(). &

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/23/2017 11:16 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: > >>> The immediate question is do we care to design/implement such a thing >>> post-RC1. I'd have to vote "no". I think the most prudent thing to >>

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/22/2017 11:19 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 09/22/2017 05:46 PM, Tom Lane wrote: >>> I'm not sure if that qualifies as a stop-ship problem, but it ain't >>> good, for sure. We need to look at w

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

g a per-transaction hash of unsafe enum values (which will almost always be empty). It might even speed up the check. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hacke

Re: [HACKERS] visual studio 2017 build support

also says: Microsoft Visual Studio Build Tools 2017 Also installs on Windows Server 2008 R2 SP1 So I'm inclined to adjust the documentation accordingly. cheers andrew Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Tr

Re: [HACKERS] Windows warnings from VS 2017

On 09/21/2017 09:41 PM, Andres Freund wrote: > On 2017-09-21 09:30:31 -0400, Tom Lane wrote: >> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>> The speed of memset is hardly going to be the dominating factor in a >>> 'CREATE DATABASE' command, so we

Re: [HACKERS] visual studio 2017 build support

ersion is still points > to V141, when I create a sample project with VS 2017 and the version > number is inline with nmake version also. > > > I was about to commit this after a good bit of testing when I noticed this: +   Building with Visual Studio 2017 is supported

Re: [HACKERS] Windows warnings from VS 2017

On 09/21/2017 02:53 AM, Haribabu Kommi wrote: > > > On Thu, Sep 21, 2017 at 12:26 PM, Andrew Dunstan > <andrew.duns...@2ndquadrant.com > <mailto:andrew.duns...@2ndquadrant.com>> wrote: > > > > On 09/20/2017 08:18 PM, Andrew Dunstan wrote: >

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 08:18 PM, Andrew Dunstan wrote: > > On 09/20/2017 07:54 PM, Tom Lane wrote: >> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>> It's also warning that it will copy 16 bytes to a 13 byte structure at >>> lines 518, 1293 and 1294 of

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 07:54 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> It's also warning that it will copy 16 bytes to a 13 byte structure at >> lines 518, 1293 and 1294 of src/backend/commands/dbcommands.c. I haven't >> seen any

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 07:32 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 09/20/2017 06:13 PM, Michael Paquier wrote: >>> Those are around for some time, see here: >>> https://www.postgresql.org/message-id/CAB7nPqTkW=b_1j

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 06:13 PM, Michael Paquier wrote: > On Thu, Sep 21, 2017 at 7:08 AM, Andrew Dunstan > <andrew.duns...@2ndquadrant.com> wrote: >> First, it warns about a couple of unused variables at lines 4553 and >> 4673 of src/backend/optimizer/path/costsize.c. I thi

[HACKERS] Windows warnings from VS 2017

on this compiler with the MemSet macros. The regression tests are currently failing on my test platform (Windows Server 2016) because it says it can't change permissions on the testtablespace directory. I have no idea what's going on there, still investigating. cheers andrew -- Andrew Dunstan

Re: [HACKERS] Show backtrace when tap tests fail

ot installed. > eval { use Carp::Always; } > > Comments? > Or maybe Devel::Confess ? In an eval you need a 'require' rather than a 'use', AFAIK. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Ser

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contrib module

On 09/19/2017 02:47 PM, Andrew Dunstan wrote: > > On 09/19/2017 11:11 AM, Tom Lane wrote: >> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>> This seems to have upset a number or animals in the buildfarm. >> Actually, after looking closer, my advic

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contrib module

On 09/19/2017 11:11 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> This seems to have upset a number or animals in the buildfarm. > Actually, after looking closer, my advice is just to drop the new > test cases involving accented lett

[HACKERS] Re: [COMMITTERS] pgsql: Add citext_pattern_ops for citext contrib module

On 09/19/2017 08:35 AM, Andrew Dunstan wrote: > Add citext_pattern_ops for citext contrib module > > This is similar to text_pattern_ops. > This seems to have upset a number or animals in the buildfarm. I could create a third output file, but I am seriously questioning the

Re: [HACKERS] [PATCH] Add citext_pattern_ops to citext contrib module

t_1.out matches the results in en_US. If you don't > satisfy both of those cases, the buildfarm will not like you. > > I'm about to pick this one up - I will handle the expected file issue. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadr

Re: [HACKERS] Automatic testing of patches in commit fest

and what doesn't build will be very useful on its own, especially if there are links to the failure reports. When we are satisfied that we're not getting significant numbers of false negatives over a significant period we can talk about automating CF state changes. I agree this is nice work. chee

Re: [HACKERS] pgbench tap tests & minor fixes.

On 09/11/2017 01:58 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 09/08/2017 09:40 AM, Tom Lane wrote: >>> Like you, I'm a bit worried about the code for extracting an exit >>> status from IPC::Run::run. We'll hav

Re: [HACKERS] pgbench tap tests & minor fixes.

cting an exit > status from IPC::Run::run. We'll have to keep an eye on the buildfarm > for a bit. If there's any trouble, I'd be inclined to drop it down > to just success/fail rather than checking the exact exit code. > > bowerbird seems to have been made unhappy. cheers

[HACKERS] Re: [COMMITTERS] pgsql: Record full paths of programs sought by "configure".

On 08/07/2017 04:20 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 08/07/2017 04:07 PM, Tom Lane wrote: >>> Sorry, I was imprecise. What I'm suggesting is that you drop the >>> runtime PATH-foolery and instead pu

[HACKERS] Re: [COMMITTERS] pgsql: Record full paths of programs sought by "configure".

On 08/07/2017 04:07 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 08/07/2017 03:36 PM, Tom Lane wrote: >>> My goodness, that's ugly. Is it really better than injecting >>> "PROVE=prove"? (I'd suggest

[HACKERS] Re: [COMMITTERS] pgsql: Record full paths of programs sought by "configure".

On 08/07/2017 03:36 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 08/07/2017 03:21 PM, Tom Lane wrote: >>> I'm confused. AFAIK, that commit did not change which "prove" would >>> be used --- at least not unless you

[HACKERS] Re: [COMMITTERS] pgsql: Record full paths of programs sought by "configure".

On 08/07/2017 03:21 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 07/31/2017 01:02 PM, Tom Lane wrote: >>> Record full paths of programs sought by "configure". >> The problem with this commit, as jacana is demonstratin

[HACKERS] Re: [COMMITTERS] pgsql: Record full paths of programs sought by "configure".

o run with the perl from the MSys DTK that understands MSys virtualized paths. I have a hack that will allow the buildfarm to overcome the difficulty, (essentially it passes 'PROVE=prove' to make) but that's fairly ugly and certainly non-intuitive for someone running an MSys build and

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

On 07/31/2017 06:54 PM, Tom Lane wrote: > but could we do something like > my $pflags = "PROVE_FLAGS='" . ($ENV{PROVE_FLAGS} || "--timer") . "'"; > > to allow overriding this choice from the buildfarm config? > > I have committed this in a slightly different form. cheers andrew --

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

On 07/28/2017 08:22 AM, Andrew Dunstan wrote: > > On 07/27/2017 11:58 PM, Tom Lane wrote: >> I kinda suspect we're not actively testing non-MULTIPLICITY builds >> either. The 5.8.7 test I just ran was with a non-MULTIPLICITY build, >> so the case doesn't seem acti

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

e owners to apply a fairly simple patch. cheers andrew -- Andrew Dunstanhttps://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 s

Re: [HACKERS] pl/perl extension fails on Windows

uch a thing exists) We haven't used PERL_IMPLICIT_CONTEXT to date, and without ill effect. For example. it's in the ExtUtils::Embed::ccopts for the perl that jacana and bowerbird happily build and test against. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Develop

Re: [HACKERS] pl/perl extension fails on Windows

def getlogin > 520*#undef setjmp* > ... > ... > > 651 #define times PerlProc_times > 652 #define waitPerlProc_wait > 653 *#define setjmp PerlProc_setjmp > > * What is the

Re: [HACKERS] Testlib.pm vs msys

On 07/26/2017 11:12 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: > >>> I still find this pretty ugly :-(. >> I'm open to alternative suggestions. But I don't want to spend a heck of >> a lot of time on this. > Well, let's at l

Re: [HACKERS] Testlib.pm vs msys

On 07/26/2017 09:33 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: > >> The latter fact makes me >> theorize that the problem arises from the fairly ancient perl that Msys >> provides, and which we need to use to run prove

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 02:45 PM, Andrew Dunstan wrote: >> Anyway, if we believe that it broke with f13ea95f9, hen it's plausible >> that CMD.EXE has been sharing pg_ctl's stdout/stderr all along, and we >> just had not noticed before. Could you check what happens if we >> ch

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 01:41 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 07/25/2017 11:25 AM, Tom Lane wrote: >>> Oh. So when was the last time it worked? And why do the buildfarm >>> archives contain apparently-successful l

Re: [HACKERS] pl/perl extension fails on Windows

to the problematic >>> field(s). >> Why ccopts rather than ccflags? > I was looking at the current code which fetches ldopts, and analogizing. > Don't know the difference between ccflags and ccopts. > > per docs: ccopts() This function com

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 11:25 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 07/25/2017 11:11 AM, Tom Lane wrote: >>> What I'm on about is that jacana still succeeds entirely, more than half >>> the time. If this is a handle-dupli

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 11:11 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 07/24/2017 09:33 PM, Tom Lane wrote: >>> Seems like the TAP test should fail every time, if this is a full >>> description. But maybe it's part

Re: [HACKERS] pl/perl extension fails on Windows

> > perl -MExtUtils::Embed -e ccopts > > on one of the affected installations, and compare that to the problematic > field(s). -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fwrapv -f

Re: [HACKERS] Testlib.pm vs msys

n pg_ctl.c. It's not apparent to me that there > are any handles we do need the CMD process to inherit. > > Maybe. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- S

Re: [HACKERS] pl/perl extension fails on Windows

that on earlier versions of perl we got by without this check for years without any issue or complaint I recall hearing of. If we don't adopt this I would not be at all surprised to see Windows packagers adopt it anyway. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadr

[HACKERS] Testlib.pm vs msys

detecting the exit properly. The workaround I have found to work is to redirect command_like's output instead to a couple of files and then slurp in those files and delete them. A bit hacky, I know, so I'm open to other suggestions. cheers andrew -- Andrew Dunstanhttps://www

Re: [HACKERS] Syncing sql extension versions with shared library versions

be nice if we could teach yhe load mechanism to expand a a version escape in the MODULE_PATHNAME. e.g. MODULE_PATHNAME = '$libdir/foo-$version' cheers andtrew -- Andrew Dunstanhttps://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

[HACKERS] Unportable use of select for timeouts in PostgresNode.pm

objections I'll prepare a patch along those lines. cheers andrew -- Andrew Dunstanhttps://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

Re: [HACKERS] pl/perl extension fails on Windows

On 07/13/2017 10:36 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 07/13/2017 08:08 AM, Ashutosh Sharma wrote: >>> -dVAR; dXSBOOTARGSAPIVERCHK; >>> +dVAR; dXSBOOTARGSNOVERCHK; >> Good job hunting this down! >&

Re: [HACKERS] pl/perl extension fails on Windows

dXSBOOTARGSNOVERCHK; > > I need to further investigate, but let me know if you have any ideas. Good job hunting this down! One suggestion I saw in a little googling was that we add this to the XS file after the inclusion of XSUB.h: #undef dXSBOOTARGSAPIVERCHK #define dXSBOOTARGSAPIVERCHK

Re: [HACKERS] pl/perl extension fails on Windows

ra box - and we have no problems on Linux, only on > Windows. > > Yeah, I have this on one of my Windows boxes, and haven't had time to get to the bottom of it yet ;-( Latest versions of ActivePerl don't ship with library descriptor files, either, which is unpleasant. cheers andrew -- Andrew

Re: [HACKERS] Arrays of domains

On 07/11/2017 12:44 PM, Tom Lane wrote: > > Can anyone think of a reason not to pursue that? > > I'm all for it. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

On 06/26/2017 10:45 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 06/23/2017 07:47 AM, Andrew Dunstan wrote: >>> Rerunning with some different settings to see if I can get separate cores. >> Numerous attempts to get core dum

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

On 06/26/2017 10:36 AM, Amit Kapila wrote: > On Fri, Jun 23, 2017 at 9:12 AM, Andrew Dunstan > <andrew.duns...@2ndquadrant.com> wrote: >> >> On 06/22/2017 10:24 AM, Tom Lane wrote: >>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>>>

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

On 06/23/2017 07:47 AM, Andrew Dunstan wrote: > > On 06/23/2017 12:11 AM, Tom Lane wrote: >> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>> On 06/22/2017 10:24 AM, Tom Lane wrote: >>>> That earlier request is still valid. Also, if you can r

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

On 06/23/2017 12:11 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 06/22/2017 10:24 AM, Tom Lane wrote: >>> That earlier request is still valid. Also, if you can reproduce the >>> symptom that lorikeet just

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

On 06/22/2017 10:24 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> Please let me know if there are tests I can run. I missed your earlier >> request in this thread, sorry about that. > That earlier request is still valid. Al

Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

ed your earlier request in this thread, sorry about that. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

On 06/21/2017 02:25 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 06/21/2017 11:30 AM, Tom Lane wrote: >>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>>> Unfortunately this seems precluded by the use

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

On 06/21/2017 11:30 AM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> Unfortunately this seems precluded by the use of the non-standard >> "err.h". It looks like that will trip us up on mingw also. > Hm, why? Doesn't the

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

On 06/21/2017 08:20 AM, Andrew Dunstan wrote: > > On 06/20/2017 08:30 PM, Tom Lane wrote: >> Michael Paquier <michael.paqu...@gmail.com> writes: >>> On Wed, Jun 21, 2017 at 8:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>>> Yeah, I thought i

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

ly simple based on Craig Ringer's recent work in building extensions on Windows using cmake. I'll take a look when I get a chance, but I don't think it's a high priority. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Train

Re: [HACKERS] pg_bsd_indent 2.0 is available from git.postgresql.org

built it on Cygwin without touching a line of code, will probably be able to to the same on Mingw. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

[HACKERS] Announcing Release 5 of the PostgreSQL Buildfarm Client

Release 5 of the PostgreSQL Buildfarm Client has been released and can be downloaded from In a similar move to PostgreSQL version numbering, with this release we move to a one part numbering system. In addition to a number

Re: [HACKERS] Buildfarm failures on woodlouse (in ecpg-check)

ing ecpg ages ago on bowerbird because I was getting errors. That's an older version of the toolset. We already define _WIN32_WINNT to be 0x0600 on all appropriate platforms (Vista/2008 and above), so I think you could probably just check for that value. I have no opinion on the pthread quest

Re: [HACKERS] jsonb_to_tsvector should be immutable

On 06/08/2017 03:06 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> On 06/08/2017 02:26 PM, Tom Lane wrote: >>> Yeah, if the (regconfig,text) one is considered immutable, I don't see >>> why the other two aren't. The justif

Re: [HACKERS] jsonb_to_tsvector should be immutable

g. > > (You could argue that none of these should be immutable because text > search configurations are changeable, but we already decided to ignore > that for the (regconfig,text) case.) > > Yes, agreed it should be done consistently with text. cheers andrew --

Re: [HACKERS] Does pg_upgrade really support "make installcheck"?

table since some time in April. I recently started work on bringing it up to production standard. It does take up a lot of space, since it's saving out binaries and databases that are normally removed at the end of each buildfarm run. On crake the static space required is 3.2Gb. That's in contrast to

Re: [HACKERS] PROVE_FLAGS

On 05/23/2017 06:59 AM, Andrew Dunstan wrote: > On 17 May 2017 at 14:30, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, May 16, 2017 at 9:20 PM, Andrew Dunstan >> <andrew.duns...@2ndquadrant.com> wrote: >>> Inheriting variables from the environment is a

  1   2   3   4   5   6   7   8   9   10   >