[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 wrote: >> Process variadic arguments consistently in json functions >> >> json_build_object and json_build_array and the jsonb equivalents did not >> correctly process

[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 > wrote: > >> here's a patch that works that way, based on Michael's code. > Patch not attached :) > I still have a patch half-cooked, that I can send if necess

[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 wrote: >>> I don't think collecting all the arguments is particularly special --- >>> format() or concat() for ins

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 > 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 where I hope we can collect how-to info

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. chee

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 > wrote: >> Actually, that didn't take too long. >> >> No testing yet, but this runs a build successfully: >> <https://gist.github.com/adunstan/7f18e5db33bb2d73

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 th

Re: [HACKERS] Continuous integration on Windows?

;m taking a look. 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 Dun

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

On 09/27/2017 02:52 PM, Tom Lane wrote: > Andrew Dunstan 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 of marking an input function as not

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

On 10/03/2017 04:43 PM, Tom Lane wrote: > Andres Freund 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 different header with more li

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

nce these are 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 vi

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 writes: >>> On 09/30/2017 10:32 PM, Andres Freund wrote: >>>> Heh. I'm inclined to take it out. We could add a --use-the-force-luke >>>&g

[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

fixes 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 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 settles around CaseTestExpr. &g

Re: [HACKERS] Arrays of domains

I'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-ha

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 Dunstan

Re: [HACKERS] Arrays of domains

e what or > 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, Rem

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 Dun

[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,

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

behavior > we want for that case. So I don't want to create a precedent for that > here. > > Thoughts? > This is a pretty 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 he

Re: [HACKERS] Arrays of domains

orward, as is patch 3. Patch 2 is fairly complex, but it still 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 th

[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

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

o AFAIK - the function 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 yo

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

of a bad bunch of choices. Second choice might 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 > 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? > If I understand the issue c

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

> 11+, general purpose, 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

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

On 09/25/2017 10:42 AM, Tom Lane wrote: > Andrew Dunstan 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 heuristic. It'd be >&g

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

On 09/25/2017 10:14 AM, Tom Lane wrote: > Andrew Dunstan 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 exactly what they're >>>

Re: [HACKERS] visual studio 2017 build support

t; > 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?

where we were 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 DB

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

On 09/24/2017 04:37 PM, Tom Lane wrote: > Andrew Dunstan 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.6 will be forbidden. That's

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

On 09/23/2017 06:06 PM, Tom Lane wrote: > Andrew Dunstan 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 not going anywhere I

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

On 09/23/2017 03:52 PM, Tom Lane wrote: > Andrew Dunstan 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 by ADD VALUE can't be used in

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

On 09/23/2017 02:00 PM, Tom Lane wrote: > I wrote: >> Andrew Dunstan 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(). >>> Any other value, whethe

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

On 09/23/2017 11:16 AM, Tom Lane wrote: > Andrew Dunstan 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 >>> do is revert 15bc038

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

On 09/22/2017 11:19 PM, Tom Lane wrote: > Andrew Dunstan 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 whether we should revert 15bc038f9

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

der if we wouldn't be better doing this more directly, keeping 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 Su

Re: [HACKERS] visual studio 2017 build support

-vs > > That page 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

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 writes: >>> The speed of memset is hardly going to be the dominating factor in a >>> 'CREATE DATABASE' command, so we could certainly afford to

Re: [HACKERS] visual studio 2017 build support

nts > 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 +   dow

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 > <mailto:andrew.duns...@2ndquadrant.com>> wrote: > > > > On 09/20/2017 08:18 PM, Andrew Dunstan wrote: > > > > On 09/20/2017 07:5

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 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

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 07:54 PM, Tom Lane wrote: > Andrew Dunstan 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 ill effects of this so far

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 07:32 PM, Tom Lane wrote: > Andrew Dunstan 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_1jvvywd_g0wrkot+4ufqjggrv8osqbuzzxg...@mail.gmail.co

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 > wrote: >> First, it warns about a couple of unused variables at lines 4553 and >> 4673 of src/backend/optimizer/path/costsize.c. I think we can do a >> little rearrangemen

[HACKERS] Windows warnings from VS 2017

is possibly amiss 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.

Re: [HACKERS] Show backtrace when tap tests fail

d module, don't fail if not 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 Develop

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 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

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 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 letters. It surprises me not in the > leas

[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 point

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

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.2ndQuadrant.com PostgreSQL Develop

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

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. cheers andrew --

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

On 09/11/2017 01:58 PM, Tom Lane wrote: > Andrew Dunstan 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 have to keep an eye on the buildfarm &

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

> 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

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

On 08/07/2017 04:20 PM, Tom Lane wrote: > Andrew Dunstan 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 put this in configure's environm

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

On 08/07/2017 04:07 PM, Tom Lane wrote: > Andrew Dunstan 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 saying that to configure, not make, >&

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

On 08/07/2017 03:36 PM, Tom Lane wrote: > Andrew Dunstan 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 change PATH between co

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

On 08/07/2017 03:21 PM, Tom Lane wrote: > Andrew Dunstan 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 demonstrating, is that on >> Msys it finds

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

ve needs to 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

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 -- Sent

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

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

cal animals we can ask the 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)

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

hing 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 PostgreS

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

setjmp* > ... > ... > > 651 #define times PerlProc_times > 652 #define waitPerlProc_wait > 653 *#define setjmp PerlProc_setjmp > > * What is the minimal set of extra defines required

Re: [HACKERS] Testlib.pm vs msys

On 07/26/2017 11:12 AM, Tom Lane wrote: > Andrew Dunstan 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 least do the temp

Re: [HACKERS] Testlib.pm vs msys

On 07/26/2017 09:33 AM, Tom Lane wrote: > Andrew Dunstan 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 so the TAP tests >> understand the enviro

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 &

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 01:41 PM, Tom Lane wrote: > Andrew Dunstan 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 log_stage entries for pg_ctl-check >>

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

opts 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 combines "perl_inc()", "ccflags()"

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 11:25 AM, Tom Lane wrote: > Andrew Dunstan 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-duplication problem, how could it ever >

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 11:11 AM, Tom Lane wrote: > Andrew Dunstan 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 of the answer, so it seems worth >>>

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

Utils::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 -fno-strict-aliasing -mms-bitfields -I&q

Re: [HACKERS] Testlib.pm vs msys

eter > as FALSE not TRUE in 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,

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

ERCHK */ Note 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 Dunstan

[HACKERS] Testlib.pm vs msys

IPC::Run isn't 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 Duns

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

t; > It would 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

hear 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 c

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

On 07/13/2017 10:36 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 07/13/2017 08:08 AM, Ashutosh Sharma wrote: >>> -dVAR; dXSBOOTARGSAPIVERCHK; >>> +dVAR; dXSBOOTARGSNOVERCHK; >> Good job hunting this down! >> One suggestion I saw in a little

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

HK; > +dVAR; 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

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

gt; > 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 Dunstanhttps://www.2ndQuadr

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 & Ser

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

On 06/26/2017 10:45 AM, Tom Lane wrote: > Andrew Dunstan 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 dumps following methods suggested in >&g

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 > wrote: >> >> On 06/22/2017 10:24 AM, Tom Lane wrote: >>> Andrew Dunstan writes: >>>> Please let me know if there are tests I can run. I missed your earlier &

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 writes: >>> On 06/22/2017 10:24 AM, Tom Lane wrote: >>>> That earlier request is still valid. Also, if you can reproduce the >>>> symptom th

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

On 06/23/2017 12:11 AM, Tom Lane wrote: > Andrew Dunstan 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 showed and get a stack trace from the >>> (hypo

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

On 06/22/2017 10:24 AM, Tom Lane wrote: > Andrew Dunstan 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. Also, if you can reproduce the > symptom that lor

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

tests I can run. I missed 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@postg

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 writes: >> On 06/21/2017 11:30 AM, Tom Lane wrote: >>> Andrew Dunstan writes: >>>> Unfortunately this seems precluded by the use of the non-standard >>>> "err.h". It looks like that

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 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 -I search path get the right thing? >

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 writes: >>> On Wed, Jun 21, 2017 at 8:43 AM, Tom Lane wrote: >>>> Yeah, I thought it would work fine with Makefile-using Windows toolchains. >>&g

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

ng 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, Training & Services -- Sent via pg

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

needs? I have 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 m

[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)

. I turned off testing 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 opi

Re: [HACKERS] jsonb_to_tsvector should be immutable

On 06/08/2017 03:06 PM, Tom Lane wrote: > Andrew Dunstan 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 justification for the other three bein

Re: [HACKERS] jsonb_to_tsvector should be immutable

; > (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 and

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

mal crake, and has been stable 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

Re: [HACKERS] PROVE_FLAGS

On 05/23/2017 06:59 AM, Andrew Dunstan wrote: > On 17 May 2017 at 14:30, Robert Haas wrote: >> On Tue, May 16, 2017 at 9:20 PM, Andrew Dunstan >> wrote: >>> Inheriting variables from the environment is a part of make by design. >>> We have PG_PROVE_FLAGS for ou

  1   2   3   4   5   6   7   8   9   10   >