Thank you!
On 2024-11-26 23:46, Andrew Dunstan wrote:
On 2024-11-26 Tu 1:24 AM, Marina Polyakova wrote:
Hello! Could you backport the commit "Fix meson uuid header check so
it works with MSVC" [1] to REL_16_STABLE please? Building with
-Duuid=ossp fails without it:
yep, done.
"uuid_export" with dependency -luuid: YES
[1]
https://github.com/postgres/postgres/commit/7c655a04a2dc84b59ed6dce97bd38b79e734ecca
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
s.
regards, tom lane
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 2024-07-26 15:27, Daniel Gustafsson wrote:
On 26 Jul 2024, at 14:03, Marina Polyakova
wrote:
It looks like the recommended way of using autoheader [1] is now
broken. The attached patch fixes the master branch for me.
Thanks for the report, I'll fix it. Buildfarm animal hamerkop
ge-id/30511.1546097762%40sss.pgh.pa.us
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index db3fcbecc3ab33c8593eeb4a6d2927f674e2f684..3dea3856aaf06a3c59a77cc46e76b6d6efd5f88c 100644
---
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,
unless t
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]
bbcf2f980d280711f8ff8001331c5d
[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/tool
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&dt=2023-05-1904%3A29%3A42
Yes, it is the same e
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
k 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
a6e56%40postgrespro.ru
[2]
https://github.com/postgres/postgres/blob/ce20f8b9f4354b46b40fd6ebf7ce5c37d08747e0/src/interfaces/ecpg/test/Makefile#L18
[3]
https://github.com/postgres/postgres/blob/ce20f8b9f4354b46b40fd6ebf7ce5c37d08747e0/src/test/regress/pg_regress.c#L1992
--
Marina Polyakova
Po
le sss->locale->info.icu.locale en-US
...
The patch diff_fix_pg_regress_create_database.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/c
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 - if it is
ding 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
ch
b --icu-locale 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 that in the
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
rovider 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
pg_enc2icu_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..f248ad42b77c8c0cf2089963d4357b120914ce2
;
psql -c "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 Ru
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
f with the 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
edb210b36c63187d52a632448e1d2
[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
x27;
collname | 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 l
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) &
-08-20 11:38:30.225 MSK [136548] DETAIL: The database was created
using collation version 49.192.0.42, 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
EATE DATABASE?.. From
src/backend/commands/dbcommands.c:
if (dblocprovider == 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
to write about 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
.
[1]
https://www.postgresql.org/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.anaraze
downloaded
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://ww
.postgresql.org/message-id/20200227185129.hikscyenomnlrord%40alap3.anarazel.de
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company<>
in 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
in Berkeley 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..7a54638db191982d538cabf007d82715fa2
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/ i
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 in
e
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 Polyak
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
serializ
a different name, 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.postgr
nt" or "total_cnt" does not help much.
Maybe "succeeded" 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
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
keep on one line?
I tried not to break the limit of 80 characters, but if you think that
this is 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
sho
ables 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://
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
ECTION_FAILURE
} FailureStatus;
[...]
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 th
+ accumStats(&sql_script[st->use_file].stats, skipped,
latency, lag,
+ st->failure_status, st->retries);
+ }
}
I do not see the point of changing the style here.
If in such cases one command is placed on several lines, ISTM that the
code is more understandable if curly brackets are used...
[1]
https://www.postgresql.org/message-id/fcc2512cdc9e6bc49d3b489181f454da%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
d on the size of 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 functio
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 hand, this
.
In the next 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
able, putVariable* as they are,
call pgbench_error with a level which does not stop the execution, and
abort 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
tate struct members 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
argv[i]);
appendPQExpBufferChar(&errmsg_buf, '\n');
ereport(ELEVEL_DEBUG, (errmsg("%s", errmsg_buf.data)));
termPQExpBuffer(&errmsg_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->retries
could be
recomputed
from these.
Thank you, I agree with you. Unfortunately each new error type adds a
new 1 or 2 columns of maximum 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
t; but without a corresponding "COMMIT" is a user error and
warrants an abort, so that there is no need to manage these "in aborted
transaction" 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
u hoping that advises from 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
(errmsg("Server error"),
+errdetail("%s", PQerrorMessage(con)),
+sqlState && strcmp(sqlState,
ERRCODE_UNDEFINED_TABLE) == 0 ?
+ errhint("Perhaps you need to do initialization (\"pgbench -i\
..
[1]
https://www.postgresql.org/message-id/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 "V
's processors, providing more 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 is
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
clause_to_partition_key:
if (IsA(rightop, Const))
{
...
}
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
ou do not mind, of
course..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ached 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 1
nditional stack..
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 06-03-2018 18:02, David Steele wrote:
Hi Marina,
On 3/6/18 4:45 AM, Marina Polyakova wrote:
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
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&#
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 thi
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
On 21-02-2018 18:51, Tom Lane wrote:
Marina Polyakova 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 with you, but I have
On 20-02-2018 21:23, Tom Lane wrote:
Marina Polyakova 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 success, so I'm not too exc
o pass everywhere. This'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
Pos
On 16-02-2018 19:31, Tom Lane wrote:
Marina Polyakova writes:
Hello, hackers! I got a permanent failure of master (commit
2a41507dab0f293ff241fe8ae326065998668af8) check on Windows Server
2008.
Regression output and diffs as well as config.pl are attached.
Weird. AFAICS the cost estimates
the 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:/User
On 14-02-2018 17:54, Tom Lane wrote:
Marina Polyakova 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 how did this ever work for
anyone
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
x27;s 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.postg
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
wrote:
This is the 8-th version of the patch for the precalculation of stable
or
immutable functions, stable or immutable oper
sql.org/message-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 writes:
[ v7-0001-Precalculate-stable-and-immutable-functions.patch ]
Another thing that's bothering me is tha
AFAIU they do not differ, and as I said above I'll try not to change the
infrastructure of ParamListInfoData.
And what in the world is
CheckBoundParams about? The internal 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
corr
test 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.postgre
On 18-01-2018 20:24, Tom Lane wrote:
Marina Polyakova 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 least that means we don't
On 18-01-2018 19:53, Tom Lane wrote:
Marina Polyakova 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 wrong, but if it only shows
On 18-01-2018 17:56, Tom Lane wrote:
Marina Polyakova 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... broken
...
And make check-world passes
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
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
1 - 100 of 121 matches
Mail list logo
