привет. подскажите пожалуйста, такая проблема: есть таблица, допустим CREATE TABLE t (id int PRIMARY KEY, parent int NULL, CONSTRAINT fk FOREIGN KEY parent REFERENCES t (id) я вставляю пачку строк одним запросом INSERT, допустим там есть строки id = 1, parent = null и id = 2, parent = 1. в итоге в базе у второй строки parent оказывается NULL если убрать constraint, то все ок. это можно как-то исправить не убирая внешний ключ?

а можно сам запрос? его не генерит ORM часом?

я через sqlalchemy, но запрос точно один table.insert().values([{'id': 1, 'parent': None}, {'id': 2, 'parent': 1}]) что-то такое получается

а покажи, что она генерит

В PostgreSQL v12 возможно будет select from DUAL ? https://www.postgresql.org/message-id/flat/CAFjFpRdHJbM2EgDng2NgMLkXWD2bYrKhZPchsFj8r4PcVW2E5g%40mail.gmail.com#CAFjFpRdHJbM2EgDng2NgMLkXWD2bYrKhZPchsFj8r4PcVW2E5g@mail.gmail.com

Мне показалось, что речь не SELECT FROM DUAL, а о том чтобы у SELECT без FROM генерировалась RTE. А для пользователя ничего не изменится при этом.

у меня реальная таблица с кучей столбцов и вставляется сразу 800 строк...

щас попробую минимальный пример соорудить

Мне показалось, что речь не SELECT FROM DUAL, а о том чтобы у SELECT без FROM генерировалась RTE. А для пользователя ничего не изменится при этом.

Да, там в сообщении про это. Но заголовок написан так, что, кажется, внутренними изменениями может не закончится.

Да, заголовок, как говорится, по Фрейду :)

а покажи, что она генерит

>>> str(t.insert().values([{'id': 1, 'parent': None}, {'id': 2, 'parent': 1}]).compile(dialect=postgresql.dialect())) 'INSERT INTO t (id, parent) VALUES (%(id_m0)s, %(parent_m0)s), (%(id_m1)s, %(parent_m1)s)'

>>> str(t.insert().values([{'id': 1, 'parent': None}, {'id': 2, 'parent': 1}]).compile(dialect=postgresql.dialect())) 'INSERT INTO t (id, parent) VALUES (%(id_m0)s, %(parent_m0)s), (%(id_m1)s, %(parent_m1)s)'

тут не хватает значений

Ну так значения 1, null, 2, 1

%(parent_m1)s говорит, что над массивом диктов происходили какие-то преобразования

покажи то, откуда берётся ключ parent_m1

есть какие-то существенные причины почему так не стоит делать?

вот главный и правильный вопрос. так и правда нельзя делать в одной транзакции

Ладно, я попробую сделать минимальный воспроизведимый пример и приду снова

покажи то, откуда берётся ключ parent_m1

его еще нету. топикстартер хочет за один раз вставить обе записи

уфф... кажется закончил :)

резюмирую

Использование pgpool имеет смысл только в связке с PGBOUNCER

в противном случае - адский жор коннектов вам обеспечен

его еще нету. топикстартер хочет за один раз вставить обе записи

Да, именно это и хочу. Почему так нехорошо-то? :)

его еще нету. топикстартер хочет за один раз вставить обе записи

мы видим темплейт sql-я, но не видим подставляемые в этот темплейт значения

@Komzpa внимательнее )

привет. подскажите пожалуйста, такая проблема: есть таблица, допустим CREATE TABLE t (id int PRIMARY KEY, parent int NULL, CONSTRAINT fk FOREIGN KEY parent REFERENCES t (id) я вставляю пачку строк одним запросом INSERT, допустим там есть строки id = 1, parent = null и id = 2, parent = 1. в итоге в базе у второй строки parent оказывается NULL если убрать constraint, то все ок. это можно как-то исправить не убирая внешний ключ?

>если убрать constraint, то все ок

Я генерирую пачку записей, глубина ссылок на себя может быть и больше 1. Не хочу в своём коде делить на уровни (хотя и могу)

>если убрать constraint, то все ок

я видел разную магию на алхимии. убрать констрейнт в её описании или в базе?

Я генерирую пачку записей, глубина ссылок на себя может быть и больше 1. Не хочу в своём коде делить на уровни (хотя и могу)

Что мешает использовать COPY?

я видел разную магию на алхимии. убрать констрейнт в её описании или в базе?

Alter table drop constraint

Руками в базу

Что мешает использовать COPY?

Тогда надо сначала в памяти сгенерировать csv, а потом скормить его в базу? Правильно я понимаю?

да

Что мешает использовать COPY?

впишется в констрейнт как надо?

да, и столько же иопсов съедено

эм, оно же через файловый кеш, до иопсов дело может не дойти

впишется в констрейнт как надо?

А фиг его знает. Но когда я вижу инсёрт одной командой и больше одной строки, у меня всегда возникает этот вопрос.

да брось! многострочный insert - это же так весело! ;)

user=> \d t001 Table "user.t001" Column | Type | Collation | Nullable | Default -----------+---------+-----------+----------+--------- id | integer | | not null | parent_id | integer | | | Indexes: "t001_pkey" PRIMARY KEY, btree (id) Foreign-key constraints: "fk" FOREIGN KEY (parent_id) REFERENCES t001(id) Referenced by: TABLE "t001" CONSTRAINT "fk" FOREIGN KEY (parent_id) REFERENCES t001(id) user=> ^Z user@host:~$ echo -e "1\tNULL\n2\t1"|psql -c "COPY t001 FROM STDIN WITH NULL 'NULL';" COPY 2 user@host:~$ fg psql user=> select * from t001 ; id | parent_id ----+----------- 1 | 2 | 1 (2 rows) user=> жЫзнь - боль и страдание, унижение и отчаяние.

да брось! многострочный insert - это же так весело! ;)

особенно сформированный ОРМ-ом, ага. :D Модно, задорно, молодёжно!

Если функция возвращает SETOF record который формируется исключительно на основе её параметров (JSON), то её можно отметить как IMMUTABLE?

Если функция возвращает SETOF record который формируется исключительно на основе её параметров (JSON), то её можно отметить как IMMUTABLE?

Да.

Спасибо! Кто pgAdmin4 использует? Часто у вас он падает?

А если функция возвращает результат в OUT параметры, её тоже можно/нужно отмечать как IMMUTABLE когда при одних и тех же входных параметрах в OUT будет тоже самое?

через консоль так же?

ещё. Из документации PostgreSQL requires that STABLE and IMMUTABLE functions contain no SQL commands other than SELECT to prevent data modification. А если создаются временные таблицы?

через консоль так же?

Разобрался, спасибо

ещё. Из документации PostgreSQL requires that STABLE and IMMUTABLE functions contain no SQL commands other than SELECT to prevent data modification. А если создаются временные таблицы?

нет. но при должном упорстве можно завернуть в immutable что угодно

Сейчас проводил тесты по обновлению постгреса на новую версию с использованием хардлинков (`pg_upgrade -k`) Делал на бинарной реплике, остановил, сделал upgrade на новую версию при выполнении vacuumdb --all --analyze-in-stages ошибка ERROR: MultiXactId 1159414 has not been created yet -- apparent wraparound vacuum вызвал кучу сообщений вида WARNING: page is not marked all-visible but visibility map bit is set in relation "some_table" page 105805

да, перед выполнением не промоутил до мастера. Во второй раз запромоутил и все обновилось без проблем. В связи с чем вопрос: является ли допустимым бинарное обновление постгреса, если старый постгрес не переведен в режим мастера? И если нет, то почему pg_upgrade не отругивается?

Чёртовы майнеры. Эти сукины сыны научились прятаться даже там. http://www.opennet.ru/opennews/art.shtml?num=48269

"Джонни!.."

Чёртовы майнеры. Эти сукины сыны научились прятаться даже там. http://www.opennet.ru/opennews/art.shtml?num=48269

Не светить postgresql наружу

А какого хрена у postgres вообще пароль есть?

Он же беспарольный по умолчанию

Пароль есть, когда сервер баз данных отдельно от сервера приложений живёт

Пароль есть, когда сервер баз данных отдельно от сервера приложений живёт

Ну да, и пусть себе живет только во внутренней сети

А что, если ее нет?

А что, если ее нет?

Шо, таки прям ПГ наружу?! иптаблесами и пг_хба прикрыть доступ только из откедова можно.

Пароль есть, когда сервер баз данных отдельно от сервера приложений живёт

На юзера postgres? Зачем??

У меня наружу торчит, но с ssl

С валидным сертификатом

Шо, таки прям ПГ наружу?! иптаблесами и пг_хба прикрыть доступ только из откедова можно.

Еще knockd есть

У меня наружу торчит, но с ssl

Безопасно, но чуть заморочливее, чем разрешить порт только для белых ip

Безопасно, но чуть заморочливее, чем разрешить порт только для белых ip

На той стороне может быть динамический ip

На той стороне может быть динамический ip

Тогда vpn во внутреннюю сеть

Тогда vpn во внутреннюю сеть

Тут как раз больше заморочек, некоторые говнороутеры не могут пропускать gre, некоторые говнопровайдеры могут не пропускать gre..

На юзера postgres? Зачем??

А кто базы создавать будет?

А кто базы создавать будет?

Суперпользователь

не postgres

Он есть и его зовут postgres!

Зачем ещё один?

А второго создать кто мешает?

А кем?

Postgres'ом, один раз, при инсталляции

А как потом вспомнить имя этого пользователя?

Хороший вопрос.. у меня чет такой проблемы не возникало..

Записать в блокнот?

cat create_db.sql | ssh dbhost sudo -iu postgres psql

А кто базы создавать будет?

Это вот на вопрос, кто базы создавать будет

Это вот на вопрос, кто базы создавать будет

Админ один раз установил и ссх никому не даст

Админ один раз установил и ссх никому не даст

Нет в мире счастья, а в жЫзни совершенства.

А как потом вспомнить имя этого пользователя?

а как вспомнить пароль от постгреса

а как вспомнить пароль от постгреса

а зачем?

а как вспомнить пароль от постгреса

Он как в переговорке, 12345

но вообще конечно слабовата тема для пятничного срача

А если серьёзно, то такому админу надо популярно объяснить, что ПГ - это не оракел. И если он хочет проблем с ПГ из-за наличия в оном уязвимостей, то пусть продолжает дальше не давать ssh. Либо пусть организовывает беспроблемный ВПН.

надо чтото получше придумать