трах-тибидох-тах-тах!
ERROR: ExecutePlan: (junk) `ctid' is NULL!
трах-тибидох-тах-тах!

UPDATE t_values
SET value=COALESCE(Sum(value),0)
WHERE tid=-1000000000;
ERROR: ExecutePlan: (junk) `ctid' is NULL!

што ему не нравится!!!
SELECT * from t_values WHERE tid=-1000000000; (пусто)

Select COALESCE(Sum(value),0) from t_values WHERE tid=-1000000000;
! 0 (- !!! значение возвращаю не null, стал быть не это???)

UPDATE t_values
SET value=1 /* COALESCE(Sum(value),0) */
WHERE tid=-1000000000;
!!! отрабатывает (как и должен - нет записей - не его собачье дело)

- Или я же еще и обязан проверить, а не загнется ли он при запросе от своего унутреннего несовершенства? ("буквы так и лезли из него, но все непечатные")

?Что я делаю не так? Что делать? Как быть? (Кто виноват?)
__
SELECT version();
PostgreSQL 7.3.4 on i386-unknown-freebsd5.1, compiled by GCC gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release)

спасибо, но:

UPDATE t_values
SET value=1 /* COALESCE(Sum(value),0) */
WHERE tid=-1000000000;

- работает. т.е. причина идентифицирована - Sum(value), при отсутствии записей в наборе. COALESCE не спасает.

из системных вижу:
tableoid
cmax
xmax
cmin
xmin
ctid /* именно тут мы ругаемся?

-и все.

если записи в наборе есть, - то ошибки нет . Но запрос не "реальный". - Так, - моделька, полученная усечением того, что нужно. (как пробило на ошибку, так и начал отбрасывать "лишнее"). GROUP BY нужна была бы, если выводить поля, по которым НЕ выводятся агрегаты - тогда именно по ним и нужен GROUP BY. А соображение, что "Постгрес можно обвинить только в том, что сообщение об ошибке непонятное" в данном случае равно не вьезжанию в природу SQL :0) . Прошу простить за резкость :0). Но в данном случае не работает SUM() по пустому множеству. При не пустоте, оно срабатывает. Вот и все. Т.ч. постгресс облажался :0). Правда я "вдруг" понял, что ТАК мне, собственно, и не надо. И сделал иначе. Там ошибка не выскакивает. Но осадочек-с остается.

НУ вот, подвигли на иллюстративный прогон:

/*
UPDATE t_values
SET value=COALESCE(Sum(value),0)
WHERE tid=-1000000000;
*/
/*
ERROR: ExecutePlan: (junk) `ctid' is NULL!
*/
/*
SELECT * from t_values WHERE tid=-1000000000;
row number -1 is out of range 0..-1
Суммарное время выполнения запроса:63 ms.
Время получения данных:31 ms.
получено строк: 0
*/
НО !
/*
SELECT COALESCE(Sum(value),0) from t_values WHERE tid=-1000000000;
Суммарное время выполнения запроса:47 ms.
Время получения данных:0 ms.
получено строк: 1
*/
/*
UPDATE t_values
SET value=(SELECT COALESCE(Sum(value),0) from t_values WHERE tid=-1000000000)
WHERE tid=-1000000000;
Запрос успешно завершён без результата возврата за 47 мс.
*/
это была просто иллюстрация к "обходу бзика"
А вот это уже интересно:
/*
UPDATE t_values
SET value=COALESCE(Sum(value),0)
WHERE tid=6;
Запрос успешно завершён без результата возврата за 78 мс.
*/
/*
SELECT COALESCE(Sum(value),0) from t_values WHERE tid=6;
Суммарное время выполнения запроса:47 ms.
Время получения данных:0 ms.
получено строк: 1
*/

PS: т.е. на лицо явный таракан в 7.3.х. А "непонятная ошибка" - это - "кишки наружу" (проявление бага во внутренней кухне постгресса).

тьфу, зарапортавался.
- вот вместо последнего запроса в предыдущем посте:

SELECT * from t_values WHERE tid=6;
/*Суммарное время выполнения запроса:63 ms.
Время получения данных:15 ms.
получено строк: 2
*/

все оказалось много гаже :0))))

Проблема в ПРИНЦИПЕ. Если я имею запрос в триггере (на каждую запись). А он вдруг у меня выдает ЕРРОР при некоторых выпаданиях параметров, и именно из-за кривых кишок инструмента, то это уже ПРОБЛЕМА. Вот собсна и все. Еще раз повторю: у Вас есть триггер, который обновляет некоторые данные в другой таблице(не tid=-1000000000 , а tid={входные данные}, причем если синтаксис позволяет писать агрегаты в теле UPDATE, то агрегаты считаются по тем записям, которые входят в набор отфильтрованный предложением FROM (что проверено), например:
но тут начинается полная каша - обновляются НЕ ВСЕ записи с данным tid!!! (но число считается верно!!!)
но!!!
!
далее уменьшу число записей, выставлю value в 0 и запущу запрос несколько раз
!!!
что забавно - находит каждый раз для обновления новую запись (а не все из фром)!!! но считает каунт именно из того ФРОМ, которое и стоит в запросе.

Ну, и, ебстественно, агрегат Count() ничем не отличается от агрегата Sum()

UPDATE t_values
SET value=COALESCE(Count(*),0)
WHERE tid=-1;
ERROR: ExecutePlan: (junk) `ctid' is NULL!

_________________________________________________________________
>>>>> если же вопрос о том, что нужно мне, то, в данном случАе мне, как я уже говорил, потребовалось нечто иное, наподобие:

UPDATE t_values SET
value=sv
FROM (
SELECT COALESCE(Sum(t.value),0) as sv
...
FROM t_values AS t INNER JOIN tree ON t.tid = tree.id
WHERE tree.id=cid AND t.tid=cid
GROUP BY ... ) AS q
WHERE (t_values.amonth = q.amonth) AND ...;
но это уже не имеет отношения к теме.

Интересное поведение UPDATE даже без группировочных функций!!!
(Перетаскиваю приладу с 7.0 на 7.3.4.)

запрос вида (генерится приладой):

вылетает по таймауту. При запуске из-под pgAdmina я прождал 30 сек. Отрубил сам.

Проверяю:
row number -1 is out of range 0..-1
Суммарное время выполнения запроса:828 ms.
Время получения данных:156 ms.
получено строк: 0

долговато :), но в 1 сек. укладываюсь :)
Т.е. при отсутствии подходящих предложению FROM записей мы улетели в бесконечность по временивыполнения.

Для пробы переписываю:

Запрос успешно завершён без результата возврата за 93 мс.
все работает!
и даже быстрее чем простой селект:
row number -1 is out of range 0..-1
Суммарное время выполнения запроса:640 ms.
Время получения данных:16 ms.
получено строк: 0


Ставлю комментарий:

опять улетаю на бесконечность

Вспоминаю, что уже переписывал синтаксис, и все работало , только на базе с созданными по умолчанию oid -ами. Запускаю первый запрос там - "опять все работает" : Запрос успешно завершён без результата возврата за 219 мс.

"Будь проклят тот день, когда я сел за баранку...." :(

Резюме:
1. oid в явном виде используются во внутренней реализации процедур выполнения запросов. Надеятся на собственные уникальные ключи (особенно из нескольких полей) вряд ли стоит. (вероятно - ошибка в реализации логики). Выбрасывать oid при конструировании крайне рискованно.
2. никто не гарантирует, что работавший на некотором наборе данных запрос не загнется при неопределенных обстоятельствах.

Вопрос: Есть ли еще какие "эмпирические правила", придерживаясь которых можно не натыкаться на дыры в реализации?

Я тут обнаружил, что в той схеме с oid-ами, в которую все вставилось, аккурат в таблице leaf_heap (в единственной) oid-ов то и нет (успел уже когда-то отредактировать). Перепугалси, что вру и об остальном (типа - триггерков каких кривых насобачил, а людям вру). Создал копию дампа схемы БД без оидов (в которой был глюк), поменял строки without oids на with oids, поднял (со всеми ф-ями и триггерками). Влил данные. Запустил запрос (1). Работает. Запустил в старой (нет оидов ни в одной таблице) - не работает (уходит в задумчивость).

часть схемы примерно такая:

CREATE TABLE public.leaf
(
id int4 NOT NULL,
aid int4,
company int4,
kind int4 NOT NULL,
date int4,
name varchar(128),
description varchar(128),
search_name varchar(128),
leaf_from int4 DEFAULT 0,
leaf_to int4 DEFAULT 0,
currency int4,
value float8,
payment_kind int4 DEFAULT 0,
planfact int4,
CONSTRAINT leaf_pkey PRIMARY KEY (id),
CONSTRAINT company_leaf FOREIGN KEY (company) REFERENCES public.company (id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT tl_id FOREIGN KEY (id) REFERENCES public.tree (id) ON UPDATE RESTRICT ON DELETE RESTRICT
) WITHOUT OIDS;

CREATE TABLE public.leaf_heap
(
id int4,
company int4 NOT NULL,
status int4 NOT NULL,
aid int4 NOT NULL,
kind int4 NOT NULL DEFAULT 0,
date int4,
name varchar(128),
description text,
search_name varchar(128),
currency int4,
value float8,
payment_kind int4,
planfact int4 DEFAULT 2,
orgto varchar(15),
orgfr varchar(15),
corgto int4,
corgfr int4,
subdsss varchar(18),
subksss varchar(18),
changed int4 DEFAULT 0,
CONSTRAINT leaf_heap_pkey PRIMARY KEY (company, aid, status),
CONSTRAINT company_leaf_heap FOREIGN KEY (company) REFERENCES public.company (id) ON UPDATE CASCADE ON DELETE CASCADE
) WITHOUT OIDS;

CREATE TABLE public.tree
(
id int4 NOT NULL DEFAULT nextval('tree_id_seq'::text),
pid int4 NOT NULL,
pos int4 NOT NULL,
uname_create varchar(8),
uname_modify varchar(8),
date_create int4,
date_modify int4,
status int4 NOT NULL,
uid int2,
gid int2,
rights int2,
CONSTRAINT tree_pkey PRIMARY KEY (id),
CONSTRAINT pid FOREIGN KEY (pid) REFERENCES public.tree (id) ON UPDATE CASCADE ON DELETE CASCADE
) WITHOUT OIDS;

Почему связь (tree-leaf) 1:1 - не ко мне. :) В описаном случае есть еще тригерок в tree, ( в обеих схемах ес-сно один).

НО! (удивительное рядом) создал копию без данных - запрос выполняется махом. На всякий случай сделел копию с данными - такой же висяк. (вчера поднимались тудыть данные из дампа (без схемы) 7.0. Может какие баги в данных?). Будет время - будем мало-мало посмотреть. (Пока вариант с оидами вроде как работает - некогда упираться рогом).

видимо проблема где-то в заливке данных подъемом дампа. Удалил данные из leaf_heap (буферная корзина) в копии (без оидов), и с теми же данными в остальных все зашуршало. (!но в корзинку-то, данные и не переносили! это я потом их туда внешним приложением накидал. которое и уткнулось в проблему.).

В механизме подъема дампа только данных в схему с ограничениями нет ли каких хитростей? Может какое-нить "последействие" не устранившееся?

ничего не понимаю.

в части поста [446797] заявляю: его выводы (скорее всего) неверны. Проблема не в наличии/отсутствии оидов.

(был непроспамши, заработамши, отупемши. и вапше - глюп и недалек. сыплю пепел голова.)

В чем была проблема и появится ли она снова выяснить не могу - в оригинале базы, демонстрирующей аномалии провел VACUUM FULL (в синтаксисе 7.0 FULL отсутствовал, выполнялся только VACUUM ANALYZE;), глюки пропали, а вместе с ними и шаблон (точнее - его аномальность), из которого я мог делать глючные копии комадой CREATE DATABASE name TEMPLATE [=] template.


Теперь сижу весь из себя в задумчивости - выбрасывать оиды при наличии собственного ключа, или нет. (А вдрух?).
_____

2Sad Spirit: нет ли рекомендаций по рекурсивным вызовам функций (или видов, или аналогичным технологиям обсчета деревьев без излишней "денормализации" базы)?