Обсуждение: BUG #17476: ERROR: "variable not found in subplan target list" when running SELECT COUNT(*)

Поиск
Список
Период
Сортировка

BUG #17476: ERROR: "variable not found in subplan target list" when running SELECT COUNT(*)

От
PG Bug reporting form
Дата:
The following bug has been logged on the website:

Bug reference:      17476
Logged by:          Milos Urbanek
Email address:      milos.urbanek@email.cz
PostgreSQL version: 14.2
Operating system:   Windows 2012 R2 Foundation
Description:

Trying to run simple SELECT COUNT(*) from some table gives me the following
error (either running by hand or trying to run EXPLAIN using pgadmin or by
hand):

2022-05-09 00:06:30.428 CEST [1196] ERROR:  variable not found in subplan
target list
2022-05-09 00:06:30.428 CEST [1196] STATEMENT:  SELECT COUNT(*) FROM
"domino_efekty_havarijniprojev"
2022-05-09 00:06:31.884 CEST [1196] ERROR:  variable not found in subplan
target list
2022-05-09 00:06:31.884 CEST [1196] STATEMENT:  EXPLAIN (FORMAT JSON,
ANALYZE false, VERBOSE false, COSTS false, TIMING false, BUFFERS false,
SUMMARY false, SETTINGS false) SELECT COUNT(*) FROM
"domino_efekty_havarijniprojev"
2022-05-09 00:06:39.820 CEST [1196] ERROR:  variable not found in subplan
target list
2022-05-09 00:06:39.820 CEST [1196] STATEMENT:  EXPLAIN SELECT COUNT(*) FROM
"domino_efekty_havarijniprojev"

Differences against standard config:
shared_buffers = 8192MB
effective_cache_size = 16GB
cursor_tuple_fraction = 1.0


PG Bug reporting form <noreply@postgresql.org> writes:
> Trying to run simple SELECT COUNT(*) from some table gives me the following
> error (either running by hand or trying to run EXPLAIN using pgadmin or by
> hand):

> 2022-05-09 00:06:30.428 CEST [1196] ERROR:  variable not found in subplan
> target list
> 2022-05-09 00:06:30.428 CEST [1196] STATEMENT:  SELECT COUNT(*) FROM
> "domino_efekty_havarijniprojev"

Is that really just a table?  I could believe a bug like this for
some types of views, but it's a bit hard to credit for a plain table.

In any case, we can't do much with this report unless you can provide
a reproducer case --- preferably a SQL script that creates an object
that triggers the problem.

            regards, tom lane