On 03/28/2017 07:31 AM, Dagfinn Ilmari Mannsåker wrote:
> Andrew Dunstan writes:
>
>> I would try something like this:
>>
>> @opts = grep { $_ !~ /\$\(/ && $_ =~ /^--/ }
>> map { s/\Q$(top_builddir)\E/\"$topdir\"/; }
>> sp
pand the
test in place.
I don't have much time this week to work on it, as there are one or
two other patches I also want to look at. If you clean these things
up I will commit it. The second patch looks fine.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
Postgr
On 29 March 2017 at 16:19, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On 29 March 2017 at 18:28, Andrew Dunstan
>> wrote:
>>
>> These patches seem fundamentally OK. But I'm still not happy with the
>> naming etc.
>
> I've changed names for
On 03/31/2017 03:17 PM, Oleg Bartunov wrote:
>
>
> On 30 Mar 2017 23:43, "Dmitry Dolgov" <9erthali...@gmail.com
> <mailto:9erthali...@gmail.com>> wrote:
>
> On 31 March 2017 at 00:01, Andrew Dunstan
> <mailto:andrew.duns...@2ndqua
On 04/03/2017 02:22 PM, Andres Freund wrote:
> On 2017-04-01 16:20:46 -0400, Andrew Dunstan wrote:
>>
>> On 03/31/2017 03:17 PM, Oleg Bartunov wrote:
>>>
>>> On 30 Mar 2017 23:43, "Dmitry Dolgov" <9erthali...@gmail.com
>>> <mailto:9erthal
On 04/03/2017 02:44 PM, Sven R. Kunze wrote:
> On 01.04.2017 22:20, Andrew Dunstan wrote:
>> I added documentation when I committed it for the new functions, in the
>> FTS section. I'm not sure what we need to add to the JSON section if
>> anything.
>
> Not
On 04/03/2017 03:41 PM, Sven R. Kunze wrote:
> On 03.04.2017 21:30, Andrew Dunstan wrote:
>> On 04/03/2017 02:44 PM, Sven R. Kunze wrote:
>>> On 01.04.2017 22:20, Andrew Dunstan wrote:
>>>> I added documentation when I committed it for the new functions, in
>
On 04/03/2017 05:17 PM, Andres Freund wrote:
> On 2017-03-21 14:31:08 -0400, Andrew Dunstan wrote:
>>
>> On 03/21/2017 01:37 PM, David Steele wrote:
>>> On 3/16/17 11:54 AM, David Steele wrote:
>>>> On 2/1/17 12:53 AM, Michael Paquier wrote:
>>>>&g
On 04/04/2017 05:18 PM, Andrew Dunstan wrote:
>
> On 04/03/2017 05:17 PM, Andres Freund wrote:
>> On 2017-03-21 14:31:08 -0400, Andrew Dunstan wrote:
>>> On 03/21/2017 01:37 PM, David Steele wrote:
>>>> On 3/16/17 11:54 AM, David Steele wrote:
>>>&g
es prove anything at all
>> about whether the feature does what it's claimed to.
> That echoes my perception - so let's move this to the next CF? It's not
> like this patch has been pending for very long.
>
Or just Return with Feedback.
ISTM before we revisit this
;
> Therefore I propose changing the defaults in pg_regress.c.
>
+1
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
s a bit like overkill, though.
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
On 04/05/2017 07:24 PM, Andrew Dunstan wrote:
>
> OK, I have been through this and I think it's basically committable. I
> am currently doing some cleanup, such as putting all the typedefs in one
> place, fixing redundant comments and adding more comments, declaring all
>
ast) 2013, and we've had only one
> complaint, then I'd say there are too few potential users to justify
> the maintenance burden.
>
>
I agree.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x
s errors of the same ilk.
>
> I don't think any recent changes are supposed to affect deadlock
> detector behaviour?
>
Both these machines have CLOBBER_CACHE_ALWAYS set. And on both machines
recent changes have made the isolation tests run much much longer.
cheers
andrew
-
On 04/08/2017 10:11 AM, Andrew Dunstan wrote:
>
>
> Forwarded Message
> Subject: Re: [HACKERS] Running make check-world in buildfarm (was Re:
> [COMMITTERS] pgsql: Use SASLprep to normalize passwords for SCRAM
> authentication.)
> Date: Sat
On 04/08/2017 12:11 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>>> I think it's partially knowing which target failed, and which
>>> regression.diffs to display. If we were able to revamp check-world so
>>> it outputs a list of targets the re
On 04/08/2017 02:49 PM, Andrew Dunstan wrote:
>
> On 04/08/2017 12:11 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>>> I think it's partially knowing which target failed, and which
>>>> regression.diffs to display. If we were able to revamp check-w
qu2taf1ku4iuu...@mail.gmail.com
> still applies and passes all the tests.
Sorry, previous notification flew by me. I Have looked at the patch. On
the surface it looks fine and I will apply after running a test, should
be today.
cheers
andrew
--
Andrew Dunstanhttps://www.2n
.
[11:21:06] restarting db (cs_CZ.UTF-8)...
[11:21:08] running make test-modules installcheck (cs_CZ.UTF-8)...
[11:21:24] stopping db (cs_CZ.UTF-8)...
[11:21:42] running make ecpg check ...
[11:22:12] running find_typedefs ...
[11:22:50] OK
--
Andrew Dunstanhttps://www.2ndQuadran
On 04/11/2017 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan
>> wrote:
>>> This buildfarm run as you can see takes 33m32s, and the Tap tests take a
>>> combined 19m52s of that time.
>> I don't thi
On 04/11/2017 03:58 PM, Andres Freund wrote:
> On 2017-04-11 15:52:34 -0400, Tom Lane wrote:
>> Andrew Dunstan writes:
>>>> The other thing that might be useful here is to push on parallelizing
>>>> buildfarm runs.
>>> One reason I haven't sup
On 04/11/2017 08:12 PM, Craig Ringer wrote:
>
>
> On 12 Apr. 2017 03:14, "Andrew Dunstan"
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
>
>
> On 04/11/2017 12:08 PM, Tom Lane wrote:
> > Robert Haas <mailto:robertmh...@gmail.
ase.
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
On 04/12/2017 08:40 AM, Andrew Dunstan wrote:
>
> On 04/12/2017 01:27 AM, Craig Ringer wrote:
>> BTW, I suggest adding --timer to our default PROVE_FLAGS, so we can
>> collect more data from the buildfarm on what takes a while. Sample
>> output:
>>
>
>
ase "wincrypt.h". Therefore, unless there's an objection
I propose to lower case that "W".
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers ma
ery last second would be to put something like
TZ => 'Us/Eastern',
in the build_env section of the config file. But as you say we don't
want everyone doing that.
Alternatively, we could have an initdb TAP test that explicitly removed
the environment setting so we'd g
ot;/C=XY/CN=yourdomain.name"|
Is there any reason for sticking with the current instructions?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list
On 04/15/2017 09:58 AM, Andrew Dunstan wrote:
> The instructions on how to create a self-signed certificate in s 18.9.3
> of the docs seem unduly cumbersome. AFAICT we could replace all the
> commands (except the chmod) with something like this:
>
> |openssl req -new-x509
On 04/15/2017 11:44 AM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Alternatively, we could have an initdb TAP test that explicitly removed
>> the environment setting so we'd get coverage of select_default_timezone,
>> and have the buildfarm set TZ to some
On 04/15/2017 12:13 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> What I had in mind was the attached plus roughly this in the buildfarm
>> client:
>> $ENV{TZ} ||= 'US/Eastern';
>> or whatever zone we choose to use.
> How about letting the first
On 04/15/2017 02:13 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Sure. Just means putting this code a bit later in the file. "make check"
>> is only one initdb, so it won't cost much. I'm still inclined to force a
>> TAP test for initdb with no
On 04/16/2017 07:43 PM, Peter Eisentraut wrote:
> On 4/15/17 12:33, Andrew Dunstan wrote:
>> Sure. Just means putting this code a bit later in the file. "make check"
>> is only one initdb, so it won't cost much. I'm still inclined to force a
>> TAP test
On 04/17/2017 02:19 PM, Bruce Momjian wrote:
> On Sat, Apr 15, 2017 at 11:17:14AM -0400, Andrew Dunstan wrote:
>>
>> On 04/15/2017 09:58 AM, Andrew Dunstan wrote:
>>> The instructions on how to create a self-signed certificate in s 18.9.3
>>> of the docs seem u
nt variable to set up a base directory
> for all the nodes created in PostgresNode.pm, and use that for
> temporary statistics with a custom folder name. But that's not
> scalable if we want to enforce more parameter.
>
>
What more parameters do you want?
cheers
andrew
nderstand that PG community is not
> harsh/intimidating to newbies and thus, I am feeling at home.
>
>
Glad you have found it so.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
way forward here.
>
Agreed, a well organized web site would work much better.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On 04/18/2017 08:23 AM, Michael Paquier wrote:
> On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan
> wrote:
>> Yeah, but the way you have done it could also to lead to errors unless
>> you're very careful, as I found on axolotl (which died recently,
>> unfortuna
s from there at least
> in the case of hamster. When initializing a node via PostgresNode.pm,
> we would just check for this variable, and the init() routine just
> creates a temporary folder in it, setting up temp_stats_path in
> postgresql.conf.
How is that going to deal with your wa
config_opts+=--enable-tap-tests \
--config-set locales+=en_US.utf8
If you run something like this against your development code, and it
succeeds, you can be reasonably confident that if committed it won't
sent the buildfarm all red.
cheers
andrew
--
Andrew Dunstanht
t of reach. I don't even want to think about how long it
> might take a CLOBBER_CACHE_ALWAYS animal to run these tests.
You can disable the extra tests by adding this to the buildfarm command
line:
--skip-steps=misc-check
cheers
andrew
>
> regard
On 04/19/2017 01:38 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I have released version 4.19 of the PostgreSQL Buildfarm client. It can
>> be downloaded from
>> <https://buildfarm.postgresql.org/downloads/releases/build-farm-4_19.tgz>
> Nice work!
>
Thank
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
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
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
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?
>
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
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
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
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
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
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
&
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
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
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
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
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
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
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
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
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
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,
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
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
>>>
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
>
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()"
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
>>
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
&
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
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
setjmp*
> ...
> ...
>
> 651 #define times PerlProc_times
> 652 #define waitPerlProc_wait
> 653 *#define setjmp PerlProc_setjmp
>
> *
What is the minimal set of extra defines required
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
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)
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
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
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
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
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
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,
>&
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
ld be sufficient. So I suggest the attached patch.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/test/recovery/t/001_stream_rep.pl b/src/test/recovery/t/001_stream_rep
On 04/21/2017 10:36 AM, Daniel Gustafsson wrote:
>> On 21 Apr 2017, at 15:08, Andrew Dunstan
>> wrote:
>>
>> As we discovered yesterday via jacana, very old versions of Test::More
>> don't support the note() function. It therefore seems prudent to specify
On 04/21/2017 10:45 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> As we discovered yesterday via jacana, very old versions of Test::More
>> don't support the note() function. It therefore seems prudent to specify
>> a minimum version number for the module in
On 04/21/2017 09:22 PM, Craig Ringer wrote:
>
>
> On 22 Apr. 2017 4:23 am, "Tom Lane" <mailto:t...@sss.pgh.pa.us>> wrote:
>
> Peter Eisentraut <mailto:peter.eisentr...@2ndquadrant.com>> writes:
> > On 4/21/17 14:49, Andrew Dunstan wr
Paths that go in recovery.conf or archive commands must of course be
pure Windows paths.In this case the path would have been correct if
prefixed with "c:/Mingw/Msys/1.0"
I'll try to come up with a fix for that.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuad
xtra blank lines are problematic.
>
>
+1. Not sure how we survived so long with it the way it is.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent
On 04/22/2017 04:43 PM, Andrew Dunstan wrote:
> After we got over the Test::More version issue, the recovery tests
> proceeded to fail fairly spectacularly in a test run on jacana.
>
>
> Test 6 fails because there is a CR in the returned stdout from psql. I'm
> inc
tempt to minimize the unnecessary running of installs.
Once we have this I will switch the buildfarm client to use it. The
previous bincheck procedure is kept to avoid breakage of scripts,
buildfarm clients etc.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
Postg
iding an installcheck target for tests like recover. In at
least one case (buildfarmn jacana) installs are quite expensive (2 or 3
minutes) and if they are pointless as seems to be the case here why
can't we just avoid them?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQu
On 04/23/2017 10:33 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> AFAICT, unlike the pg_regress checks, which in the installcheck case run
>> against a running instance of postgres, for TAP tests the only
>> difference is that that for the check case a temp install is d
On 04/25/2017 10:45 AM, Robert Haas wrote:
> On Sun, Apr 23, 2017 at 10:57 PM, Andrew Dunstan
> wrote:
>> On 04/23/2017 10:33 PM, Tom Lane wrote:
>>> Andrew Dunstan writes:
>>>> AFAICT, unlike the pg_regress checks, which in the installcheck case run
>>&g
stall contrib
and test_modules in the temp install directory as part of their install
steps and to check that that's been done before using NO_TEMP_INSTALL.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
ting, but if errors start to occur again we'll
have some slight notion of where to look.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsq
On 04/27/2017 04:30 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've been trying to track down the cause of recent failures at the "make
>> check" stage on frogmouth, a 32-bit Windows/Mingw instance running on XP.
> I've been wondering about that too.
&
On 04/26/2017 10:32 PM, Peter Eisentraut wrote:
> On 4/23/17 17:09, Andrew Dunstan wrote:
>> Here's a patch that will allow calling vcregress.pl to run a single TAP
>> test set. It would work like this:
>>
>>
>> vcregress.pl src/test/recover true
>&g
On 04/28/2017 08:54 AM, Andrew Dunstan wrote:
>
> On 04/26/2017 10:32 PM, Peter Eisentraut wrote:
>> On 4/23/17 17:09, Andrew Dunstan wrote:
>>> Here's a patch that will allow calling vcregress.pl to run a single TAP
>>> test set. It would work like this:
&g
the regression tests.)
>
>
Yes, me too. We're getting a bit lazy about that - see thread nearby
that will let us avoid unnecessary temp installs among other things.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Dev
tings in production.
Having had years of telling users that CTEs are an optimization fence it
doesn't seem at all nice for us to turn around and change our mind about
that. I have relied on it in the past and I'm sure I'm very far from
alone in that.
Maybe we could allow a "decora
"check"
target which defaults to parallel?
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
On 05/01/2017 10:17 AM, David Fetter wrote:
> On Mon, May 01, 2017 at 09:22:42AM -0400, Andrew Dunstan wrote:
>>> So no more planner-affecting GUCs, please, particularly if we expect
>>> regular users to use them.
>> +1
>>
>> I still see users wanting to us
201 - 300 of 8403 matches
Mail list logo
