On 2024-04-27 09:14, John Naylor wrote:
On Wed, Apr 17, 2024 at 7:21 AM John Naylor
wrote:
On Mon, Apr 15, 2024 at 9:20 PM Marina Polyakova
wrote:
> Everything seems to work with this patch, thank you!
Glad to hear it -- I'll push next week when I get back from vacation,
unl
On 2024-04-13 08:40, John Naylor wrote:
On Fri, Apr 12, 2024 at 11:51 PM Marina Polyakova
wrote:
...
In the other branches everything is fine: these problems begin with
commits [2] (jsonpath_gram.h) and [3] (gram.h) and in the master
branch
there're no such problems after commit [4
f980d280711f8ff8001331c5d
[3]
https://github.com/postgres/postgres/commit/ecaf7c5df54f7fa9df2fdc7225d2bb4e283f0081
[4]
https://github.com/postgres/postgres/commit/721856ff24b3722ce8e894e5a32c9c063cd48455
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/tools/pgi
On 2023-05-19 17:59, Tom Lane wrote:
Marina Polyakova writes:
On 2023-05-19 09:03, Michael Paquier wrote:
FYI, the buildfarm is seeing some spurious failures as well:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=schnauzer=2023-05-1904%3A29%3A42
Yes, it is the same error. Here's
On 2023-05-19 09:03, Michael Paquier wrote:
On Wed, May 17, 2023 at 02:39:10PM +0900, Michael Paquier wrote:
On Tue, May 16, 2023 at 11:02:45AM +0300, Marina Polyakova wrote:
It confuses me a little that different methods are used for the same
purpose. But the namespace test checks schemas. So
On 2023-05-16 02:19, Michael Paquier wrote:
On Mon, May 15, 2023 at 11:23:18PM +0300, Marina Polyakova wrote:
Maybe use a separate schema for all new objects in the transaction
test?..
See diff_set_tx_schema.patch.
Sure, you could do that to bypass the failure (without the "public"
On 2023-05-15 19:16, Tom Lane wrote:
Marina Polyakova writes:
IIUC the conflict was caused by
+SET search_path to public, test_ns_schema_1;
+CREATE SCHEMA test_ns_schema_2
+ CREATE VIEW abc_view AS SELECT a FROM abc;
because the parallel regression test transactions had already
atch fixes this problem...
[1]
https://github.com/postgres/postgres/commit/dbd5795e7539ec9e15c0d4ed2d05b1b18d2a3b09
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/test/regress/expected/namespace.out b/src/test/regress/expe
the documentation is fine.
I played a bit with "make check", creating a database in my native
language (pt_BR), testing with some data and everything worked as
expected.
Hello!
Thank you!
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 2022-10-29 14:33, Marina Polyakova wrote:
Hello!
This is the last proposed patch on this subject [1] moved to a
separate thread for Commitfest..
Also added a patch to export with_icu when running src/bin/scripts tests
[1].
The problem can be reproduced as
$ meson setup &&am
e patch that first
checks everything for provider, locales and encoding but IMO it is worse
[2]..
[1]
https://www.postgresql.org/message-id/e94aca035bf0b92fac42d204ad385552%40postgrespro.ru
[2]
https://www.postgresql.org/message-id/79f410460c4fc9534000785adb8bf39a%40postgrespro.ru
d6ebf7ce5c37d08747e0/src/interfaces/ecpg/test/Makefile#L18
[3]
https://github.com/postgres/postgres/blob/ce20f8b9f4354b46b40fd6ebf7ce5c37d08747e0/src/test/regress/pg_regress.c#L1992
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/s
base.patch fixes both issues
for me.
[1]
https://github.com/postgres/postgres/blob/ce20f8b9f4354b46b40fd6ebf7ce5c37d08747e0/src/interfaces/ecpg/test/Makefile#L18
[2]
https://github.com/postgres/postgres/blob/ce20f8b9f4354b46b40fd6ebf7ce5c37d08747e0/src/test/regress/pg_regress.c#L1992
--
Marina Po
On 2022-10-01 15:07, Peter Eisentraut wrote:
On 22.09.22 20:06, Marina Polyakova wrote:
On 2022-09-21 17:53, Peter Eisentraut wrote:
Committed with that test, thanks. I think that covers all the ICU
issues you reported for PG15 for now?
I thought about the order of the ICU checks
se encoding has been set to "UTF8".
initdb: error: ICU is not supported in this build
4.2. If icu_locale is specified for the wrong provider, the error will
be at the beginning of the program start as before:
$ initdb --icu-locale en-US hoge
initdb: error: --icu-locale cannot be specified unless
On 2022-09-20 12:59, Peter Eisentraut wrote:
On 17.09.22 10:33, Marina Polyakova wrote:
3.
The locale provider is ICU, but it has not yet been set from the
template database:
$ initdb --locale-provider icu --icu-locale en-US -D data &&
pg_ctl -D data -l logfile start &&
On 2022-09-16 10:56, Peter Eisentraut wrote:
On 15.09.22 17:41, Marina Polyakova wrote:
I agree with you. Here's another version of the patch. The
locale/encoding checks and reports in initdb have been reordered,
because now the encoding is set first and only then the ICU locale is
checked
cale ru-RU --template template0 mydb
...
createdb: error: database creation failed: ERROR: ICU locale cannot be
specified unless locale provider is ICU
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 2022-09-16 11:11, Kyotaro Horiguchi wrote:
At Fri, 16 Sep 2022 09:49:28 +0300, Marina Polyakova
wrote in
In continuation of options check: AFAICS the following checks in
initdb
if (locale_provider == COLLPROVIDER_ICU)
{
if (!icu_locale
On 2022-09-16 10:57, Peter Eisentraut wrote:
On 16.09.22 09:31, Marina Polyakova wrote:
IMO it is hardly understantable from the program output either - it
looks like I manually chose the encoding UTF8. Maybe first inform
about selected encoding?..
Yes, I included something like
On 2022-09-16 07:55, Kyotaro Horiguchi wrote:
At Thu, 15 Sep 2022 18:41:31 +0300, Marina Polyakova
wrote in
P.S. While working on the patch, I discovered that UTF8 encoding is
always used for the ICU provider in initdb unless it is explicitly
specified by the user:
if (!encoding
er from the
template database (which could be icu):
$ initdb --locale-provider icu --icu-locale en-US -D data &&
pg_ctl -D data -l logfile start &&
createdb --icu-locale ru-RU --template template0 mydb
...
createdb: error: database creation failed: ERROR: ICU locale cannot be
speci
2icu_tbl in
encnames.c...
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c
index 6ff48bb18f3639ae45d9528b32df51a4aebc60c0..f248ad42b77c8c0cf2089963d4357b120914ce20 100644
-
t;SELECT 'a' < 'b'" mydb
ERROR: encoding "SQL_ASCII" not supported by ICU
The patch diff_check_icu_encoding.patch prohibits the creation of such
objects...
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/b
On 2022-09-13 15:41, Peter Eisentraut wrote:
On 13.09.22 07:34, Marina Polyakova wrote:
I agree with you that it is more comfortable and more similar to what
has already been done in initdb. IMO it would be easier to do it like
this:
diff --git a/src/bin/scripts/createdb.c b/src/bin/scripts
function
normalize_libc_locale_name (collationcmds.c). But ISTM that the current
check is a safety net in case the function pg_get_encoding_from_locale
(chklocale.c) returns -1 or PG_SQL_ASCII...
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
[2] https://www.postgresql.org/docs/devel/sql-createdatabase.html
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c
index 6ff48bb18f3639ae45d9528b32df51
| colliculocale
+---
testcoll_backwards |
(1 row)
diff_dump_colliculocale.patch works for me.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companyinitdb -D data_old &&
pg_ctl -D data_old -l logfile_old start &am
On 2022-08-22 17:10, Peter Eisentraut wrote:
On 15.08.22 14:06, Marina Polyakova wrote:
1.1) It looks like there's a bug in the function get_db_infos
(src/bin/pg_upgrade/info.c), where the version of the old cluster is
always checked:
if (GET_MAJOR_VERSION(old_cluster.major_version) < 1
but the operating system provides
version 49.192.5.42.
2022-08-20 11:38:30.225 MSK [136548] HINT: Rebuild all objects in this
database that use the default collation and run ALTER DATABASE mydb
REFRESH COLLATION VERSION, or build PostgreSQL with the right library
version.
[1]
https://buildf
rovider == COLLPROVIDER_ICU && !dbiculocale)
{
if (dlocale && dlocale->arg)
dbiculocale = defGetString(dlocale);
}
[1]
https://github.com/postgres/postgres/commit/f2553d43060edb210b36c63187d52a632448e1d2
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
this issue to
webmaster(dot)postgresql(dot)org?..
Just in case I'm lucky this email contains the lost patch.
[1]
https://www.postgresql.org/message-id/4047CC05-1AF5-454B-850B-ED37374A2AC0%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres
/message-id/CAPpHfduV3v3EG7K74-9htBZz_mpE993zGz-%3D2k5RNA3tqabUAA%40mail.gmail.com
[2]
https://github.com/postgres/postgres/commit/84d514887f9ca673ae688d00f8b544e70f1ab270
[3]
https://www.postgresql.org/message-id/20200227185129.hikscyenomnlrord%40alap3.anarazel.de
--
Marina Polyakova
Postgres
oaded
from http://www.mingw.org/;>. Neither is
required to run the resulting binaries; they are needed only for
creating the binaries.
[2]
https://www.postgresql.org/message-id/e5a09b790db21356376b6e73673aa07c%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
T
gresql.org/message-id/20200227185129.hikscyenomnlrord%40alap3.anarazel.de
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company<>
n the Winsock2.h header file is used in constructing the FD_SET
structures used with select function.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
erkeley Unix. Their data representation is opaque.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 3057665bbec567331ad5ea03d31af707f5e91b4c..7a54638db191982d538cabf007d82715fa254b6a
On 2019-09-23 19:41, Alvaro Herrera wrote:
On 2019-Sep-23, Marina Polyakova wrote:
The branch REL9_4_STABLE (commit
8a17afe84be6fefe76d0d2f4d26c5ee075e64487)
has the same issue - according to the release table [2] it is still
supported, isn't it?...
Yeah, but pg_upgrade is in contrib/ in 9.4
On 2019-09-18 17:36, Alvaro Herrera wrote:
On 2019-Sep-17, Marina Polyakova wrote:
Hello, hackers!
We got an error for pg_upgrade check on the branch REL_11_STABLE
(commit
40ad4202513c72f5c1beeb03e26dfbc8890770c0) on Solaris 10 because IIUC
the
argument to the sed command is not enclosed
SUNWcsu.
Thanks to Victor Wagner for his help to investigate this issue.
[1] $ man sh
<...>
Quoting
The following characters have a special meaning to the shell and cause
termination of a word unless quoted:
; & ( ) | ^ < > newline space tab
--
Marina Polyako
On 2018-11-16 22:59, Alvaro Herrera wrote:
On 2018-Sep-05, Marina Polyakova wrote:
v11-0001-Pgbench-errors-use-the-RandomState-structure-for.patch
- a patch for the RandomState structure (this is used to reset a
client's
random seed during the repeating of transactions after
serialization
esp if it has a different semantics.
Ok!
I think
I was arguing only about cnt in StatsData.
The discussion about this has become entangled from the beginning,
because as I wrote in [1] at first I misread your original proposal...
[1]
https://www.postgresql.org/message-id/d318c
eded" or "success" to show what is really counted?
Perhaps renaming of StatsData.cnt is better than just adding a comment
to this field. But IMO we have the same problem (They are all counters,
so naming them "cnt" or "total_cnt" does not help much.) for CSta
On 11-09-2018 16:47, Marina Polyakova wrote:
On 08-09-2018 16:03, Fabien COELHO wrote:
Hello Marina,
I'd insist in a comment that "cnt" does not include "skipped"
transactions
(anymore).
If you mean CState.cnt I'm not sure if this is practically useful
because the co
better, I'll change it.
Overall, the comment text in StatsData is very clear. However they are
not
clearly linked to the struct fields. I'd suggest that earch field when
used
should be quoted, so as to separate English from code, and the struct
name
should always be used explicitely when possible
during the repeating of transactions after
serialization/deadlock failures).
Simpler version, applies cleanly on top of previous patch, compiles
and global & local "make check" are ok. Fine with me as well.
Glad to hear it :)
--
Marina Polyakova
Postgres Professional: http://www.p
STM overly complicated):
I agree., I do not think that it would be useful given that the same
thing is done on all meta-command error cases in the end.
Ok!
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
tatus;
[...]
If in such cases one command is placed on several lines, ISTM that the
code is more understandable if curly brackets are used...
Hmmm. Such basic style changes are avoided because they break
backpatching, so we try to avoid gratuitous changes unless there is a
strong added val
the meta commands errors always do not cause the abortions
of the client?
if (per_script_stats)
- accumStats(_script[st->use_file].stats, skipped,
latency, lag);
+ {
+ accumStats(_script[st->use_file].stats, skipped,
latency, lag,
+
the
swap.
Also I do not like the ExpBuf stuff, as usual.
The exponential allocation seems overkill. I'd simply add a constant
number of slots, with a simple rule:
/* reallocated with a margin */
if (max_vars < needed) max_vars = needed + 8;
So in the end the function should be much simpler.
On 10-08-2018 17:19, Arthur Zakirov wrote:
On Fri, Aug 10, 2018 at 04:46:04PM +0300, Marina Polyakova wrote:
> +1 from me to keep initial name "pgbench_error". "pgbench_log" for new
> function looks nice to me. I think it is better than just "log",
>
On 10-08-2018 15:53, Arthur Zakirov wrote:
On Thu, Aug 09, 2018 at 06:17:22PM +0300, Marina Polyakova wrote:
> * ErrorLevel
>
> If ErrorLevel is used for things which are not errors, its name should
> not include "Error"? Maybe "LogLevel"?
On the one han
version I will put the error patch last, so it will be
possible to compare the "retry on error" feature with it and without it,
and let the committer decide how it is better)
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
rt if necessary from the callers with a "aborted because of
putVariable/eval/... error" message, as it was done before.
There's one more problem: if this is a client failure, an error message
inside any of these functions should be printed at the level
DEBUG_FAILS; otherwise it should be printed at the level LOG. Or do you
suggest using the error level as an argument for these functions?
pgbench_error calls pgbench_error. Hmmm, why not.
[1]
https://www.postgresql.org/message-id/alpine.DEB.2.21.1806100837380.3655%40lancre
[2]
https://www.postgresql.org/message-id/b692de21caaed13c59f31c06d0098488%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
so that it
wouldn't look as confusing. Maybe that's just me.
[2]
https://www.postgresql.org/message-id/cb2cde10e4e7a10a38b48e9cae8fbd28%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
_buf, '\n');
ereport(ELEVEL_DEBUG, (errmsg("%s", errmsg_buf.data)));
termPQExpBuffer(_buf);
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 11-07-2018 21:04, Alvaro Herrera wrote:
Just a quick skim while refreshing what were those error reporting API
changes about ...
Thank you!
On 2018-May-21, Marina Polyakova wrote:
v9-0001-Pgbench-errors-use-the-RandomState-structure-for-.patch
- a patch for the RandomState structure
On 11-07-2018 20:49, Alvaro Herrera wrote:
On 2018-Jul-11, Marina Polyakova wrote:
can we try something like this?
PGBENCH_ERROR_START(DEBUG_FAIL)
{
PGBENCH_ERROR("client %d repeats the failed transaction (try %d",
st->id, st
imum width 20 to the per-statement report
The fact that some data are collected does not mean that they should
all be reported in detail. We can have detailed error count and report
the sum of this errors for instance, or have some more
verbose/detailed reports
as options (eg --latencies does just that).
Ok!
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ion" errors every where and report about them and document them
extensively.
This means adding a check when a script is finished or starting that
PQtransactionStatus(const PGconn *conn) == PQTRANS_IDLE, and abort if
not
with a fatal error. Then we can forget about these "in tx errors"
counting,
reporting and so on, and just have to document the restriction.
Ok!
[1]
https://www.postgresql.org/message-id/alpine.DEB.2.20.1801031720270.20034%40lancre
[2]
https://www.postgresql.org/message-id/e4c5e8cefa4a8e88f1273b0f1ee29...@postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
m different reviewers should
be consistent? That seems optimistic:-)
To make the patch committable there should be no objection to it..
[1]
https://www.postgresql.org/message-id/c89fcc380a19380260b5ea463efc1416%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
rrmsg("Server error"),
+errdetail("%s", PQerrorMessage(con)),
+sqlState && strcmp(sqlState,
ERRCODE_UNDEFINED_TABLE) == 0 ?
+ errhint("Perhaps you need to do initialization (\"pgbench -i\")
in dat
d/453fa52de88477df2c4a2d82e09e461c%40postgrespro.ru
[2]
https://www.postgresql.org/message-id/20180405180807.0bc1114f%40wp.localdomain
[3]
https://www.postgresql.org/message-id/20180508105832.6o3uf3npfpjgk5m7%40alvherre.pgsql
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
".
I'd suggest "vars" instead. "nvariables" could be "nvars" for
consistency with that and "vars_sorted", and because
"foo.variables->nvariables" starts looking heavy.
I'd suggest but "Variables" type declaration just after "Variable&qu
quality at a lower
cost.
This sounds interesting, thanks!
*went to look for a multiplier and a summand that are large enough and
are mutually prime..*
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 09-05-2018 17:30, Alvaro Herrera wrote:
Marina Polyakova wrote:
Hello everyone in this thread!
I got a similar server crash as in [1] on the master branch since the
commit
9fdb675fc5d2de825414e05939727de8b120ae81 when the assertion fails
because
the second argument ScalarArrayOpExpr
On 07-05-2018 4:37, Michael Paquier wrote:
On Fri, May 04, 2018 at 12:32:23PM +0300, Marina Polyakova wrote:
I got a similar server crash as in [1] on the master branch since the
commit
9fdb675fc5d2de825414e05939727de8b120ae81 when the assertion fails
because
the second argument
nst))
{
...
}
else
{
ArrayExpr *arrexpr = castNode(ArrayExpr, rightop); #
fails here
...
}
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Sorry for this late reply, I was very busy with the patch for pgbench..
On 04-04-2018 20:07, Simon Riggs wrote:
...
Which debug mode are we talking about, please?
-d 5
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
not mind, of
course..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
a
try that makes the tests pass. Sorry if I missed that it was already
discussed somewhere.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
index c8d9626..2411658 100644
..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 05-03-2018 18:21, David Steele wrote:
Hello Marina,
Hello, David!
On 1/12/18 12:01 PM, Marina Polyakova wrote:
...
This patch was marked Waiting on Author on Jan 8 and no new patch was
submitted before this commitfest.
I think we should mark this patch as Returned with Feedback.
I'm
Ok!
On 02-03-2018 22:56, Andres Freund wrote:
Hi,
On 2018-03-02 11:22:01 +0300, Marina Polyakova wrote:
I fixed the failure that Thomas pointed out to me, and I'm finishing
work on
it, but it took me a while to study this part of the executor..
I unfortunately think that makes this too
Hello!
I fixed the failure that Thomas pointed out to me, and I'm finishing
work on it, but it took me a while to study this part of the executor..
On 02-03-2018 0:11, Andres Freund wrote:
Hi,
On 2018-02-01 08:01:48 +0300, Marina Polyakova wrote:
> ISTM, there might be some va
On 21-02-2018 18:51, Tom Lane wrote:
Marina Polyakova <m.polyak...@postgrespro.ru> writes:
On 20-02-2018 21:23, Tom Lane wrote:
I continue to wonder if it's not better to just remove
the option and thereby simplify our lives. What's the actual value
of
having it anymore?
I agree wi
On 20-02-2018 21:23, Tom Lane wrote:
Marina Polyakova <m.polyak...@postgrespro.ru> writes:
On 20-02-2018 3:37, Tom Lane wrote:
4. Try to tweak the stats_ext.sql test conditions in some more
refined
way to get the test to pass everywhere. This'd be a lot of work with
no guarantee of s
d be a lot of work with
no guarantee of success, so I'm not too excited about it.
Thank you for your explanations! I'll try to do something in this
direction..
5. Something else?
regards, tom lane
--
Marina Polyakova
Postgres Professional: http://www.postg
system: Windows Server 2008 R2 Standard, Service Pack 1,
64-bit.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company*** C:/Users/buildfarm/mpolyakova/postgrespro_master/src/test/regress/expected/stats_ext.out Fri Feb 16 12:56:00 2018
--- C:/Users/bui
On 14-02-2018 17:54, Tom Lane wrote:
Marina Polyakova <m.polyak...@postgrespro.ru> writes:
On 14-02-2018 3:43, Peter Eisentraut wrote:
OK, can you get some kind of stack trace or other debugging
information?
I got this backtrace from gdb:
Hmm, so the only question in my mind is h
On 14-02-2018 3:43, Peter Eisentraut wrote:
On 2/13/18 05:40, Marina Polyakova wrote:
Binary search has shown that this failure begins with commit
8561e4840c81f7e345be2df170839846814fa004 (Transaction control in PL
procedures.). On the previous commit
(b9ff79b8f17697f3df492017d454caa9920a7183
no
plpython_transaction test and plpython check passes.
About the system: SunOS, Release 5.10, KernelID Generic_141444-09.
P.S. It seems that there's a similar failure on Windows, and I'm trying
to reproduce it..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The
Hello!
Thank you for reporting! I'll try to get it on our buildfarm..
On 05-02-2018 0:10, Thomas Munro wrote:
On Thu, Feb 1, 2018 at 6:01 PM, Marina Polyakova
<m.polyak...@postgrespro.ru> wrote:
This is the 8-th version of the patch for the precalculation of stable
or
immutable fun
-id/403e0ae329c6868b3f3467eac92cc04d%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 17-01-2018 1:05, Tom Lane wrote:
[ I'm sending this comment separately because I think it's an issue
Andres might take an interest in. ]
Marina Polyakova <m.polyak...@postgrespro.ru> writes:
[ v7-0001-Precalculate-stable-and-immutable-functions.patch ]
Another thing that's bother
documentation in this patch
isn't quite nonexistent, but it's well short of being in a
committable state IMO.
I'll try to improve it, for CheckBoundParams (if I understood you
correctly) and others.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 18-01-2018 20:49, Marina Polyakova wrote:
On 18-01-2018 20:34, Tom Lane wrote:
...
What you could do in the meantime is work on finding a variation of
Victor's test that will detect the bug regardless of -O level.
If we do have hope that future gcc versions will handle this
correctly
that will detect the bug regardless of -O level.
If we do have hope that future gcc versions will handle this correctly,
we'll need a better test rather than just summarily dismissing
host_cpu = sparc.
Thanks, I'll try..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian
On 18-01-2018 20:24, Tom Lane wrote:
Marina Polyakova <m.polyak...@postgrespro.ru> writes:
On 18-01-2018 19:53, Tom Lane wrote:
So basically, we're outta luck and we have to consider __int128 as
unsupportable on SPARC. I'm inclined to mechanize that as a test on
$host_cpu. At
On 18-01-2018 19:53, Tom Lane wrote:
Marina Polyakova <m.polyak...@postgrespro.ru> writes:
On 18-01-2018 17:56, Tom Lane wrote:
Weird. Maybe the gcc bug only manifests with certain optimization
flags? That's not what I'd have expected from Victor's theory about
why the code is
On 18-01-2018 17:56, Tom Lane wrote:
Marina Polyakova <m.polyak...@postgrespro.ru> writes:
Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
and using the configuration command from [1], I got:
checking for __int128... yes
checking for __int128 alignment bug...
On 17-01-2018 18:50, Marina Polyakova wrote:
On 17-01-2018 18:28, Tom Lane wrote:
BTW, now that you've demonstrated that the bug exists in a current
gcc release, you should definitely file a bug at
https://gcc.gnu.org/bugzilla/
I think you can just give them int128test2.c as-is as a test case
age-id/0d3a9fa264cebe1cb9966f37b7c06e86%40postgrespro.ru
[2]
https://www.postgresql.org/message-id/20180117203648.2626d97a%40wagner.wagner.home
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--- I think it would be
good to cite the bug specifically in the comments for our configure
code.
Thanks, I'll try to do it.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Sorry, diff.patch is attached now.
On 17-01-2018 18:02, Marina Polyakova wrote:
[I added Victor Wagner as co-researcher of this problem]
On 13-01-2018 21:10, Tom Lane wrote:
In the end this might just be an instance of the old saw about
avoiding dot-zero releases. Have you tried a newer gcc
, though none look to be specifically about
misaligned data.)
gcc 5.5.0 (from [1]) did not fix the problem..
On 16-01-2018 2:41, Tom Lane wrote:
Marina Polyakova <m.polyak...@postgrespro.ru> writes:
On 13-01-2018 21:10, Tom Lane wrote:
I'm not sure there's much we can do about this. Dr
Thank you so much for your comments!! I'll answer a bit later because
now I'm trying to find a test for int128 on Solaris 10.. [1]
On 17-01-2018 1:05, Tom Lane wrote:
[ I'm sending this comment separately because I think it's an issue
Andres might take an interest in. ]
Marina Polyakova
On 12-01-2018 14:05, Marina Polyakova wrote:
- on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935)
the same failures occur (see the attached regression diffs and
output);
- on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
passes.
I'll try to find out from what
On 12-01-2018 18:12, Alvaro Herrera wrote:
Marina Polyakova wrote:
- on the previous commit (272c2ab9fd0a604e3200030b1ea26fd464c44935)
the same
failures occur (see the attached regression diffs and output);
- on commit bf54c0f05c0a58db17627724a83e1b6d4ec2712c make check-world
passes.
I'll try
file is
involved, it is different from the shell.
Oh, now googling was successful, thanks)
[1]
https://www.postgresql.org/message-id/alpine.DEB.2.20.1707141637300.7871%40lancre
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
1 - 100 of 107 matches
Mail list logo
