On 9/9/19 11:07 AM, gc...@sina.cn wrote:
> Hi,I just want know does PostgreSQL support debian Linux with ARM CPU
> Platform,Thank you!
See
<https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=mereswine&br=HEAD>
cheers
andrew
--
Andrew Dunstan
we decide to kick that to the curb, I'd either shut
> down the box or put some newer Linux or BSD variant on it.
>
>
Well, nightjar is on FBSD 9.0 which is oldish. I can replace it before
long with an 11-stable instance if that's appropriate.
cheers
- run TAP tests for contrib modules that have them
. explicitly use "trust" with initdb
Download from
<https://github.com/PGBuildFarm/client-code/archive/REL_11.tar.gz> or
<https://buildfarm.postgresql.org/downloads/latest-client.tgz>
Enjoy
cheers
andrew
--
Andrew D
prefix': 'C:\\Python37', 'exec_prefix': 'C:\\Python37',
'SO': '.cp37-win_amd64.pyd', 'srcdir': 'C:\\Python37'}
The python3.dll and python37.dll files are in c:\\python37, i.e. the
BINDIR as one might expect on Windows.
It would be nice to get this working.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
if
possible.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
where
as time goes on, so this would stand us in good stead if we do.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/configure b/configure
index b3c92764be..57d634d501 100755
--
de. Removes ~200 unnecessary memsets.
>> More consistent initialisation.
>>
> +1. This seems like an improvement. I can review and take this
> forward unless there are objections from others.
>
>
+1.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
not consistent (REL_!2_STABLE is currently green).
The interval test itself hasn't changed for m ore than 2 years, and I
haven't found any obvious recent change that might cause the problem. I
guess it could be a comoiler bug ... this is gcc 9.2.0, which is the
current release.
cheers
go running
on the same machine is not exhibiting these problems. Yes, it's not
running test.sh, but vcregress.pl does pretty much the same thing. So
that does seem to point to the toolset. I'll see if I can get the same
toolset jacana is using installed and try that.
cheers
andrew
-
07910968). The makefile
now assumes that zic has this switch. But I was attempting to get around
an issue on msys2 by using its zic, (ZIC=/usr/bin/zic configure ...). It
crashes on the floor because it doesn't know about "-b slim". I think we
probably need a way to turn this
On 10/5/19 6:33 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I've just run into an issue with this (commit a1207910968). The makefile
>> now assumes that zic has this switch. But I was attempting to get around
>> an issue on msys2 by using its zic, (ZIC=/usr/
On 10/5/19 10:33 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/5/19 6:33 PM, Tom Lane wrote:
>>> I had contemplated injecting the -b switch via
>>> -ZIC_OPTIONS =
>>> +ZIC_OPTIONS = -b slim
>> I don't think that's going to work ve
only $Config{ccflags}, but it seems that
> $Config{cccdlflags} is also required. The attached patch make
> ./configure success. (configure itself is excluded in the patch.)
>
./configure --with-perl
is working for me on Centos8 (double checked after a `dnf update`)
cheers
andrew
--
gt; to do that right this minute, though.
>
> A nearer-term solution would be to reproduce this manually and
> dig into the core. Mark, are you in a position to give somebody
> ssh access to wobbegong's host, or another similarly-configured VM?
I have given Mark my SSH key. That
On 10/10/19 6:01 PM, Andrew Dunstan wrote:
> On 10/10/19 5:34 PM, Tom Lane wrote:
>> I wrote:
>>>>> Yeah, I've been wondering whether pg_ctl could fork off a subprocess
>>>>> that would fork the postmaster, wait for the postmaster to exit, and then
&
On 10/11/19 11:45 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>>> At least on F29 I have set /proc/sys/kernel/core_pattern and it works.
> FWIW, I'm not excited about that as a permanent solution. It requires
> root privilege, and it affects the whole machine not on
to connect as both bar and baz,
and give both bar and baz a certificate with a CN of foo. But then bar
can connect as baz and vice versa, which isn't a good thing.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Oct 12, 2019 at 3:56 PM Peter Eisentraut
wrote:
>
> On 2019-10-03 16:21, Andrew Dunstan wrote:
> > My new msys2 animal fairywren
>
> Could you please check how this animal is labeled? AFAICT, this is not
> an msys2 build but a mingw build (x86_64-w64-mingw32).
>
> By the way, is there any official way to specify options like -O0
> while configure time?
>
CFLAGS=-O0 configure --with-perl ...
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Oct 16, 2019 at 8:32 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > On Tue, Oct 15, 2019 at 6:45 AM Kyotaro Horiguchi
> > wrote:
> >> The problematic command line boils down to:
> >> $ ./configure --with-perl CFLAGS=-O0
> >> It is bash-a
e new syntax to make upgrading easier.
>>
>> +1
>>
>
> +0.5
>
> In general, I'm not opposed to accepting and ignoring the MATERIALIZED
> syntax (assuming we'd only accept AS MATERIALIZED, but not the negative
> variant).
>
> FWIW I'm no
hat policy that
is in large measure responsible for Postgres' deserved reputation for
stability.
Incidentally, why is your function written in plpgsql? Wouldn't a simple
SQL wrapper be better?
create or replace function safe_jsonb_set
(target jsonb, path text[], new_value jsonb, create_missing
boolean default true)
returns jsonb as
$func$
select case when new_value is null then target else
jsonb_set(target, path, new_value, create_missing) end
$func$ language sql;
And if we were to change it I'm not at all sure that we should do it the
way that's suggested here, which strikes me as no more intuitive than
the current behaviour. Rather I think we should possibly fill in a json
null in the indicated place.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10/19/19 11:10 AM, Isaac Morland wrote:
> On Sat, 19 Oct 2019 at 10:53, Andrew Dunstan
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
>
> > In general, I'm not opposed to accepting and ignoring the
> MATERIALIZED
> > syntax (assuming
#x27;s proto.h but didn't see any obvious candidate. I
tried a couple of others (e.g. Perl_get_context) and got the same result
reported above.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10/19/19 12:18 PM, Tomas Vondra wrote:
> On Sat, Oct 19, 2019 at 11:26:50AM -0400, Andrew Dunstan wrote:
>
> Not sure, but that seems rather confusing to me, because it's mixing SQL
> NULL and JSON null, i.e. it's not clear to me why
>
> jsonb_set(..., ".
able argument in the first
> place, and can reasonably safely and effectively prevent it going
> forward. Then people will have to explicitly code what they want to
> do if their data and queries present this invalid unknown data to the
> function.
>
>
How exactly do we prevent a NULL being passed as an argument? The only
thing we could do would be to raise an exception, I think. That seems
like a fairly ugly thing to do, I'd need a h3eck of a lot of convincing.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
meter. Possibly we could even add an extra
parameter to specify what should be done.
Also, the question will arise what to do when any of the other
parameters are NULL. Should we return NULL in those cases as we do now?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.
On 10/20/19 1:23 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/18/19 9:50 AM, Tom Lane wrote:
>>> Can we fix this by using something other than perl_alloc() as
>>> the tested-for function? That is surely a pretty arbitrary
>>> choice. Are there any
On 10/20/19 1:14 PM, David G. Johnston wrote:
> On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
> And yet another is to
> raise an exception, which is easy to write but really punts the issue
> back to the
On 10/20/19 4:18 PM, Tomas Vondra wrote:
> On Sun, Oct 20, 2019 at 03:48:05PM -0400, Andrew Dunstan wrote:
>>
>> On 10/20/19 1:14 PM, David G. Johnston wrote:
>>> On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan
>>> >> <mailto:andrew.duns...@2ndquadrant.c
On 10/20/19 7:36 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/20/19 1:23 PM, Tom Lane wrote:
>>> The right way to fix it, likely, is to add CFLAGS_SL while performing this
>>> particular autoconf test, as that would replicate the switches used for
>&g
On 10/21/19 2:07 AM, Tomas Vondra wrote:
> On Sun, Oct 20, 2019 at 06:51:05PM -0400, Andrew Dunstan wrote:
>>
>>> I think the general premise of this thread is that the application
>>> developer does not realize that may be necessary, because it's a bit
>>&g
n occasional
similar failures on other tests in Windows so a more systemic approach
might be better.
Thoughts?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10/21/19 2:58 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Bowerbird (Visual Studio 2017 / Windows 10 pro) just had a failure on
>> the pg_ctl test :
>> <https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-10-21%2011%3A50%3A21>
>>
ed json{b}. Not sure if they would work for your purpose. I hadn't
considered something to let you transform keys.
PLV8 is useful for doing more outlandish JSON transformations. Maybe the
Underscore library has something that would be useful here.
cheers
andrew
--
Andrew Dunstan
On 10/25/19 3:09 PM, Peter Eisentraut wrote:
> On 2019-10-16 13:34, Andrew Dunstan wrote:
>>> Could you please check how this animal is labeled? AFAICT, this is not
>>> an msys2 build but a mingw build (x86_64-w64-mingw32).
>> It is indeed an msys2 system. However, w
L;
}
Why not something like:
if (GetLastError() == ERROR_FILE_NOT_FOUND)
errno = 0;
else
_dosmaperr(GetLastError());
return NULL;
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
trouble
>> maker...
> My proposal would be that we make both options available as both
> reloptions and vacuum options.
+many
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
r sure.
>
>
You could allow an explicitly set command option to override the reloption.
It's important for us to be able to control the vacuum phases more. In
particular, the index cleanup phase can have significant system impact
but often doesn't need to be done
it:
3. The right way to detect attacks is through OS-level monitoring or
firewall-level monitoring, and nothing we do in PG is going to come
close to the same value.
So I propose shortly to commit this patch unconditionally demoting the
message to DEBUG1.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/1/19 6:49 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> So I propose shortly to commit this patch unconditionally demoting the
>> message to DEBUG1.
> No patch referenced, but I assume you mean only for the
> zero-bytes-received case, right
erics don't support NaN, Infinity etc., so I assume
this can only happen in a jsonpath expression being converted to a jsonb
value. If so, the new section should contain a comment to that effect,
otherwise it will be quite confusing.
cheers
andrew
--
Andrew Dunstanhtt
On 3/3/19 3:52 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan writes:
>>> Patch proposed by Christoph Berg is here:
>>> https://www.postgresql.org/message-id/20190228151336.GB7550%40msg.df7cb.de
>> Meh. That doesn't silence only the zero-bytes case, and
t;(5,1),3> | 1.47213595499958
| <(100,200),10> | <(100,1),115> | 74
| <(100,200),10> | <(1,2),100> | 111.370729772479
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
seems perfectly reasonable, and has plenty of
support. I'm going to commit it shortly unless there are last minute
objections.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
after setting table level option, one can compress such tuples.
>
> The attached patch implements this idea.
>
This is a nice idea, and I'm a bit surprised it hasn't got more
attention. The patch itself seems very simple and straightforward,
although it could probably do with h
On 3/4/19 7:42 AM, Christoph Berg wrote:
> Re: Andrew Dunstan 2019-03-04
> <7cc6d2c1-bd87-9890-259d-36739c247...@2ndquadrant.com>
>> Looks good to me.
> +1.
>
OK, I think we have agreement on Tom's patch. Do we want to backpatch
it? It's a change in behavi
) recommend that it be rejected.
>
> If no committer steps up in the next week I think we should mark it as
> rejected.
>
>
Having reviewed the thread, I'm with Andres and Tom. Maybe though we
should have a note somewhere to the effect that you can't use VARIADIC
with the
in all cases.
>
So you want two options, like wal_recycle_files and wal_zero_fill, both
defaulting to true? Is there a reasonably use case for turning one off
without the other?
Alternatively, we could remove the 'for example" wording, which I agree
is unfortunate.
cheers
On 3/6/19 11:30 AM, Robert Haas wrote:
> On Wed, Mar 6, 2019 at 10:55 AM Andrew Dunstan
> wrote:
>>> I *really* dislike this. For one thing, it means that users don't
>>> have control over the behaviors individually. For another, the
>>> documentation
w risk.
I haven't looked at the others in detail, but I think at least some part
of this is reasonably committable.
I'll try to look at the others fairly shortly.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/6/19 1:38 PM, Jeremy Schneider wrote:
> On 3/5/19 14:14, Andrew Dunstan wrote:
>> This patch is tiny, seems perfectly reasonable, and has plenty of
>> support. I'm going to commit it shortly unless there are last minute
>> objections.
> +1
>
done.
che
On 3/6/19 12:12 PM, Robert Haas wrote:
> On Tue, Mar 5, 2019 at 5:35 PM Andrew Dunstan
> wrote:
>> OK, I think we have agreement on Tom's patch. Do we want to backpatch
>> it? It's a change in behaviour, but I find it hard to believe anyone
>> relies on the ex
bug that was preventing the module from
picking up its log files. The latest report has them all.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
but you get the idea why this pragma can accur just
about anywhere.) There is also 'pragma Assert' which is more or less
like our Assert in C.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
the patch is that the only
testing it does it to make sure that pragmas are ignored by the core
plpgsql processor. Maybe that's enough, but mostly we tend to like to
have one actual use of a feature.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/7/19 12:41 PM, Pavel Stehule wrote:
>
>
> čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan
> <mailto:andrew.duns...@2ndquadrant.com>> napsal:
>
>
>
>
> The other thing that bugs me a bit about the patch is that the only
> testing it does it t
d
apply this and remove the (confusing) message setting for the case we'll
now be avoiding. If not we should at least comment there that this is a
case we only expect to see in pathological cases.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-tune the hit/miss/dirty scores so that they're some larger factor
> apart from each other the standard scores are. The 10,000 limit does
> not allow much wiggle room for that.
>
Increase it to what?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
nging how it all works in PG13. If nothing happens before this
> time next year then we can consider making vacuum_cost_delay a
> microseconds GUC.
>
+1.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3/9/19 12:55 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/9/19 4:28 AM, David Rowley wrote:
>>> I agree that vacuum_cost_delay might not be granular enough, however.
>>> If we're going to change the vacuum_cost_delay into microseconds, then
>&
c_fname_ext() not just fsync() failures;
>> that's painting with too broad a brush isn't it?
> That indeed seems wrong. Thomas? I'm not quite sure how to best fix
> this though - I guess we could rename fsync_fname_ext's eleval parameter
> to fsync_failure_elevel? It's not visible outside fd.c, so that'd not be
> to bad?
>
Thread seems to have gone quiet ...
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
he patch, attached.
>> Setting back to NR.
> The patch looks good to me. I'm happy for it to be marked as ready for
> committer. Fabien, do you want to have another look?
>
I think we've spent enough time on this. Committed with minor changes.
cheers
andrew
--
Andrew
On 3/6/19 10:24 AM, Chapman Flack wrote:
> On 3/6/19 10:12 AM, Andrew Dunstan wrote:
>
>> Having reviewed the thread, I'm with Andres and Tom. Maybe though we
>> should have a note somewhere to the effect that you can't use VARIADIC
>> with these.
> Perhaps
On 3/11/19 1:04 PM, Dagfinn Ilmari Mannsåker wrote:
> Andrew Dunstan writes:
>
>> I think we've spent enough time on this. Committed with minor changes.
> Thanks for committing it. However, I can't see it in git. Did you forget
> to push?
>
>
Ooops
On 3/11/19 6:07 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I'm going to mark this as rejected. Here's a possible doc patch
> Maybe s/strictly/ordinary/, or some other word? "strictly"
> doesn't convey much to me. Otherwise seems fine.
OK, don
;1234567890',30));
>>
>> Without this patch, the second INSERT will not compress the tuple since its
>> length is less than the toast threshold. With the patch and after setting
>> table level option, one can compress such tuples.
>>
>> The attached p
result = arg1;/* Handle 0 and -0 explicitly */
> else
> result = asinh(arg1);
>
> Aside from being ugly, this'd mean that our regression tests weren't
> really exercising the library asinh function at all.
Or we could possibly call the function and t
he mingw math library. I think jacana is the
only currently reporting mingw member :-( The MSVC members appear to be
happy.
I have several releases of the mingw64 toolsets installed on jacana -
I'll try an earlier version to see if it makes a difference.
cheers
andrew
--
Andrew Dunstan
On 3/14/19 3:08 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/14/19 12:41 AM, Tom Lane wrote:
>>> So far, no other failures ...
>> I have replicated this on my Msys2 test system.
>> I assume it's a bug in the mingw math library. I think jacana is th
>
> BTW, it appears that windows build scripts also needs some fixup. I'm
> not very familiar with that. I would be glad if somebody review the
> attached patch.
Why are we installing the jsonpath_gram.h file? It's not going to be
used by anything else, is it? TBH, I'
019 is currently in preview. I think we'd probably be better off
waiting until the full release. I don't know of any pressing urgency for
us to support it.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I
On 3/25/19 3:44 PM, Andrew Dunstan wrote:
> On 3/21/19 3:13 AM, Michael Paquier wrote:
>> On Thu, Mar 21, 2019 at 12:45:57PM +1100, Haribabu Kommi wrote:
>>> The commit f2ab389 is later back-patch to version till 9.3 in commit
>>> 19acfd65. I guess that building th
gt; I can provide a separate back branches patch later once this patch
> comes to a stage of commit. Currently all the supported branches are
> possible to compile with VS 2017.
>
> comments?
>
>
I have verified that this works with VS2019.
There are a few typos in the co
, all the URLs in
> win32_port.h (except the wine one) are dead.
>
That's a fairly awful URL. How stable is it likely to be?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
so, then if it happens
> again we'd have more info.
>
>
I was able to get this stack trace.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
[Switching to
On 3/28/19 1:01 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I was able to get this stack trace.
>>
>> (gdb) bt
>> #0 0x7ffb9ce6a458 in ntdll!RtlRaiseStatus ()
>>from C:\WINDOWS\SYSTEM32\ntdll.dll
>> #1 0x7ffb9ce7760e in ntdll!memset () f
On 3/28/19 5:38 AM, Alexander Korotkov wrote:
> On Thu, Mar 28, 2019 at 5:55 AM Andrew Dunstan
> wrote:
>> On 3/27/19 9:48 AM, Tom Lane wrote:
>>> Alexander Korotkov writes:
>>>> Still no reproduction.
>>> Annoying, but it's probably not worth ex
tatements in the same session?
>
I mean repeated invocations of
psql -c "select '$ ? (@ like_regex \"pattern\" flag \"a\")'::jsonpath"
These get crash, no crash, crash, no crash ...
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ssingly high chance that this is somehow specific
> to the bison version, flex version, and/or compiler in use on jacana.
>
>
lousyjack has also passed it (x64).
git bisect on jacana blames commit 550b9d26f.
cheers
andrew
--
Andrew Dunstan
he relfroxzenxid in relcache
has been updated. If that happens this vacuum is redundant, so skip it.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Or perhaps better, allow pg_ctl to grow new
> subcommands for those tasks?
>
>
I think that's a better direction. psql is already pretty cumbersome.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
opinions?
> Andrew perhaps?
>
>
It's really just a matter of housekeeping as I see it, so probably
DEBUG1 is right.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgrade location. The risk seems appropriately low and it only
affects our test regime.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upg
o drop the updated file in place, get it from
<https://raw.githubusercontent.com/PGBuildFarm/client-code/51889e9dd86dd10f7b9444cb62eebb7f8baa989e/PGBuild/Modules/TestUpgrade.pm>
There will be a buildfarm release out very soon that includes this.
cheers
andrew
--
Andrew Dunstan
n commit ad69bd0, was to facilitate pg_upgrade
> testing. Folks using "make installcheck-world" to populate a cluster for
> pg_upgrade testing will see additional test coverage, which may cause
> additional failures. I'm fine with that, too.
Excellent. Extending use of USE_MODULE_DB has been on my list of
things to do. I'll add the buildfarm patch right away. It should be
harmless before these changes are made.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
iple places in the buildfarm client that
> have hard-wired references to "buildfarm".
This goes back quite a way:
commit 7528701abb88ab84f6775448c59b392ca7f33a07
Author: Andrew Dunstan
Date: Tue Nov 27 13:47:38 2012 -0500
Run everything as buildfarm ra
there
are a couple of not very widely used modules that need similar treatment
- TestSepgsql and TesUpgradeXVersion
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
d.
>
> regards, tom lane
>
> [1]
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur&dt=2019-07-22%2017%3A08%3A27
>
There's a strong tendency these days to be secure by default, so I
understand the motivation.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
and in the path on Windows. The Windows equivalent would be something like:
\setshell two\
@set /a c = 1 + :one && echo %c%
I propose to prepare a patch along these lines. Alternatively we could
just drop it - I don't think the test matters all that hugely.
cheers
es, it's built into the cmd processor (as is "set /a", to answer Tom's
earlier question about portability - I tested the above back to XP.)
echo is much more universal, and I can confirm that the suggested fix
works on the Windows test box I'm using.
I'll apply and backpatch
On 7/22/19 1:40 PM, Andres Freund wrote:
> Hi,
>
> On 2019-07-22 13:02:13 -0400, Andrew Dunstan wrote:
>> There are a few things we could do. We could force trust auth, or we
>> could add an ident map that allowed $USER to login as buildfarm. Finding
>> all the place
On 7/23/19 2:12 AM, Peter Eisentraut wrote:
> On 2019-07-22 21:16, Andrew Dunstan wrote:
>> Modulo this issue, experimentation shows that adding '-A trust' to the
>> line in run_build.pl where initdb is called fixes the issue. If we're
>> going to rely on a
en using the
> command prompt for native tools. So using it sounds like a good idea
> to me if it exists.
Yeah, on consideration I think Peifeng's patch upthread looks OK.
(Incidentally, this variable is not set in the very old version of VC
running on currawong).
cheers
andrew
--
On 7/24/19 10:00 AM, Andrew Dunstan wrote:
> On 7/23/19 2:12 AM, Peter Eisentraut wrote:
>> On 2019-07-22 21:16, Andrew Dunstan wrote:
>>> Modulo this issue, experimentation shows that adding '-A trust' to the
>>> line in run_build.pl where initdb is called f
es (say to 78 chars -- make sure pgperltidy
> agrees), and keep some spaces after sentence-ending periods and other
> punctuation.
>
I've fixed the bitrot and some other infelicities on this patch. It's
not commitable yet but I think it's more reviewable.
cheers
andrew
--
ht
> incompatibilities or extensions.
My instict wouyld be to move as close as possible to the standard,
especially if the current behaviour isn't documented.
>
> We should collect a list of test cases that illustrate the differences
> and then work out how to deal with them.
>
Agreed.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
l seconds, 1 digit" etc. or something like that.
> And what about "tenths of seconds", "hundredths of seconds"?
Yes, those are much better.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
am leaning towards that being
> the most reasonable choice.
>
+1 for #4.
I'll be happy to participate in any effort.
About 22 years ago I wrote a pure perl implementation of a wire protocol
of roughly similar complexity (RFC1459). I got it basically working in
just a few days, so this sort of thing is very doable. Let's see your
skeleton and maybe it's a good starting point.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 7/27/19 6:37 PM, Andres Freund wrote:
> Hi,
>
> On 2019-07-27 17:48:39 -0400, Andrew Dunstan wrote:
>> On 7/27/19 3:15 PM, Andres Freund wrote:
>>> I'm not volunteering to do 4), my perl skills aren't great (if the test
>>> infra were python, otoh..
401 - 500 of 2809 matches
Mail list logo
