вот тот, который залип — он уже есть в архиве. в логах есть записи об успешной архивации?

Говорю, он есть в архиве, но он какой-то битый, отличается по размеру.

У меня есть подозрение, что в этом виноват Commvault, который бэкапит и удаляет wal-архивы. Но нужна фактура. Пока это лишь подозрения.

Помогите пожалуйста:
DECLARE did integer;
BEGIN
INSERT INTO "Deals" (status) VALUES ('inprocess') RETURNING id as did;
INSERT INTO "Requests" VALUES (did, customer_id, service_id, NOW());
END

Выдает ошибку:
ERROR:  query has no destination for result data
CONTEXT:  PL/pgSQL function newrequest(integer,integer) line 3 at SQL statement
SQL state: 42601

На стаке только по функциям. Да и черт знает, что тут возвращать

есть 3 варианта, если обязательно цену со скидкой надо хранить, то триггер,
либо проще сделать view где будет join этих 2 таблиц и поле, где будет на лету вычисляться скидка.
3-й вариант материализованная view,но это экзотика.

первый INSERT возвращает данные, но они никуда не направляются/присваиваются

Не понимаю, как это поправить?

Или надо присвоить без возврата?

вот тот, который залип — он уже есть в архиве. в логах есть записи об успешной архивации?

я бы либо воспользовался готовой утилитой: pgbackrest, wal-g, barman
либо дописал бы скрипт так, чтобы он успешные попытки архивации также бы логгировал

With (insert returning) as foo insert into... Select foo.did, ...

^ там даже лучше описано)

Ну, СРК у нас продиктовано сверху. Используем его. И в целом оно нас устраивает, если бы не эти мелкие косяки.
Так что, хотелось бы разобраться с проблемой.

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

А cp между разными файловыми системами?

Ну, я про соседнюю папку на одной ФС

Да, пожалуй вариант с

mv

первое что стоит попробовать, даже не углубляясь

Если это нужно делать многократно (и хочется сильно ускорить) — можно переписать запрос с использованием loose indexscan.  Но для этого, на первый взгляд, понадобится как минимум индекс по (devtodev_id, action_date).
См. http://wiki.postgresql.org/wiki/Loose_indexscan

Спасибо, сейчас почитаю

а вот на action_date или на action_tdate?

На action_date — у Вас же именно он используется в запросе:

SELECT mx.devtodev_id, MAX(mx.action_tdate) AS last_action_tdate
  FROM core_data.level_start_tbl AS mx
 WHERE mx.action_date BETWEEN '2020-05-01' AND '2020-05-27'
 GROUP BY mx.devtodev_id

SELECT mx.devtodev_id, MAX(mx.action_tdate) AS last_action_tdate
  FROM core_data.level_start_tbl AS mx
 WHERE mx.action_date BETWEEN '2020-05-01' AND '2020-05-27'
 GROUP BY mx.devtodev_id

а кините ссылкой, я вот не могу понять, когда происходит агрегация как в данном запросе
лучший индекс это получается на devtodev_id и action_date.
А что происходит в этот момент для MAX(mx.action_tdate).

Я к тому имеет и разница что находится внутри агрегатной функции?
если б было

SELECT mx.devtodev_id, MAX(

1

) AS last_action_tdate
  FROM core_data.level_start_tbl AS mx
 WHERE mx.action_date BETWEEN '2020-05-01' AND '2020-05-27'
 GROUP BY mx.devtodev_id

Это что-то изменило б?

Спасибо