Schema variables - new implementation for Postgres 15

From: Pavel Stehule <pavel.stehule@gmail.com>
--------------------------------------------------
do $$
declare x int ;
begin
for i in 1..1000000
loop
let ooo = i;
end loop;
end;
$$;

variant 1 .. 1500 ms
variant 2 with PLpgSQL support .. 140 ms
variant 2 without PLpgSQL support 9000 ms
--------------------------------------------------

That's impressive! But 1 million times of variable assignment took only 140 ms? It's that one assignment took only 140 nanosecond, which is near one DRAM access? Can PL/pgSQL processing be really so fast?

Regards
Takayuki Tsunakawa

čt 15. 4. 2021 v 18:02 odesílatel tsunakawa.takay@fujitsu.com <
tsunakawa.takay@fujitsu.com> napsal:

From: Pavel Stehule <pavel.stehule@gmail.com>

--------------------------------------------------

do $$

declare x int ;

begin

for i in 1..1000000

loop

let ooo = i;

end loop;

end;

$$;

variant 1 .. 1500 ms

variant 2 with PLpgSQL support .. 140 ms

variant 2 without PLpgSQL support 9000 ms

--------------------------------------------------

That's impressive! But 1 million times of variable assignment took only
140 ms? It's that one assignment took only 140 nanosecond, which is near
one DRAM access? Can PL/pgSQL processing be really so fast?

In this case the PLpgSQL can be very fast - and after changes in pg 13, the
PLpgSQL is not significantly slower than Lua or than PHP.

Every body can repeat these tests - I did it on my Lenovo T520 notebook

Pavel

čt 15. 4. 2021 v 10:42 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:

Hi,

I am returning back to implementation of schema variables. The schema
variables can be used as an alternative to package variables (Oracle's
PL/SQL or ADA). The schema variables can be used as fast and safe storage
of session information for RLS too.

The previous implementation had not cleanly implemented execution of the
LET statement. It was something between query and utility, and although it
was working - it was out of Postgres concept (with different implementation
of queries and utilities).

I totally rewrote the implementation of the LET statement. I prepared two
variants:

First variant is based on the introduction of the new command type CMD_LET
and new very small executor node SetVariable (this is a very very reduced
analogy of ModifyTable node). The code is consistent and what is important
- the LET statement can be prepared. The execution is relatively fast from
PLpgSQL too. Without any special support the execution has the same speed
like non simple queries. The statement reuses an execution plan, but
simple execution is not supported.

Second variant is implemented like a classic utility command. There is not
any surprise. It is shorter, simple, but the LET statement cannot be
prepared (this is the limit of all utility statements). Without special
support in PLpgSQL the execution is about 10x slower than the execution of
the first variant. But there is a new possibility of using the main parser
from PLpgSQL (implemented by Tom for new implementation of assign statement
in pg 14), and then this support in plpgsql requires only a few lines).
When the statement LET is explicitly supported by PLpgSQL, then execution
is very fast (the speed is comparable with the speed of the assign
statement) - it is about 10x faster than the first variant.

I tested code

do $$
declare x int ;
begin
for i in 1..1000000
loop
let ooo = i;
end loop;
end;
$$;

variant 1 .. 1500 ms
variant 2 with PLpgSQL support .. 140 ms
variant 2 without PLpgSQL support 9000 ms

The slower speed of the first variant from PLpgSQL can be fixed. But for
this moment, the speed is good enough. This is the worst case, because in
the first variant LET statement cannot use optimization for simple query
evaluation (now).

Now I think so implementation is significantly cleaner, and I hope so it
will be more acceptable for committers.

I am starting a new thread, because this is a new implementation, and
because I am sending two alternative implementations of one functionality.

Comments, notes, objections?

I am sending only one patch and I assign this thread to commitfest
application

Regards

Pavel

On Thu, Apr 15, 2021, at 10:42, Pavel Stehule wrote:

*Attachments:*
* schema-variables-v-execnode-2021-01.patch
* schema-variables-v-utility-2021-01.patch

Applications are currently know to be misusing set_config()+current_setting() to pass information in a session or transaction.

Such users might be interested in using Schema variables as a better replacement.

However, since set_config() is transactional, it can't be used as a drop-in replacement:

+   <para>
+    The value of a schema variable is local to the current session. Retrieving
+    a variable's value returns either a NULL or a default value, unless its value
+    is set to something else in the current session with a LET command. The content
+    of a variable is not transactional. This is the same as in regular variables
+    in PL languages.
+   </para>

I think the "The content of a variable is not transactional." part is therefore a bad idea.

Another pattern is to use TEMP TABLEs to pass around information in a session or transaction.
If the LET command would be transactional, it could be used as a drop-in replacement for such use-cases as well.

Furthermore, I think a non-transactional LET command would be insidious,
since it looks like any other SQL command, all of which are transactional.
(The ones that aren't such as REINDEX CONCURRENTLY will properly throw an error if run inside a transaction block.)

A non-transactional LET command IMO would be non-SQL-idiomatic and non-intuitive.

/Joel

pá 16. 4. 2021 v 8:07 odesílatel Joel Jacobson <joel@compiler.org> napsal:

On Thu, Apr 15, 2021, at 10:42, Pavel Stehule wrote:

*Attachments:*

- schema-variables-v-execnode-2021-01.patch
- schema-variables-v-utility-2021-01.patch

Applications are currently know to be misusing
set_config()+current_setting() to pass information in a session or
transaction.

Such users might be interested in using Schema variables as a better
replacement.

However, since set_config() is transactional, it can't be used as a
drop-in replacement:

+   <para>
+    The value of a schema variable is local to the current session.
Retrieving
+    a variable's value returns either a NULL or a default value, unless
its value
+    is set to something else in the current session with a LET command.
The content
+    of a variable is not transactional. This is the same as in regular
variables
+    in PL languages.
+   </para>

I think the "The content of a variable is not transactional." part is
therefore a bad idea.

Another pattern is to use TEMP TABLEs to pass around information in a
session or transaction.
If the LET command would be transactional, it could be used as a drop-in
replacement for such use-cases as well.

Furthermore, I think a non-transactional LET command would be insidious,
since it looks like any other SQL command, all of which are transactional.
(The ones that aren't such as REINDEX CONCURRENTLY will properly throw an
error if run inside a transaction block.)

A non-transactional LET command IMO would be non-SQL-idiomatic and
non-intuitive.

I am sorry, but in this topic we have different opinions. The variables in
PLpgSQL are not transactional too (same is true in Perl, Python, ...).
Session variables in Oracle, MS SQL, DB2, MySQL are not transactional too.
My primary focus is PLpgSQL - and I would like to use schema variables as
global plpgsql variables (from PLpgSQL perspective) - that means in
Postgres's perspective session variables. But in Postgres, I have to write
features that will work with others PL too - PLPython, PLPerl, ...
Statement SET in ANSI/SQL standard (SQL/PSM) doesn't expect transactional
behaviour for variables too. Unfortunately SET keyword is used in Postgres
for GUC, and isn't possible to reuse without a compatibility break.

The PostgreSQL configuration is transactional, but it is a different
feature designed for different purposes. Using GUC like session variables
is just a workaround. It can be useful for some cases, sure. But it is not
usual behaviour. And for other cases the transactional behaviour is not
practical. Schema variables are not replacement of GUC, schema variables
are not replacement of temporal tables. There is a prepared patch for
global temp tables. I hope so this patch can be committed to Postgres 15.
Global temp tables fixes almost all disadvantages of temporary tables in
Postgres. So the schema variable is not a one row table. It is a different
creature - designed to support the server's side procedural features.

I have prepared a patch that allows non default transactional behaviour
(but this behaviour should not be default - I didn't design schema
variables as temp tables replacement). This patch increases the length of
the current patch about 1/4, and I have enough work with rebasing with the
current patch, so I didn't send it to commitfest now. If schema variables
will be inside core, this day I'll send the patch that allows transactional
behaviour for schema variables - I promise.

Regards

Pavel

From: Pavel Stehule <pavel.stehule@gmail.com>
--------------------------------------------------
I am sorry, but in this topic we have different opinions. The variables in PLpgSQL are not transactional too (same is true in Perl, Python, ...). Session variables in Oracle, MS SQL, DB2, MySQL are not transactional too. My primary focus is PLpgSQL - and I would like to use schema variables as global plpgsql variables (from PLpgSQL perspective) - that means in Postgres's perspective session variables. But in Postgres, I have to write features that will work with others PL too - PLPython, PLPerl, ... Statement SET in ANSI/SQL standard (SQL/PSM) doesn't expect transactional behaviour for variables too. Unfortunately SET keyword is used in Postgres for GUC, and isn't possible to reuse without a compatibility break.

The PostgreSQL configuration is transactional, but it is a different feature designed for different purposes. Using GUC like session variables is just a workaround. It can be useful for some cases, sure. But it is not usual behaviour. And for other cases the transactional behaviour is not practical. Schema variables are not replacement of GUC, schema variables are not replacement of temporal tables. There is a prepared patch for global temp tables. I hope so this patch can be committed to Postgres 15. Global temp tables fixes almost all disadvantages of temporary tables in Postgres. So the schema variable is not a one row table. It is a different creature - designed to support the server's side procedural features.
--------------------------------------------------

+1
I understand (and wish) this feature is intended to ease migration from Oracle PL/SQL, which will further increase the popularity of Postgres. So, the transactional behavior is not necessary unless Oracle has such a feature.

Furthermore, Postgres already has some non-transactonal SQL commands. So, I don't think we need to reject non-transactional LET.

* Sequence operation: SELECT nextval/setval
* SET [SESSION]
* SET ROLE
* SET SESSION AUTHORIZATION

--------------------------------------------------
I have prepared a patch that allows non default transactional behaviour (but this behaviour should not be default - I didn't design schema variables as temp tables replacement). This patch increases the length of the current patch about 1/4, and I have enough work with rebasing with the current patch, so I didn't send it to commitfest now. If schema variables will be inside core, this day I'll send the patch that allows transactional behaviour for schema variables - I promise.
--------------------------------------------------

I prefer the simpler, targeted one without transactional behavior initially, because added complexity might prevent this feature from being committed in PG 15.

Regards
Takayuki Tsunakawa

Hi

only rebase

Regards

Pavel

st 12. 5. 2021 v 6:17 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:

Hi

only rebase

second try - rebase after serial_scheduler remove

Regards

Pavel

st 12. 5. 2021 v 7:37 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:

st 12. 5. 2021 v 6:17 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:

Hi

only rebase

second try - rebase after serial_scheduler remove

only rebase

Regards

Pavel

Hi

rebase

Regards

Pavel

so 12. 6. 2021 v 8:00 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
napsal:

Hi

rebase

rebase only

Regards

Pavel

Regards

Hi,

Review resume:

This patch implements Schema Variables that are database objects that
can hold a single or composite value following the data type used at
variable declaration. Schema variables, like relations, exist within a
schema and their access is controlled via GRANT and REVOKE commands. The
schema variable can be created by the CREATE VARIABLE command, altered
using ALTER VARIABLE and removed using DROP VARIABLE.

The value of a schema variable is local to the current session.
Retrieving a variable's value returns either a NULL or a default value,
unless its value is set to something else in the current session with a
LET command. The content of a variable is not transactional. This is the
same as in regular variables in PL languages.

Schema variables are retrieved by the SELECT SQL command. Their value is
set with the LET SQL command. While schema variables share properties
with tables, their value cannot be updated with an UPDATE command.

The patch apply with the patch command without problem and compilation
reports no warning or errors. Regression tests pass successfully using
make check or make installcheck
It also includes all documentation and regression tests.

Performances are near the set of plpgsql variable settings which is
impressive:

do $$
declare var1 int ; i int;
begin
  for i in 1..1000000
  loop
    var1 := i;
  end loop;
end;
$$;
DO
Time: 71,515 ms

CREATE VARIABLE var1 AS integer;
do $$
declare i int ;
begin
  for i in 1..1000000
  loop
    let var1 = i;
  end loop;
end;
$$;
DO
Time: 94,658 ms

There is just one thing that puzzles me.We can use :

    CREATE VARIABLE var1 AS date NOT NULL;
    postgres=# SELECT var1;
    ERROR:  null value is not allowed for NOT NULL schema variable "var1"

which I understand and is the right behavior. But if we use:

    CREATE IMMUTABLE VARIABLE var1 AS date NOT NULL;
    postgres=# SELECT var1;
    ERROR:  null value is not allowed for NOT NULL schema variable "var1"
    DETAIL:  The schema variable was not initialized yet.
    postgres=# LET var1=current_date;
    ERROR:  schema variable "var1" is declared IMMUTABLE

It should probably be better to not allow NOT NULL when IMMUTABLE is
used because the variable can not be used at all.  Also probably
IMMUTABLE without a DEFAULT value should also be restricted as it makes
no sens. If the user wants the variable to be NULL he must use DEFAULT
NULL. This is just a though, the above error messages are explicit and
the user can understand what wrong declaration he have done.

Except that I think this patch is ready for committers, so if there is
no other opinion in favor of restricting the use of IMMUTABLE with NOT
NULL and DEFAULT I will change the status to ready for committers.

--
Gilles Darold
http://www.darold.net/

so 28. 8. 2021 v 11:57 odesílatel Gilles Darold <gilles@darold.net> napsal:

Hi,

Review resume:

This patch implements Schema Variables that are database objects that can
hold a single or composite value following the data type used at variable
declaration. Schema variables, like relations, exist within a schema and
their access is controlled via GRANT and REVOKE commands. The schema
variable can be created by the CREATE VARIABLE command, altered using ALTER
VARIABLE and removed using DROP VARIABLE.

The value of a schema variable is local to the current session. Retrieving
a variable's value returns either a NULL or a default value, unless its
value is set to something else in the current session with a LET command.
The content of a variable is not transactional. This is the same as in
regular variables in PL languages.

Schema variables are retrieved by the SELECT SQL command. Their value is
set with the LET SQL command. While schema variables share properties with
tables, their value cannot be updated with an UPDATE command.

The patch apply with the patch command without problem and compilation
reports no warning or errors. Regression tests pass successfully using make
check or make installcheck
It also includes all documentation and regression tests.

Performances are near the set of plpgsql variable settings which is
impressive:

do $$
declare var1 int ; i int;
begin
for i in 1..1000000
loop
var1 := i;
end loop;
end;
$$;
DO
Time: 71,515 ms

CREATE VARIABLE var1 AS integer;
do $$
declare i int ;
begin
for i in 1..1000000
loop
let var1 = i;
end loop;
end;
$$;
DO
Time: 94,658 ms

There is just one thing that puzzles me. We can use :

CREATE VARIABLE var1 AS date NOT NULL;
postgres=# SELECT var1;
ERROR: null value is not allowed for NOT NULL schema variable "var1"

which I understand and is the right behavior. But if we use:

CREATE IMMUTABLE VARIABLE var1 AS date NOT NULL;
postgres=# SELECT var1;
ERROR: null value is not allowed for NOT NULL schema variable "var1"
DETAIL: The schema variable was not initialized yet.
postgres=# LET var1=current_date;
ERROR: schema variable "var1" is declared IMMUTABLE

It should probably be better to not allow NOT NULL when IMMUTABLE is used
because the variable can not be used at all. Also probably IMMUTABLE
without a DEFAULT value should also be restricted as it makes no sens. If
the user wants the variable to be NULL he must use DEFAULT NULL. This is
just a though, the above error messages are explicit and the user can
understand what wrong declaration he have done.

I thought about this case, and I have one scenario, where this behaviour
can be useful. When the variable is declared as IMMUTABLE NOT NULL without
not null default, then any access to the content of the variable has to
fail. I think it can be used for detection, where and when the variable is
first used. So this behavior is allowed just because I think, so this
feature can be interesting for debugging. If this idea is too strange, I
have no problem to disable this case.

Regards

Pavel

Hi

so 28. 8. 2021 v 11:57 odesílatel Gilles Darold <gilles@darold.net> napsal:

Hi,

Review resume:

This patch implements Schema Variables that are database objects that can
hold a single or composite value following the data type used at variable
declaration. Schema variables, like relations, exist within a schema and
their access is controlled via GRANT and REVOKE commands. The schema
variable can be created by the CREATE VARIABLE command, altered using ALTER
VARIABLE and removed using DROP VARIABLE.

The value of a schema variable is local to the current session. Retrieving
a variable's value returns either a NULL or a default value, unless its
value is set to something else in the current session with a LET command.
The content of a variable is not transactional. This is the same as in
regular variables in PL languages.

Schema variables are retrieved by the SELECT SQL command. Their value is
set with the LET SQL command. While schema variables share properties with
tables, their value cannot be updated with an UPDATE command.

The patch apply with the patch command without problem and compilation
reports no warning or errors. Regression tests pass successfully using make
check or make installcheck
It also includes all documentation and regression tests.

Performances are near the set of plpgsql variable settings which is
impressive:

do $$
declare var1 int ; i int;
begin
for i in 1..1000000
loop
var1 := i;
end loop;
end;
$$;
DO
Time: 71,515 ms

CREATE VARIABLE var1 AS integer;
do $$
declare i int ;
begin
for i in 1..1000000
loop
let var1 = i;
end loop;
end;
$$;
DO
Time: 94,658 ms

There is just one thing that puzzles me. We can use :

CREATE VARIABLE var1 AS date NOT NULL;
postgres=# SELECT var1;
ERROR: null value is not allowed for NOT NULL schema variable "var1"

which I understand and is the right behavior. But if we use:

CREATE IMMUTABLE VARIABLE var1 AS date NOT NULL;
postgres=# SELECT var1;
ERROR: null value is not allowed for NOT NULL schema variable "var1"
DETAIL: The schema variable was not initialized yet.
postgres=# LET var1=current_date;
ERROR: schema variable "var1" is declared IMMUTABLE

It should probably be better to not allow NOT NULL when IMMUTABLE is used
because the variable can not be used at all. Also probably IMMUTABLE
without a DEFAULT value should also be restricted as it makes no sens. If
the user wants the variable to be NULL he must use DEFAULT NULL. This is
just a though, the above error messages are explicit and the user can
understand what wrong declaration he have done.

I wrote a check that disables this case. Please, see the attached patch. I
agree, so this case is confusing, and it is better to disable it.

Regards

Pavel

Le 08/09/2021 à 13:41, Pavel Stehule a écrit :

Hi

so 28. 8. 2021 v 11:57 odesílatel Gilles Darold <gilles@darold.net
<mailto:gilles@darold.net>> napsal:

Hi,

Review resume:

This patch implements Schema Variables that are database objects
that can hold a single or composite value following the data type
used at variable declaration. Schema variables, like relations,
exist within a schema and their access is controlled via GRANT and
REVOKE commands. The schema variable can be created by the CREATE
VARIABLE command, altered using ALTER VARIABLE and removed using
DROP VARIABLE.

The value of a schema variable is local to the current session.
Retrieving a variable's value returns either a NULL or a default
value, unless its value is set to something else in the current
session with a LET command. The content of a variable is not
transactional. This is the same as in regular variables in PL
languages.

Schema variables are retrieved by the SELECT SQL command. Their
value is set with the LET SQL command. While schema variables
share properties with tables, their value cannot be updated with
an UPDATE command.

The patch apply with the patch command without problem and
compilation reports no warning or errors. Regression tests pass
successfully using make check or make installcheck
It also includes all documentation and regression tests.

Performances are near the set of plpgsql variable settings which
is impressive:

do $$
declare var1 int ; i int;
begin
  for i in 1..1000000
  loop
    var1 := i;
  end loop;
end;
$$;
DO
Time: 71,515 ms

CREATE VARIABLE var1 AS integer;
do $$
declare i int ;
begin
  for i in 1..1000000
  loop
    let var1 = i;
  end loop;
end;
$$;
DO
Time: 94,658 ms

There is just one thing that puzzles me.We can use :

    CREATE VARIABLE var1 AS date NOT NULL;
    postgres=# SELECT var1;
    ERROR:  null value is not allowed for NOT NULL schema variable
"var1"

which I understand and is the right behavior. But if we use:

    CREATE IMMUTABLE VARIABLE var1 AS date NOT NULL;
    postgres=# SELECT var1;
    ERROR:  null value is not allowed for NOT NULL schema variable
"var1"
    DETAIL:  The schema variable was not initialized yet.
    postgres=# LET var1=current_date;
    ERROR:  schema variable "var1" is declared IMMUTABLE

It should probably be better to not allow NOT NULL when IMMUTABLE
is used because the variable can not be used at all.  Also
probably IMMUTABLE without a DEFAULT value should also be
restricted as it makes no sens. If the user wants the variable to
be NULL he must use DEFAULT NULL. This is just a though, the above
error messages are explicit and the user can understand what wrong
declaration he have done.

I wrote a check that disables this case.  Please, see the attached
patch. I agree, so this case is confusing, and it is better to disable it.

Great, I also think that this is better to not confuse the user.

    postgres=# CREATE IMMUTABLE VARIABLE var1 AS date NOT NULL;
    ERROR:  IMMUTABLE NOT NULL variable requires default expression

Working as expected. I have moved the patch to "Ready for committers".
Thanks for this feature.

--
Gilles Darold
http://www.darold.net/

Hi

Great, I also think that this is better to not confuse the user.

postgres=# CREATE IMMUTABLE VARIABLE var1 AS date NOT NULL;
ERROR: IMMUTABLE NOT NULL variable requires default expression

Working as expected. I have moved the patch to "Ready for committers".
Thanks for this feature.

Thank you very much

Pavel

Hi

fresh rebase

Regards

Pavel

[schema-variables-20210909.patch]

Hi Pavel,

The patch applies and compiles fine but 'make check' for the
assert-enabled fails on 131 out of 210 tests.

(while compiling HEAD checks run without errors for both assert-disabled
and assert-enabled)

Erik Rijkers

test tablespace ... ok 303 ms
parallel group (20 tests): oid char pg_lsn int2 varchar txid int4
regproc uuid float4 text name money boolean bit float8 int8 enum numeric
rangetypes
boolean ... ok 112 ms
char ... ok 57 ms
name ... ok 106 ms
varchar ... ok 74 ms
text ... ok 106 ms
int2 ... ok 73 ms
int4 ... ok 92 ms
int8 ... ok 130 ms
oid ... ok 55 ms
float4 ... ok 102 ms
float8 ... ok 126 ms
bit ... ok 124 ms
numeric ... ok 362 ms
txid ... ok 87 ms
uuid ... ok 100 ms
enum ... ok 142 ms
money ... ok 109 ms
rangetypes ... ok 433 ms
pg_lsn ... ok 64 ms
regproc ... ok 91 ms
parallel group (20 tests): lseg path circle time macaddr
create_function_0 timetz line macaddr8 numerology point interval inet
date strings polygon box multirangetypes timestamp timestamptz
strings ... ok 166 ms
numerology ... ok 89 ms
point ... ok 96 ms
lseg ... ok 35 ms
line ... ok 70 ms
box ... ok 255 ms
path ... ok 50 ms
polygon ... ok 237 ms
circle ... ok 53 ms
date ... ok 127 ms
time ... ok 60 ms
timetz ... ok 67 ms
timestamp ... ok 379 ms
timestamptz ... ok 413 ms
interval ... ok 97 ms
inet ... ok 118 ms
macaddr ... ok 60 ms
macaddr8 ... ok 80 ms
multirangetypes ... ok 307 ms
create_function_0 ... ok 63 ms
parallel group (12 tests): comments unicode misc_sanity tstypes xid
expressions horology geometry mvcc type_sanity regex opr_sanity
geometry ... ok 140 ms
horology ... ok 120 ms
tstypes ... ok 53 ms
regex ... ok 335 ms
type_sanity ... ok 155 ms
opr_sanity ... ok 355 ms
misc_sanity ... ok 43 ms
comments ... ok 20 ms
expressions ... ok 100 ms
unicode ... ok 25 ms
xid ... ok 56 ms
mvcc ... ok 146 ms
test create_function_1 ... ok 10 ms
test create_type ... ok 30 ms
test create_table ... ok 333 ms
test create_function_2 ... ok 11 ms
parallel group (5 tests): copydml copyselect insert_conflict insert copy
copy ... ok 336 ms
copyselect ... ok 34 ms
copydml ... ok 28 ms
insert ... ok 291 ms
insert_conflict ... FAILED (test process exited with
exit code 2) 239 ms
parallel group (3 tests): create_operator create_procedure create_misc
create_misc ... ok 131 ms
create_operator ... ok 29 ms
create_procedure ... ok 52 ms
parallel group (5 tests): create_view create_index_spgist
index_including create_index index_including_gist
create_index ... FAILED (test process exited with
exit code 2) 3801 ms
create_index_spgist ... ok 523 ms
create_view ... FAILED (test process exited with
exit code 2) 339 ms
index_including ... FAILED (test process exited with
exit code 2) 3801 ms
index_including_gist ... FAILED (test process exited with
exit code 2) 3801 ms
parallel group (16 tests): create_aggregate create_cast typed_table
drop_if_exists roleattributes create_am hash_func updatable_views errors
infinite_recurse create_function_3 triggers constraints select inherit
vacuum
create_aggregate ... FAILED (test process exited with
exit code 2) 164 ms
create_function_3 ... FAILED (test process exited with
exit code 2) 164 ms
create_cast ... FAILED (test process exited with
exit code 2) 164 ms
constraints ... FAILED (test process exited with
exit code 2) 181 ms
triggers ... FAILED (test process exited with
exit code 2) 181 ms
select ... FAILED (test process exited with
exit code 2) 181 ms
inherit ... FAILED (test process exited with
exit code 2) 181 ms
typed_table ... FAILED (test process exited with
exit code 2) 163 ms
vacuum ... FAILED (test process exited with
exit code 2) 180 ms
drop_if_exists ... FAILED (test process exited with
exit code 2) 163 ms
updatable_views ... FAILED (test process exited with
exit code 2) 163 ms
roleattributes ... FAILED (test process exited with
exit code 2) 163 ms
create_am ... FAILED (test process exited with
exit code 2) 163 ms
hash_func ... FAILED (test process exited with
exit code 2) 162 ms
errors ... FAILED (test process exited with
exit code 2) 162 ms
infinite_recurse ... FAILED (test process exited with
exit code 2) 162 ms
test sanity_check ... FAILED (test process exited with
exit code 2) 26 ms
parallel group (20 tests): select_into subselect select_distinct arrays
join namespace hash_index select_having portals transactions aggregates
random update delete union btree_index select_implicit
select_distinct_on prepared_xacts case
select_into ... FAILED (test process exited with
exit code 2) 20 ms
select_distinct ... FAILED (test process exited with
exit code 2) 21 ms
select_distinct_on ... FAILED (test process exited with
exit code 2) 26 ms
select_implicit ... FAILED (test process exited with
exit code 2) 26 ms
select_having ... FAILED (test process exited with
exit code 2) 23 ms
subselect ... FAILED (test process exited with
exit code 2) 20 ms
union ... FAILED (test process exited with
exit code 2) 25 ms
case ... FAILED (test process exited with
exit code 2) 27 ms
join ... FAILED (test process exited with
exit code 2) 22 ms
aggregates ... FAILED (test process exited with
exit code 2) 24 ms
transactions ... FAILED (test process exited with
exit code 2) 24 ms
random ... failed (ignored) (test process
exited with exit code 2) 24 ms
portals ... FAILED (test process exited with
exit code 2) 23 ms
arrays ... FAILED (test process exited with
exit code 2) 20 ms
btree_index ... FAILED (test process exited with
exit code 2) 25 ms
hash_index ... FAILED (test process exited with
exit code 2) 22 ms
update ... FAILED (test process exited with
exit code 2) 23 ms
delete ... FAILED (test process exited with
exit code 2) 24 ms
namespace ... FAILED (test process exited with
exit code 2) 21 ms
prepared_xacts ... FAILED (test process exited with
exit code 2) 25 ms
parallel group (20 tests): gist brin identity generated password
tablesample lock matview replica_identity rowsecurity security_label
object_address drop_operator groupingsets join_hash privileges collate
init_privs spgist gin
brin ... FAILED (test process exited with
exit code 2) 15 ms
gin ... FAILED (test process exited with
exit code 2) 22 ms
gist ... FAILED (test process exited with
exit code 2) 13 ms
spgist ... FAILED (test process exited with
exit code 2) 22 ms
privileges ... FAILED (test process exited with
exit code 2) 19 ms
init_privs ... FAILED (test process exited with
exit code 2) 21 ms
security_label ... FAILED (test process exited with
exit code 2) 17 ms
collate ... FAILED (test process exited with
exit code 2) 20 ms
matview ... FAILED (test process exited with
exit code 2) 17 ms
lock ... FAILED (test process exited with
exit code 2) 15 ms
replica_identity ... FAILED (test process exited with
exit code 2) 17 ms
rowsecurity ... FAILED (test process exited with
exit code 2) 17 ms
object_address ... FAILED (test process exited with
exit code 2) 17 ms
tablesample ... FAILED (test process exited with
exit code 2) 15 ms
groupingsets ... FAILED (test process exited with
exit code 2) 17 ms
drop_operator ... FAILED (test process exited with
exit code 2) 17 ms
password ... FAILED (test process exited with
exit code 2) 14 ms
identity ... FAILED (test process exited with
exit code 2) 13 ms
generated ... FAILED (test process exited with
exit code 2) 14 ms
join_hash ... FAILED (test process exited with
exit code 2) 18 ms
parallel group (2 tests): brin_multi brin_bloom
brin_bloom ... FAILED (test process exited with
exit code 2) 4 ms
brin_multi ... FAILED (test process exited with
exit code 2) 4 ms
parallel group (14 tests): async create_table_like collate.icu.utf8
misc sysviews alter_operator tidscan tidrangescan alter_generic tsrf
incremental_sort misc_functions tid dbsize
create_table_like ... FAILED (test process exited with
exit code 2) 10 ms
alter_generic ... FAILED (test process exited with
exit code 2) 15 ms
alter_operator ... FAILED (test process exited with
exit code 2) 13 ms
misc ... FAILED (test process exited with
exit code 2) 11 ms
async ... FAILED (test process exited with
exit code 2) 9 ms
dbsize ... FAILED (test process exited with
exit code 2) 17 ms
misc_functions ... FAILED (test process exited with
exit code 2) 14 ms
sysviews ... FAILED (test process exited with
exit code 2) 12 ms
tsrf ... FAILED (test process exited with
exit code 2) 14 ms
tid ... FAILED (test process exited with
exit code 2) 16 ms
tidscan ... FAILED (test process exited with
exit code 2) 13 ms
tidrangescan ... FAILED (test process exited with
exit code 2) 13 ms
collate.icu.utf8 ... FAILED (test process exited with
exit code 2) 9 ms
incremental_sort ... FAILED (test process exited with
exit code 2) 13 ms
parallel group (6 tests): amutils psql_crosstab collate.linux.utf8 psql
stats_ext rules
rules ... FAILED (test process exited with
exit code 2) 8 ms
psql ... FAILED (test process exited with
exit code 2) 7 ms
psql_crosstab ... FAILED (test process exited with
exit code 2) 7 ms
amutils ... FAILED (test process exited with
exit code 2) 7 ms
stats_ext ... FAILED (test process exited with
exit code 2) 8 ms
collate.linux.utf8 ... FAILED (test process exited with
exit code 2) 7 ms
test select_parallel ... FAILED (test process exited with
exit code 2) 3 ms
test write_parallel ... FAILED (test process exited with
exit code 2) 3 ms
parallel group (2 tests): publication subscription
publication ... FAILED (test process exited with
exit code 2) 4 ms
subscription ... FAILED (test process exited with
exit code 2) 4 ms
parallel group (17 tests): select_views foreign_key xmlmap window
functional_deps tsearch cluster combocid bitmapops tsdicts equivclass
guc indirect_toast advisory_lock foreign_data dependency portals_p2
select_views ... FAILED (test process exited with
exit code 2) 11 ms
portals_p2 ... FAILED (test process exited with
exit code 2) 20 ms
foreign_key ... FAILED (test process exited with
exit code 2) 11 ms
cluster ... FAILED (test process exited with
exit code 2) 15 ms
dependency ... FAILED (test process exited with
exit code 2) 19 ms
guc ... FAILED (test process exited with
exit code 2) 16 ms
bitmapops ... FAILED (test process exited with
exit code 2) 16 ms
combocid ... FAILED (test process exited with
exit code 2) 15 ms
tsearch ... FAILED (test process exited with
exit code 2) 14 ms
tsdicts ... FAILED (test process exited with
exit code 2) 16 ms
foreign_data ... FAILED (test process exited with
exit code 2) 17 ms
window ... FAILED (test process exited with
exit code 2) 12 ms
xmlmap ... FAILED (test process exited with
exit code 2) 12 ms
functional_deps ... FAILED (test process exited with
exit code 2) 13 ms
advisory_lock ... FAILED (test process exited with
exit code 2) 16 ms
indirect_toast ... FAILED (test process exited with
exit code 2) 16 ms
equivclass ... FAILED (test process exited with
exit code 2) 15 ms
parallel group (6 tests): json json_encoding jsonb jsonpath_encoding
jsonb_jsonpath jsonpath
json ... FAILED (test process exited with
exit code 2) 4 ms
jsonb ... FAILED (test process exited with
exit code 2) 6 ms
json_encoding ... FAILED (test process exited with
exit code 2) 5 ms
jsonpath ... FAILED (test process exited with
exit code 2) 10 ms
jsonpath_encoding ... FAILED (test process exited with
exit code 2) 6 ms
jsonb_jsonpath ... FAILED (test process exited with
exit code 2) 7 ms
parallel group (19 tests): plpgsql limit rowtypes sequence largeobject
returning domain polymorphism plancache prepare alter_table truncate
temp rangefuncs with copy2 conversion schema_variables xml
plancache ... FAILED (test process exited with
exit code 2) 16 ms
limit ... FAILED (test process exited with
exit code 2) 10 ms
plpgsql ... FAILED (test process exited with
exit code 2) 7 ms
copy2 ... FAILED (test process exited with
exit code 2) 25 ms
temp ... FAILED (test process exited with
exit code 2) 21 ms
domain ... FAILED (test process exited with
exit code 2) 13 ms
rangefuncs ... FAILED (test process exited with
exit code 2) 22 ms
prepare ... FAILED (test process exited with
exit code 2) 19 ms
conversion ... FAILED (test process exited with
exit code 2) 24 ms
truncate ... FAILED (test process exited with
exit code 2) 19 ms
alter_table ... FAILED (test process exited with
exit code 2) 18 ms
sequence ... FAILED (test process exited with
exit code 2) 11 ms
polymorphism ... FAILED (test process exited with
exit code 2) 13 ms
rowtypes ... FAILED (test process exited with
exit code 2) 10 ms
returning ... FAILED (test process exited with
exit code 2) 11 ms
largeobject ... FAILED (test process exited with
exit code 2) 10 ms
with ... FAILED (test process exited with
exit code 2) 22 ms
xml ... FAILED (test process exited with
exit code 2) 23 ms
schema_variables ... FAILED (test process exited with
exit code 2) 23 ms
parallel group (11 tests): explain hash_part partition_info reloptions
memoize compression partition_aggregate partition_join indexing
partition_prune tuplesort
partition_join ... FAILED 902 ms
partition_prune ... ok 1006 ms
reloptions ... ok 106 ms
hash_part ... ok 99 ms
indexing ... ok 929 ms
partition_aggregate ... ok 791 ms
partition_info ... ok 104 ms
tuplesort ... ok 1099 ms
explain ... ok 90 ms
compression ... ok 214 ms
memoize ... ok 109 ms
parallel group (2 tests): event_trigger oidjoins
event_trigger ... ok 107 ms
oidjoins ... ok 157 ms
test fast_default ... ok 138 ms
test stats ... ok 617 ms

Hi

čt 9. 9. 2021 v 12:21 odesílatel Erik Rijkers <er@xs4all.nl> napsal:

[schema-variables-20210909.patch]

Hi Pavel,

The patch applies and compiles fine but 'make check' for the
assert-enabled fails on 131 out of 210 tests.

This morning I tested it. I'll recheck it.

Pavel