and I could not find in e.g. 12's
documentation any references to the cases you listed previously:
> dist_lb: <->(line,box)
> dist_bl: <->(box,line)
> close_sl: lseg ## line
> close_lb: line ## box
> poly_distance: polygon <-> polygon
> path_center
y probable upcoming move to meson, but until
then this little patch really helps me whenever I have to deal with
Windows and MSVC from the command line. Besides, it could help old
branches as well.
--
Anton Voloshin
https://postgrespro.ru
Postgres Professional, The Russian Postgres Companydiff --
tions if they are distinct from the language's
* base collation. So there might not be a de-DE or en-GB, which
would be
...
(please see the attached patch).
--
Anton Voloshin
Postgres Professional: https://www.postgrespro.com
Russian Postgres Company
diff --git a/src/backen
this should not be repalloc()?
In case it should be, I've attached a corresponding patch.
--
Anton Voloshin
Postgres Professional: https://www.postgrespro.com
Russian Postgres Company
diff --git a/src/backend/utils/adt/formatting.c
b/src/backend/utils/adt/formatting.c
index 783c7b5e7a..40906
On 04.04.2021 19:20, Tom Lane wrote:
repalloc is likely to be more expensive, since it implies copying
data which isn't helpful here. I think this code is fine as-is.
Oh, you are right, thanks. I did not think properly about copying in
repalloc.
--
Anton Voloshin
Postgres Profess
for that:
void
-SHA256_Final(uint8 digest[], SHA256_CTX *context)
+SHA256_Final(uint8 digest[SHA256_DIGEST_LENGTH], SHA256_CTX *context)
{
etc.
Please consider fixing those warnings.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
diff --git a/co
es where it exists if
there is an issue with it impacting pgcrypto without OpenSSL.
Perhaps that would be a good idea, see above.
--
Anton Voloshin
https://postgrespro.ru
Postgres Professional, The Russian Postgres Company
r-xl_tot_len-zero-test-accept-invalid.patch
I think it makes sense to backport whatever the final change would be to
all branches with 039_end_of_wal (REL_12+).
Any thoughts?
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ruFrom 5f12139816f6c1bc7d625ba8007a
more "xl_tot_len zero" failures with that addition.
I like this solution the best.
Tolerating the two different messages would weaken the test.
I agree, I also don't really like this option.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
: REL_14_STABLE and above.
Both lines come from the same commit:
> commit 6df7a9698bb036610c1e8c6d375e1be38cb26d5f
> Author: Alexander Korotkov
> Date: Sun Dec 20 07:20:33 2020
>
> Multirange datatypes
No harm from this duplication, still, I suggest to clean it up for
tidiness' sake.
in the previous letter.
Additional patch attached. Or both could go in the same commit, it's up
to committer.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ruFrom 05c9979de0596f9bbe89304f54e20b759205b57b Mon Sep 17 00:00:00 2001
From: Anton Vol
intentional or not. Hopefully, they are
harmless or intentional.
All other duplicated lines I've analyzed seem to be intentional.
Granted, I've mostly ignored lines without ';', also I could have missed
something, but currently I'm not aware of any other unintentionally
ve output.
I think in this case "IN" is better, because that allows a single
comment to address both possible outputs and to avoid unnecessary
duplication.
I've attached a patch authored mostly by my colleague, Roman Zharkov, as
one possible fix.
Only versions 15+ are affecte
econd(object))
{
I've verified that all other current branches, i.e.
REL9_6_STABLE..REL_13_STABLE (excluding REL_10_STABLE) and master can
compile cleanly even with bare ./configure without arguments using gcc-11.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Compan
$minorver = sprintf("%d", $2 ? $2 : 0);
I think this should be backported to REL_13_STABLE, but not to
REL_12_STABLE and earlier, where strver was still present.
--
Anton Voloshin,
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
diff --git a/sr
ale() means
write_message argument is false, so no error message is ever printed.
I propose an obvious patch (see attachment).
Introduced in aa17c06fb in January 2017 when debug was replaced by
false, so I guess back-patching through 10 would be appropriate.
--
Anton Voloshin
Postgres Professio
9-09 22:04:01.686 +07 [482312] WARNING: could not determine
encoding for locale "tg_TJ": codeset is "KOI8-T"
2021-09-09 22:04:01.686 +07 [482312] WARNING: could not determine
encoding for locale "th_TH": codeset is "TIS-620"
ok
While they are definite
e how adding debug-level messages
about skipping frontend-only encodings would be of any significant use here.
Unless someone more experienced in locales' subtleties would like to
chime in.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
s patch is intentional?
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ruFrom a50e58f117341e8a9df5f97fa05630f7b8f4bd86 Mon Sep 17 00:00:00 2001
From: Anton Voloshin
Date: Tue, 16 Apr 2024 17:19:28 +0300
Subject: [PATCH] Update src/tools/pginclude/README to match recent changes to
out strtod etc, but about floating-point numbers in the
source code.
P.S. $ perl --version
This is perl 5, version 38, subversion 2 (v5.38.2) built for
x86_64-linux-gnu-thread-multi
(with 44 registered patches, see perl -V for more detail)
P.P.S. I'm replying to pgsql-hackers, even thou
gt; Particularly in
> this way --- what are we supposed to do, write "if (0 < 0,5)"?
> That means something else.
Yep. I will try to report this to Perl community later.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ruFrom bc187cd95
On 26/04/2024 17:38, Anton Voloshin wrote:
I will try to report this to Perl community later.
Reported under https://github.com/Perl/perl5/issues/22176
Perl 5.36.3 seems to be fine (latest stable release before 5.38.x).
5.38.0 and 5.38.2 are broken.
--
Anton Voloshin
Postgres Professional
hose particular
circumstances (including set of locales) it would work for any username
with length < 8 or >= 16, but would fail for length 8..15 (in bytes, not
characters, if non-ASCII usernames were used).
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
n the patch I've also cleaned up some minor things, like removing
occasional "//" comments within "/* */" ones.
Any thoughts?
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ruFrom a118eb1c4caa1a140cd9a8c4230b91c7bfb91773 Mon Sep 17 0
y.
What about other changes? Are there any obviously wrong or missed ones?
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
tap test for pg_signal_autovacuum role
An obvious patch adding FATAL => 'all' is attached.
Cc Alexander Korotkov and Michael Paquier as committers of those commits.
--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru
P.S. For what it's worth, this is
27 matches
Mail list logo
