header, as I pointed out upthread.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/02/2018 05:20 PM, Andres Freund wrote:
Hi,
On 2018-11-02 17:02:24 -0400, Andrew Dunstan wrote:
On 11/02/2018 11:34 AM, Merlin Moncure wrote:
Binary format consuming applications already have to deal with these
kinds of issues. We already expose internal structures in the other
A violation that should be fixed, IMNSHO.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10/19/2018 10:15 PM, Andres Freund wrote:
Hi,
buildfarm member lorikeet had an interesting buildfarm failure in the
logical decoding test. The failure looks unrelated to logical decoding,
but might be more widely relevant:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&d
in/show_log.pl?nm=lousyjack&dt=2018-11-07%2001%3A33%3A01>
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ou can see this:
SET lc_time TO 'tr_TR';
+ ERROR: invalid value for parameter "lc_time": "tr_TR"
`locale -a | grep tr_TR` on the machine reports:
tr_TR
tr_TR.iso88599
tr_TR.utf8
so I'm not sure what's going on here.
cheers
andrew
--
Andrew Dunsta
first C implementation of initdb. I don't think my opinion has changed
much. We're talking about kilobytes, here, nothing massive.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/7/18 9:30 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/7/18 7:26 AM, Jesper Pedersen wrote:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2018-11-07%2001%3A01%3A01
And lousyjack, which uses a slightly different way of calling valgrind,
and thus got past in
esn't work for the pwrite64(buf) line.
Works for me. If there's no objection I will commit this.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/7/18 9:01 AM, Andrew Dunstan wrote:
Yesterday I did a long overdue upgrade to the machine that runs
buildfarm animal crake. After some hiccups it's all working, except
for the linux utf8 collation tests. See
<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&d
s/tag/REL_9> or
<https://buildfarm.postgresql.org/downloads>
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/17/18 2:46 PM, Andres Freund wrote:
Hi,
On 2018-07-12 11:28:46 -0400, Andrew Dunstan wrote:
On 07/12/2018 10:38 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 07/12/2018 10:20 AM, Tom Lane wrote:
bowerbird and hamerkop have some gripes like this:
bowerbird | c:\perl64\lib\core
d add an option to processSQLNamePattern
to use OR instead of AND, which would fix both this problem as well as
pg_dump's. I don't think that's important enough to stall this patch.
Thanks for the review.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
No such file or directory
2018-11-21 13:02:08.649 EST [11686] CONTEXT: writing block 0 of
relation base/17486/2840_vm
2018-11-21 13:02:08.649 EST [11686] WARNING: could not write block 0 of
base/17486/2840_vm
2018-11-21 13:02:08.649 EST [11686] DETAIL: Multiple failures --- write
error might be permanent.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
care we could do a better job of dumping LOs in a
consistent order.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
(I don't get the order here btw)
ISTM when regrole and regnamespace were added, pg_upgrade wasn't
considered. It turns out that regrole is safe, because we preserve user
oids, but regnamespace isn't afaict. I don't think it's extremely
likely that users store such reg* column
or them to go directly
to latest.
2 seems reasonable. It's perfectly possible for the buildfarm module
that does tests against old version to go back as fas as we like.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/22/18 4:14 PM, Andres Freund wrote:
Hi,
On 2018-11-21 23:32:07 -0500, Andrew Dunstan wrote:
On 11/21/18 7:14 PM, Andres Freund wrote:
Could you check whether you
still encounter the issue after applying the attached fix?
This has largely fixed the problem, so I think this should
oject's inherent conservatism, I don't expect
that to happen for some years yet. In any case, whenever we do pull
that trigger we'd surely do so only in HEAD not released branches, so
buildfarm owners will need to deal with the case for years more.
Right
nothing if
it has an empty set of tests.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
As of now, I have simnply got around the issue in the buildfarm module
by allowing up to 50 lines of fuzz in the pre-upgrade and post-upgrade
diffs when the source and destination branch are the same.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
think you should just proceed with the changes above. I just had a
quick look at the patch you posted before, and it looks sane enough.
I don't see a need to backpatch.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Supp
tand such paths, so before you use such a value in, say, CREATE
TABLESPACE, you need to translate it into a path on the underlying file
system.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/18/18 1:41 PM, Andrew Dunstan wrote:
On 11/17/18 9:55 AM, Alvaro Herrera wrote:
The comment in expand_dbname_patterns is ungrammatical and mentions
"OID" rather than "name", so I suggest
/*
* The loop below might sometimes result in duplicate entries in th
On Tue, Feb 13, 2018 at 6:28 PM, Andrew Dunstan
wrote:
> On Fri, Feb 9, 2018 at 3:54 PM, Andrew Dunstan
> wrote:
>> On Mon, Feb 5, 2018 at 7:49 AM, Andrew Dunstan
>> wrote:
>>> On Mon, Feb 5, 2018 at 7:19 AM, Thomas Munro
>>> wrote:
>>>>
On Sun, Feb 18, 2018 at 2:52 PM, David Rowley
wrote:
> On 17 February 2018 at 10:46, Andrew Dunstan
> wrote:
>> The attached version largely fixes with the performance degradation
>> that Tomas Vondra reported, replacing an O(N^2) piece of code in
>> slot_getmissingat
http://www.publix.com/myaccount/verify?validationCode=889fd4cb-6dbb-4f93-9d4f-c701410cd8a2
On Mon, Feb 19, 2018 at 1:18 PM, David Rowley
wrote:
> On 19 February 2018 at 13:48, Andrew Dunstan
> wrote:
>> On Sun, Feb 18, 2018 at 2:52 PM, David Rowley
>> wrote:
>>>
On Tue, Feb 20, 2018 at 5:03 PM, Andrew Dunstan
wrote:
> http://www.publix.com/myaccount/verify?validationCode=889fd4cb-6dbb-4f93-9d4f-c701410cd8a2
Wow, my c&p was working overtime. Good thing this won't do anyone any good.
cheers
andrew
--
Andrew Dunstan
On Wed, Feb 21, 2018 at 7:48 PM, Andres Freund wrote:
> Hi,
>
[ Long and useful review]
> This doesn't seem ready yet.
>
Thanks.
I'm working through the issues you raised. Will reply in a few days.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQ
On Wed, Feb 28, 2018 at 6:08 AM, Tom Lane wrote:
> I wrote:
> > I had not intended to back-patch, since those changes were just cosmetic,
> > but it might be the best way to preserve the XversionUpgrade tests.
>
> After closer study, it seems like the least painful answer is:
>
> 1. In HEAD, reve
; create_help rule removes the confusion.
>
Very odd. I can't reproduce it on Centos6 with make 3.81.23 and a
downloaded tarball.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
tests all the contrib databases and the isolation
and pl_regression databases. Several bugs have been found that way,
IIRC, and we should arguably do something along the same lines for our
builtin testing.
I'll post a follow up when I've had a chance to have a good look at
what Mich
+my $using_tap_tests = $conf->using_msvc ? $conf->{config}->{tap_tests} :
+ grep {$_ eq '--enable-tap-tests'} @{$conf->{config}} ;
+ return if $using_tap_tests && -d
"$buildroot/$branch/pgsql/src/bin/pg_upgrade/t";
+
# could even set up several of th
appily realign them to the start
of the line regardless of other settings. I see what looks like some
evidence of that here.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Mar 4, 2018 at 2:34 PM, Andrew Dunstan
wrote:
> On Sun, Mar 4, 2018 at 12:42 AM, Peter Eisentraut
> wrote:
>> On 1/26/18 03:00, Michael Paquier wrote:
>>> As promised on a recent thread, here is a second tentative to switch
>>> pg_upgrade's test.sh into
e at quite a large number of columns selected then I think it
might be something we can live with.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
total_relation_size('t') as size_t,
pg_total_relation_size('t_dropped') as size_t_dropped;
size_t | size_t_dropped
--+
4096 | 8192
(1 row)
Why does VACUUM FULL cause the size of this table with a single
dropped column (1 out of 1000) ca
On Sun, Mar 11, 2018 at 9:49 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Why does VACUUM FULL cause the size of this table with a single
>> dropped column (1 out of 1000) cause the table size to double?
>
> VACUUM FULL will rewrite the tuples with a null bitmap where t
On Mon, Mar 12, 2018 at 1:29 AM, David Rowley
wrote:
> On 9 March 2018 at 02:11, David Rowley wrote:
>> On 8 March 2018 at 18:40, Andrew Dunstan
>> wrote:
>>> select * from t;
>>> fastdef tps = 107.145811
>>> master tps = 150.207957
>>>
On Tue, Mar 13, 2018 at 10:58 PM, Andrew Dunstan
wrote:
> On Tue, Mar 13, 2018 at 2:40 PM, Andrew Dunstan
> wrote:
>
>>>
>>> Going by the commitfest app, the patch still does appear to be waiting
>>> on Author. Never-the-less, I've made another pass o
> On Mar 14, 2018, at 10:58 AM, David Rowley
> wrote:
>
> On 14 March 2018 at 11:36, Andrew Dunstan
> wrote:
>> Here are the benchmark results from the v15 patch. Fairly similar to
>> previous results. I'm going to run some profiling again to see if I
>
gt; error information instead of throwing the error. numeric_add() would be a
> wrapper over numeric_add_internal(), which throws an error if corresponding
> data structure is filled. In jsonpath we can call numeric_add_internal()
> and
> interpret errors in another way. That seems to be better than use of PG_TRY
> and PG_CATCH.
>
I haven't seen a response to this email. Do we need one before
proceeding any further with jsonpath?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Mar 20, 2018 at 3:36 PM, Andrew Dunstan
wrote:
> On Fri, Mar 2, 2018 at 8:27 AM, Alexander Korotkov
> wrote:
>> On Fri, Mar 2, 2018 at 12:40 AM, Nikita Glukhov
>> wrote:
>>>
>>> On 28.02.2018 06:55, Robert Haas wrote:
>>>
>>>> On
: 10, _b: 20
DROP PROCEDURE test_proc1;
Same problem in 17devel and 16. (Did not try the older branches yet.)
I can't reproduce this on my Ubuntu 22.04 ARM64 instance with perl
5.38.2 installed via perlbrew, nor on a fresh Debian unstable with it's
perl 5.38.2. In both insta
ed empty string, while an empty string data value is written
with double quotes ("").
CSV format with default settings is and has been from the beginning
designed to be round trippable.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2024-01-17 We 03:52, Laurenz Albe wrote:
On Tue, 2024-01-16 at 11:49 -0500, Andrew Dunstan wrote:
On 2024-01-16 Tu 11:07, Laurenz Albe wrote:
On Tue, 2024-01-09 at 16:51 +, Dean Rasheed wrote:
On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
Getting it print numeric/boolean
-liner
change needed to teach buildfarm animals to ignore READMEs.
- trigger_exclude => qr[^doc/|\.po$],
+ trigger_exclude => qr[^doc/|/README$|\.po$],
I've put that in the sample config file for the next release.
cheers
andre
, but they do care about docs have
sensible structure.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
uldn't be recommending any particular perl distro,
especially not ASPerl which now has annoying license issues.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
e's a consensus that we want this. It should probably
be returned with feedback.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
?
The loss with csv could be blamed on the extra manipulations of the
function pointers, likely.
I don't think that's at all acceptable.
We've spent quite a lot of blood sweat and tears over the years to make
COPY fast, and we should not sacrifice any of that lightly.
cheers
On 2024-01-22 Mo 21:02, Andrew Dunstan wrote:
On 2024-01-22 Mo 18:01, Andrew Dunstan wrote:
On 2024-01-22 Mo 14:16, Andrew Dunstan wrote:
On 2024-01-22 Mo 01:29, Peter Smith wrote:
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there
nfirmation.
Attached merged single patch along these lines.
Thanks, I have pushed this.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
erver. AFAICT
they still only sell versions for x86_64
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
h the buildfarm, you need to let it set
up its own branches.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2024-01-25 Th 14:31, Tom Lane wrote:
Andrew Dunstan writes:
Thanks, I have pushed this.
The buildfarm is pretty widely unhappy, mostly failing on
select jsonb_path_query('1.23', '$.string()');
On a guess, I tried running that under valgrind, and behold it said
==00
On 2024-01-25 Th 14:31, Tom Lane wrote:
Andrew Dunstan writes:
Thanks, I have pushed this.
The buildfarm is pretty widely unhappy, mostly failing on
select jsonb_path_query('1.23', '$.string()');
On a guess, I tried running that under valgrind, and behold it said
==00
On 2024-01-25 Th 15:33, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-01-25 Th 14:31, Tom Lane wrote:
(The reported crashes seem to be happening later during a
recursive invocation, seemingly because JsonbType(jb) is
returning garbage. So there may be another bug after this one.)
I don
On 2024-01-25 Th 15:56, Dave Cramer wrote:
On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan wrote:
On 2024-01-25 Th 08:45, Dave Cramer wrote:
I tried running my buildfarm using my git repo and my branch, but
get the following error
Status Line: 492 bad branch parameter
e also late-model clang.
Anyway, I did note that the preceding line
res = jperOk;
is dead code and might as well get removed while you're at it.
OK, pushed those. Thanks.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
rer and right
click, in the compatibility tab if the "Windows on ARM" is greyed out
it is an arm binary.
So far mine are not :(
Yeah, I think the default Developer Command Prompt for VS2022 is set up
for x86 builds. AIUI you should start by executing "vcvarsall x64_arm64"
On 2024-01-25 Th 20:32, Michael Paquier wrote:
On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan wrote:
On 2024-01-25 Th 16:17, Dave Cramer wrote:
Yeah, I think the default Developer Command Prompt for VS2022 is set up
for x86 builds
27;s still there, given that we disabled external
DTD access ages ago. I propose we just remove it.
In short, I suggest the attached.
Looks reasonable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
is far too narrow and would not cater for many use
cases I have had in the past.
I like your ideas upthread about \file_read and :{filename}
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2024-01-26 Fr 09:18, Dave Cramer wrote:
On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan wrote:
On 2024-01-25 Th 20:32, Michael Paquier wrote:
> On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
wrote:
On 2024-01-26 Fr 09:18, Dave Cramer wrote:
On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan wrote:
On 2024-01-25 Th 20:32, Michael Paquier wrote:
> On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
wrote:
hat at least I think there's close to unanimous agreement.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
ted.
Looks reasonable on the face of it. I'll see about pushing this today.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2024-01-29 Mo 11:20, Dave Cramer wrote:
Dave Cramer
www.postgres.rocks
On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan wrote:
On 2024-01-26 Fr 09:18, Dave Cramer wrote:
On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
wrote:
On 2024-01-25 Th 20:32, Michael Paquier
On 2024-01-30 Tu 09:50, Dave Cramer wrote:
On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan wrote:
On 2024-01-29 Mo 11:20, Dave Cramer wrote:
Dave Cramer
www.postgres.rocks <http://www.postgres.rocks>
On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan
wrote:
On 2024-01-30 Tu 06:49, Andrew Dunstan wrote:
On 2024-01-30 Tu 06:21, Nazir Bilal Yavuz wrote:
Hi,
I was trying to install newer Perl versions to Windows CI images and
found that 003_extrafiles.pl test fails on Windows with:
(0.183s) not ok 2 - file lists match
(0.000s) # Failed test
On 2024-01-30 Tu 18:06, Tom Lane wrote:
Andrew Dunstan writes:
Pushed to all live branches. Thanks for the patch.
v12 and v13 branches aren't looking good:
Global symbol "$test_primary_datadir" requires explicit package name (did you forget to
declare "my $test_pri
On 2024-01-30 Tu 17:54, Dave Cramer wrote:
On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan
wrote:
On 2024-01-30 Tu 09:50, Dave Cramer wrote:
On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan
wrote:
On 2024-01-29 Mo 11:20, Dave Cramer wrote:
Dave Cramer
On 2024-01-31 We 10:34, Peter Eisentraut wrote:
On 31.01.24 16:20, Andrew Dunstan wrote:
- PostgreSQL will only build for the x64 architecture on 64-bit
Windows. + PostgreSQL will only build for the x64 and ARM64
architecture on 64-bit Windows.
Are there any other 64-bit architectures for
::Utils::windows_os" used only once: possible typo at
t/003_extrafiles.pl line 85.
in v14. v15 and up are OK.
*sigh*
Have pushed a fix. Thanks for noticing.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
x27;::text, 'date'::text
from cte
union all
select jsonb_path_query(s, '$.time_tz()')::text,'-8'::text,
'time_tz'::text from cte;
commit;
[0]
https://git.postgresql.org/cgit/postgresql.git/commit/?id=66ea94e8e606529bb334515f388c62314956739e
ouch. Good catch. Clearly we need to filter these like we do for the
.datetime() method.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
Given its nature and purpose as a module we don't want to run against an
installed instance, shouldn't src/test/modules/unsafe_tests have
NO_INSTALLCHECK=1 in its Makefile and runningcheck:false in its meson.build?
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
of this comment could
break the code altogether. (Plenty of programming languages
don't even *have* non-end-of-line comments.)
I suspect not allowing // is at least a minor annoyance to any new
developer we acquire under the age of about 40.
cheers
andrew
pied them into the path from an
msys2 installation.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
+ 01 MAR 2010
(1 row)
SELECT to_char(date '2010-03-01', 'DD TMMON ' COLLATE "de_DE");
to_char
-
- 01 MRZ 2010
+ 01 MAR 2010
(1 row)
-- to_date
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
cp there doesn't seem to be a formal requirement, but there is a
recipe in src/common/unicode/meson.build that uses it, maybe that's what
caused the failure. On Windows/msvc we could just use copy instead, I think.
I haven't experimented with any of this.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
e would answer that,
but would also create an impossible back-patching problem.
Yeah, I agree that's a complete non-starter.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
--no-rebuild -C $pgsql --suite setup --suite regress");
I commented out the 'local %ENV' line and still got the error. I also
got the same error running by hand.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-02-23 Th 16:12, Andrew Dunstan wrote:
On 2023-02-23 Th 10:58, Andres Freund wrote:
On a Windows instance, fairly similar to what's running drongo, I can get a
successful build with meson+VS2019, but I'm getting an error in the
regression tests, which don't like set
he buildfarm, which is how I
discovered this issue.)
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-02-25 Sa 12:13, Andrew Dunstan wrote:
vcregress's installcheck_internal has "--encoding=SQL_ASCII
--no-locale" hardcoded. It's been like that for a long time, for no
good reason that I can see. The practical effect is to make it well
nigh impossible to run th
On 2023-02-26 Su 12:59, Andres Freund wrote:
Hi,
On 2023-02-20 20:47:59 -0500, Andrew Dunstan wrote:
I've noticed that `meson test` logs the complete environment in
meson_logs/testlog.txt. That seems unnecessary and probably undesirable for
the buildfarm client.
It doesn't seem u
7; COLLATE "de_DE");
to_char
-
- 01 MRZ 2010
+ 01 MAR 2010
(1 row)
-- to_date
The last of these is especially an issue, as it doesn't even throw an error.
See
<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2023-02-26%2016%3A56%3A30>
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-02-26 Su 16:02, Andrew Dunstan wrote:
On 2023-01-03 Tu 08:48, Peter Eisentraut wrote:
On 09.12.22 13:48, Juan José Santamaría Flecha wrote:
On Thu, Dec 1, 2022 at 8:46 AM Peter Eisentraut
<mailto:peter.eisentr...@enterprisedb.com>> wrote:
What is the status of thi
od/warnings#Fatal-Warnings>.
Some categories are inherently unsafe to fatalise, as documented in
<https://metacpan.org/pod/strictures#CATEGORY-SELECTIONS>.
Yeah.
It would be nice if there were some fuller explanation of the various
categories, but I don't know of one.
c
On 2023-02-27 Mo 07:33, Andrew Dunstan wrote:
On 2023-02-27 Mo 06:17, Dagfinn Ilmari Mannsåker wrote:
Justin Pryzby writes:
On Sun, Feb 26, 2023 at 03:21:04PM -0800, Andres Freund wrote:
Is there any consideration of promoting these or other warnings to
fatal?
You mean the perl warnings
gured locales. We do it this way so we are not subject to the
vagaries of whatever environment we are running in.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-02-27 Mo 09:34, Andrew Dunstan wrote:
I can't see an obvious way to run the regression tests via meson with
the --no-locale setting. This is particularly important on Windows.
The buildfarm client first runs the regression tests with this setting
and then tests (via install
erstand the point of this test anyway:
SELECT to_char(date '2010-03-01', 'DD TMMON YYYY' COLLATE "de_DE");
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-02-28 Tu 11:40, Juan José Santamaría Flecha wrote:
On Tue, Feb 28, 2023 at 12:55 PM Andrew Dunstan
wrote:
On 2023-02-27 Mo 17:20, Juan José Santamaría Flecha wrote:
Hmm, yeah. I'm not sure I understand the point of this test anyway:
SELECT to_char(date '
On 2023-02-23 Th 10:58, Andres Freund wrote:
On 2023-02-23 06:27:23 -0500, Andrew Dunstan wrote:
On 2023-02-22 We 20:20, Andres Freund wrote:
There is work to do to make sure we pick up the right log files, and maybe
adjust a module or two. I have adopted a design where instead of trying to
version has fixed that, it was a misunderstanding about /
imprecision in the tap 14 specification.
Unfortunately, meson v 1.0.1 appears to be broken on Windows, I had to
downgrade back to 1.0.0.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-03-02 Th 17:06, Andres Freund wrote:
Hi
On 2023-03-02 17:00:47 -0500, Andrew Dunstan wrote:
On 2023-03-01 We 16:32, Andres Freund wrote:
This is now working
on my MSVC test rig (WS2019, VS2019, Strawberry Perl), including TAP tests.
I do get a whole lot of annoying messages like this
allation, which means that
on Linux the corresponding -running tests are failing.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
ients, but we can adjust these patterns if new info emerges.
This is actually moving the inclusion-check goalposts quite far,
but HEAD seems to pass cleanly, and again we can always adjust later.
Any objections?
LGTM
cheers
andrew
--
Andrew Dunstan
EDB:
701 - 800 of 2807 matches
Mail list logo