would be helpful.
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 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 part of make by design.
>> We have PG_PROVE_FLAGS for
On 05/16/2017 10:37 PM, Tom Lane wrote:
> Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
>> On 5/16/17 18:14, pg...@postgresql.org wrote:
>>> Tag refs/tags/REL_10_BETA1 was created.
>> Was this change in naming pattern intentional?
> Yes, it was. A
On 05/16/2017 07:44 PM, Peter Eisentraut wrote:
> On 5/3/17 15:14, Andrew Dunstan wrote:
>> Can someone please explain to me why we have this in Makefile.global.in?
>> (from commit e9c81b60 )
>>
>> PROVE_FLAGS =
>>
>> ISTM it's unnecessary, and prev
ke a poor choice for a globally visible typedef name.
>
>
There is a place in pgindent around line 139 where we filter out
typedefs we don't want. You could add it there of you were so inclined.
I agree this seems like a remarkably bad choice of name.
cheers
andrew
--
esults.
>
> Shouldn't take too long.
>
> No clue if there's some switch that needs to be toggled on the buildfarm
> side to accept the typedefs, I've never looked at that side of things.
prion has done a run. UChar is now in the list.
cheers
andrew
--
Andrew Dunstanht
On 05/14/2017 12:04 AM, Andrew Dunstan wrote:
>
> On 05/13/2017 11:32 PM, Robert Haas wrote:
>> On Sat, May 13, 2017 at 6:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Or at least, that's what I surmise from the fact that buildfarm critter
>>> caiman has bee
cularly good idea.
>
I'd be inclined to set $Data::Dumper::Indent to 0 which would suppress
all indentation, and adjusting the test results accordingly. We already
set $Data::Dumper::Sortkeys to 1, so there's precedent for controlling
how it presents data back to us.
cheers
andrew
t;
> Surely Test::More::is_deeply is the way to go here.
This isn't a TAP test. It's a standard pg_regress test.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mai
On 05/04/2017 12:50 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>> Can someone please explain to me why we have this in Makefile.global.in?
>>> (from commit e9c81b60 )
>>&g
On 05/10/2017 01:53 AM, Andrew Dunstan wrote:
>
>> Does it make a different if you use for example coup_d_grace =>
>> "QUIT"? Per the docs of IPC::Run SIGTERM is used for kills on Windows.
>
> No idea. I'll try.
>
>
>
This isn't going to work. If
On 05/09/2017 09:37 PM, Michael Paquier wrote:
> On Wed, May 10, 2017 at 2:11 AM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com> wrote:
>> (After extensive trial and error) Turns out it's not quite that, it's
>> the kill_kill stuff. I think for now we should just disab
ntion of having vaporware. Say we get a patch and for some reason it
gets rejected. We've had features that took two or three releases to get
accepted. This is why we've historically shied away from roadmaps. And
we've been bitten in the past by deprecating things only to undeprecate
th
On 05/06/2017 08:54 PM, Andrew Dunstan wrote:
>
> On 05/06/2017 07:41 PM, Craig Ringer wrote:
>>
>> On 7 May 2017 4:24 am, "Andrew Dunstan"
>> <andrew.duns...@2ndquadrant.com
>> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>>
>>
On 05/06/2017 07:41 PM, Craig Ringer wrote:
>
>
> On 7 May 2017 4:24 am, "Andrew Dunstan"
> <andrew.duns...@2ndquadrant.com
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
>
> I have been working on enabling the remaining TAP tests on MSVC
&g
eatable on bowerbird, and I'm a bit puzzled about how to
fix it.
Anyone have any clues?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsq
in semantics, which we should definitely
not be getting. Avoiding a change in semantics might be an interesting
exercise, but we have lots of clever coders ...
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & S
On 05/04/2017 01:33 PM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Hadn't though about LATERAL, good point. Still, there will be other cases.
> I'm not sure what your point is. We know that for some cases the
> optimization barrier semantics are useful, which i
On 05/04/2017 12:34 PM, David G. Johnston wrote:
> On Thu, May 4, 2017 at 9:22 AM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com
> <mailto:andrew.duns...@2ndquadrant.com>>wrote:
>
>
> Yeah, the idea that this won't cause possibly significant pain is
>
nt pain is quite wrong.
Quite by accident I came across an example just this morning where rewriting as
a CTE makes a big improvement.
I wrote this query:
select (json_populate_record(null::mytype, myjson)).*
from mytable;
It turned out that this was an order of magnitude faster:
wi
compromise in my opinion unless it
> requires major coding gymnastics to implement.
>
The only thing I am totally dead set against is making people go back to
using OFFSET 0. It's ugly and completely non-intuitive.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
about whether
> you write the USING or ON part first ...
>
>
+1 for allowing arbitrary order of clauses. I would document it with the
USING clause at the end, and have that be what psql supports and pg_dump
produces. Since there are no WITH options now we should leav
On 05/03/2017 03:21 PM, Andres Freund wrote:
> On 2017-05-03 15:14:27 -0400, Andrew Dunstan wrote:
>> Can someone please explain to me why we have this in Makefile.global.in?
>> (from commit e9c81b60 )
>>
>>
>> PROVE_FLAGS =
>>
>>
>> ISTM it
to work the same way.
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:
On 05/03/2017 10:12 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>> On 05/02/2017 10:13 PM, Vaishnavi Prabakaran wrote:
>>> And, now after your patch, do we still need "installcheck-parallel"
>>> command? It is redundan
On 05/02/2017 10:13 PM, Vaishnavi Prabakaran wrote:
>
>
> On Tue, May 2, 2017 at 11:30 PM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
>
> Here's a simple patch that does what I ha
nless we provide both decorator
variants, so people can remediate their code one query at a time, and
this guc would just govern the default.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sen
mple,
>
> WITH [MATERIALIZED]
>
> Pushing people to OFFSET 0 is a giant step backwards IMO, and as in
> implementation detail is also subject to change.
>
>
Agreed, it's an ugly as sin and completely non-obvious hack.
cheers
andrew
--
Andrew Dunstanhttps:/
On 05/01/2017 09:39 AM, Andrew Dunstan wrote:
> The other day I wanted to run "make check" but with the serial schedule.
> This wasn't as easy as it should have been. Although we now have
> installcheck-parallel we don't have check-serial. Should we have that?
> Alternat
On 05/02/2017 12:19 AM, Vaishnavi Prabakaran wrote:
>
>
>
> On Mon, May 1, 2017 at 11:01 PM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
>
>
> In the absence of further comments I'm going to ap
On 05/01/2017 03:00 PM, Mikael Kjellström wrote:
>
> On 2017-05-01 20:56, Andrew Dunstan wrote:
>> OK, coming up with a more comprehensive fix.
>
> Ok.
>
>> The obvious workaround for now is to create the directory and dont zap
>> it or its parents. You should on
to write
> to it.
>
OK, coming up with a more comprehensive fix.
The obvious workaround for now is to create the directory and dont zap
it or its parents. You should only have to do it once (per branch)
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Dev
On 05/01/2017 02:13 PM, Mikael Kjellström wrote:
> On 2017-04-19 15:59, Andrew Dunstan wrote:
>
>
>> I have released version 4.19 of the PostgreSQL Buildfarm client. It can
>> be downloaded from
>> <https://buildfarm.postgresql.org/downloads/releases/build-farm
On 05/01/2017 02:13 PM, Mikael Kjellström wrote:
> On 2017-04-19 15:59, Andrew Dunstan wrote:
>
>
>> I have released version 4.19 of the PostgreSQL Buildfarm client. It can
>> be downloaded from
>> <https://buildfarm.postgresql.org/downloads/releases/build-farm
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
k"
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 changes to
ad 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 "decorator" that would tell the plan
ed up 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
PostgreSQ
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:
>>
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
>
On 04/27/2017 04:30 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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.
>
ccur 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 (pgsql-hackers@postgresql.org)
To
rib
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 & Services
--
On 04/25/2017 10:45 AM, Robert Haas wrote:
> On Sun, Apr 23, 2017 at 10:57 PM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com> wrote:
>> On 04/23/2017 10:33 PM, Tom Lane wrote:
>>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>>>
On 04/23/2017 10:33 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 tha
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.2ndQuadrant.com
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
PostgreSQL
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
>
tra 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 via p
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.2ndQuadrant.com
Postgr
On 04/21/2017 09:22 PM, Craig Ringer wrote:
>
>
> On 22 Apr. 2017 4:23 am, "Tom Lane" <t...@sss.pgh.pa.us
> <mailto:t...@sss.pgh.pa.us>> wrote:
>
> Peter Eisentraut <peter.eisentr...@2ndquadrant.com
> <mailto:peter.eisentr...@2ndquadra
On 04/21/2017 10:45 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 ve
On 04/21/2017 10:36 AM, Daniel Gustafsson wrote:
>> On 21 Apr 2017, at 15:08, Andrew Dunstan <andrew.duns...@2ndquadrant.com>
>> wrote:
>>
>> As we discovered yesterday via jacana, very old versions of Test::More
>> don't support the note() function. I
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.pl
i
On 04/19/2017 01:38 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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_
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
>
> regards, tom lane
>
>
--
Andrew D
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 Dunstanhttps://www.2ndQuadran
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 wal_*_timeout etc
On 04/18/2017 08:23 AM, Michael Paquier wrote:
> On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com> wrote:
>> Yeah, but the way you have done it could also to lead to errors unless
>> you're very careful, as I found on axol
d 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@postgresql.org
o understand 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
--
e 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
--
Andrew Dunstan
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
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 for initd
On 04/15/2017 02:13 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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 t
On 04/15/2017 12:13 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
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 something
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
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
f select_default_timezone,
and have the buildfarm set TZ to something if it's not already set.
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
quot;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 mailing
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:
>>
>
&
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/11/2017 08:12 PM, Craig Ringer wrote:
>
>
> On 12 Apr. 2017 03:14, "Andrew Dunstan"
> <andrew.duns...@2ndquadrant.com
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
>
>
> On 04/11/2017 12:08 PM, Tom Lane wrote:
> > Ro
On 04/11/2017 03:58 PM, Andres Freund wrote:
> On 2017-04-11 15:52:34 -0400, Tom Lane wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>>> The other thing that might be useful here is to push on parallelizing
>>>> buildfarm runs.
>>
On 04/11/2017 12:08 PM, Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan
>> <andrew.duns...@2ndquadrant.com> wrote:
>>> This buildfarm run as you can see takes 33m32s, and the Tap tests take a
&g
: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.2ndQuadrant.com
7nPqTUOpF792rDOnBkswZ=zghwxdb01oqu2taf1ku4iuu...@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 Dunstan
On 04/08/2017 02:49 PM, Andrew Dunstan wrote:
>
> On 04/08/2017 12:11 PM, Tom Lane wrote:
>> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>>>> I think it's partially knowing which target failed, and which
>>>> regression.diffs to display.
On 04/08/2017 12:11 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> 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
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
;
> 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
--
Andrew Dunstanhttps://www
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, 24x7 Support, Remo
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
> the s
ke 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
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
e 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 we need agreement on a desi
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
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/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 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.
>
> N
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 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
> <andrew.duns...@2ndquadrant.com
>
On 29 March 2017 at 16:19, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On 29 March 2017 at 18:28, Andrew Dunstan <andrew.duns...@2ndquadrant.com>
>> wrote:
>>
>> These patches seem fundamentally OK. But I'm still not happy with the
>> naming etc
ce.
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
PostgreSQL Development, 24x7 Su
On 03/28/2017 07:31 AM, Dagfinn Ilmari Mannsåker wrote:
> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
>
>> I would try something like this:
>>
>> @opts = grep { $_ !~ /\$\(/ && $_ =~ /^--/ }
>> map { s/\Q$(top_builddir
of this lexical $x variable seems entirely pointless and
obfuscatory. If perlcritic doesn't like it without then that's another
black mark against it IMNSHO.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & S
something like this:
@opts = grep { $_ !~ /\$\(/ && $_ =~ /^--/ }
map { s/\Q$(top_builddir)\E/\"$topdir\"/; }
split(/\s+/, $1);
but I don't have time to test it before I leave for pgconfUS.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQ
On 03/21/2017 06:28 PM, Dmitry Dolgov wrote:
> > On 21 March 2017 at 03:03, Andrew Dunstan
> <andrew.duns...@2ndquadrant.com
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
> >
> > However, I think it should probably be broken up into a couple of
> piec
t silly to feel like we need it for
> pg_dump's regression coverage.
>
> That said, perhaps the right answer is to have a couple tests for both
> the backend and for pg_dump which do exercise the fsync-enabled paths.
>
>
+1
cheers
andrew
--
Andrew Dunstanhttps
101 - 200 of 8267 matches
Mail list logo
