@ccxccxcg: user has been CAS banned

Господа, столкнулся с неочевидной проблемой, есть 2 устройства - на маке и убунту, есть база данных, для доступа к которой поднимается ssh-туннель и она становится доступна на локалкхосте на порту 5432. Так вот, если я всё проделываю на убунту - то я без проблем получаю доступ к базе, однако, с мака при использовании всё тех же параметров, при поднятии такого же туннеля, я ловлю ошибку аутентификации
psql: FATAL:  password authentication failed for user "db_user"
если честно - то ума не приложу в чем может быть проблема, никто не сталкивался?

кодировка локали?

всё вставляется копипастом

Попробуйте аккуратно ручками набрать явки/пароли.

NEW.a = (SELECT ...)

например. Или INTO.

NEW.a = (SELECT ...)

спасибо

Вот пример, прошу прощения, что долго не отвечал, сам не мог проверить, занят был, а коллеги оперативно данные предоставить не смогли..

План на удаленной машине.. из под пользователя, в который происходит маппинг.

QUERY PLAN
---------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=8164774.32..11236955.67 rows=10939253 width=16)
   Group Key: task_id
   ->  Gather Merge  (cost=8164774.32..11018170.61 rows=21878506 width=16)
         Workers Planned: 2
         ->  Partial GroupAggregate  (cost=8163774.29..8491848.13 rows=10939253 width=16)
               Group Key: task_id
               ->  Sort  (cost=8163774.29..8236668.06 rows=29157508 width=16)
                     Sort Key: task_id
                     ->  Parallel Seq Scan on crm_task_history  (cost=0.00..3053732.08 rows=29157508 width=16)
                           Filter: (new_status_id = 2)

План на локальной.
QUERY PLAN

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------
Nested Loop  (cost=8132841.20..11708150.35 rows=1 width=12)
  Output: "3291".deal_id, ((min("3292".created_at)) + CASE WHEN ("3291".created_at > '2019-06-26 10:52:00'::timestamp without time zone) THEN '00:00:00'::interval ELSE '03:00:00'::interval END)
  ->  Foreign Scan  (cost=8132740.63..11708041.72 rows=1 width=16)
        Output: "3292".task_id, (min("3292".created_at))
        Relations: Aggregate on (private."3292")
        Remote SQL: SELECT task_id, min(created_at) FROM public.crm_task_history WHERE ((new_status_id = 2)) GROUP BY 1
  ->  Foreign Scan on private."3291"  (cost=100.57..108.61 rows=1 width=16)
        Output: "3291".id, "3291".crm_deal_id, "3291".person_id, "3291".task_type_id, "3291".status_id, "3291".active, "3291".created_at, "3291".updated_at, "3291".cas_user_id, "3291".description, "3291".deal_id, "3291".plan_date, "3291".task_data, "3291".crm_activity_id, "3291".priority, "3291".closed_at_session_id, "3291".terbank_id, "3291".queue_id, "3291".is_training, "3291".service_line, "3291".closed_at, "3291".tz
        Remote SQL: SELECT id, created_at, deal_id FROM public.crm_task WHERE ((task_type_id = 230)) AND (($1::bigint = id))
(9 rows)

QUERY PLAN
---------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=8164774.32..11236955.67 rows=10939253 width=16)
   Group Key: task_id
   ->  Gather Merge  (cost=8164774.32..11018170.61 rows=21878506 width=16)
         Workers Planned: 2
         ->  Partial GroupAggregate  (cost=8163774.29..8491848.13 rows=10939253 width=16)
               Group Key: task_id
               ->  Sort  (cost=8163774.29..8236668.06 rows=29157508 width=16)
                     Sort Key: task_id
                     ->  Parallel Seq Scan on crm_task_history  (cost=0.00..3053732.08 rows=29157508 width=16)
                           Filter: (new_status_id = 2)

Да, странно.
А EXPLAIN для "SELECT task_id, min(created_at) FROM public.crm_task_history WHERE ((new_status_id = 2)) GROUP BY 1;" отсылается туда в процессе планирования (Есть в логах? А пользователь точно тот?)?

да, в процессе планирования запрос отсылается, в логах пачка разных разных explain, один из них он. По поводу пользователя - точно, я раньше смотрел из под разных, поэтому когда вы сказали, что стоит проверить от одного - это было важной частью, на которую я обратил внимание..

А версии PostgreSQL (полные) какие?

локальная
PostgreSQL 11.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit

удаленная
PostgreSQL 10.4 (Debian 10.4-2.pgdg90+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit

А со времён 10.4 никаких связанных с FDW bugs не исправляли, Вы не смотрели (мало ли)?
Хотя вот тут https://why-upgrade.depesz.com/show?from=10.4&to=10.13 из хоть как-то похожего я вижу только вот это:

Avoid crash in contrib/postgres_fdw when a query using remote grouping or aggregation has a SELECT-list item that is an uncorrelated sub-select, outer reference, or parameter symbol

А Вы можете показать скрипты создания / настройки этого FDW (особенно интересуют fdw_startup_cost и fdw_tuple_cost — непонятна разница в cost-ах remote и в основном плане)?
Да и вообще попробовать какие-нибудь remote estimations — что-то там в плане везде "rows=1", что странно.

Avoid crash in contrib/postgres_fdw when a query using remote grouping or aggregation has a SELECT-list item that is an uncorrelated sub-select, outer reference, or parameter symbol

я целенаправленно не смотрел, но переодически в принципе смотрю, что меняется от версии к версии, вроде не помню. как вообще возник вопрос, сама локальная база постгрес была версии 9.6, соответственно решили обновить, обновили на стенде и получили огромную разницу в скорости выполнения запросов, оно и понятно в 9.6 не было push down, но когда начали смотреть, а в чем собстенно разница и как сделать так, чтобы все было хорошо - вот это поведение и нашли.
Тут как раз все параметры дефолтные, как из коробки идут, с ними даже не играли, т.к. в принципе все устраивало, а на более тонкий тюнинг времени не было. Но конкретно в кейсе, о котором я говорю - мы в принципе в силах поменять версию на удаленной машине.. У нас так выстроена система, что такая возможность есть.. Ну если вдруг интересно, что, как и зачем, то это наверное, лучше в личке..

А есть ли гдето описание формата PGOPTIONS?

> обновили на стенде
> мы в принципе в силах поменять версию на удаленной машине..

Ну так и почему remote — не последняя minor version (вот Вы сейчас сидите и думаете, а возможно, это просто bug, и решить это можно было обновлением за пять минут)? ;)

> Тут как раз все параметры дефолтные, как из коробки идут, с ними даже не играли

use_remote_estimate=true — это не default. ;) Я это вот к чему:
Оценка раз:

Finalize GroupAggregate  (cost=8164774.32..11236955.67 rows=10939253 width=16)

И оценка два:

Foreign Scan  (cost=8132740.63..11708041.72 rows=1 width=16)

Тут вообще оценки не совпадают — foreign scan startup дешевле, чем на remote (такого не должно быть, насколько я помню... разве что там данные активно меняются)!
И полные оценки стоимости исполнения тоже отличаются на непонятную величину (11708041.72 - 11236955.67) = 471086.05 — это вообще ни на что не похоже.

Если для себя - можно просто забрать у всех пользователей права на внесение изменений в таблицы. Доступ к заполнению и изменению организовать через пользовательские функции. И бизнес логику написать как хотите. Будет API на уровне БД с разграничениями доступа по ролям.

только задолбаешься с всякими пулами

роли прописывать