Я в жизни максимум repeatable read использовал.

Так, а сериалайзабл заканчиывется с ошибкой в случае, если разный порядок одноврменно выполняемых транзакции даёт разный результат?

Или постгрес добивается просто любого порядка транзакции?

Так, а сериалайзабл заканчиывется с ошибкой в случае, если разный порядок одноврменно выполняемых транзакции даёт разный результат?

Заканчивается с ошибкой.

Так, а сериалайзабл заканчиывется с ошибкой в случае, если разный порядок одноврменно выполняемых транзакции даёт разный результат?

Если он может дать разный результат — да, одна из транзакций получает ошибку сериализации (и откатывается, в норме). Кстати, в некоторых случаях, ошибка выдаётся и в тех случаях, когда на самом деле всё было бы хорошо, т.е. есть false positives.

Или постгрес добивается просто любого порядка транзакции?

Вообще — да, разумеется (это определение serializable).

Ага, тогда в случае с мастер-слейв и сериалазбл придумается простой пример, когда не понятно, что делать, ведь на каком-то из slave-ов может запрос привести к ошибке.

Вообще — да, разумеется (это определение serializable).

Блин, под "разумеется" имелось ввиду, что любой порядок должен приводить к одинаковому исходу или выбирается какой-то порядок произвольный?

Ага, тогда в случае с мастер-слейв и сериалазбл придумается простой пример, когда не понятно, что делать, ведь на каком-то из slave-ов может запрос привести к ошибке.

Как это вам удалось придумать простой пример, когда у computer scientists это заняло не одно десятилетие?! ;) (Напоминаю, slave — read-only).

Как это вам удалось придумать простой пример, когда у computer scientists это заняло не одно десятилетие?! ;) (Напоминаю, slave — read-only).

Тогда нужно ответить всё-таки ещё раз на вопрос с порядком в сериалайзбл

Блин, под "разумеется" имелось ввиду, что любой порядок должен приводить к одинаковому исходу или выбирается какой-то порядок произвольный?

Для serializable достаточно достижения результата, эквивалентного произвольному порядку, да.

Блин, под "разумеется" имелось ввиду, что любой порядок должен приводить к одинаковому исходу или выбирается какой-то порядок произвольный?

Вот на этот

Для serializable достаточно достижения результата, эквивалентного произвольному порядку, да.

Спасибо

Как это вам удалось придумать простой пример, когда у computer scientists это заняло не одно десятилетие?! ;) (Напоминаю, slave — read-only).

Тогда я где-то ошибся. Сейчас изложу свои мысли.

Как это вам удалось придумать простой пример, когда у computer scientists это заняло не одно десятилетие?! ;) (Напоминаю, slave — read-only).

Я рассуждал так: в слэйв началась транзакация в которой делается к примеру select sum() всех строк в таблице. В мастер пришла транзакция , которая делает Insert в таблицу, а потом началась репликция на слейв, которая вероятно тоже делается в транзакции. Итого мы имеем две транзации на слейве, которые в serializable приводят к разному результату.

Я рассуждал так: в слэйв началась транзакация в которой делается к примеру select sum() всех строк в таблице. В мастер пришла транзакция , которая делает Insert в таблицу, а потом началась репликция на слейв, которая вероятно тоже делается в транзакции. Итого мы имеем две транзации на слейве, которые в serializable приводят к разному результату.

Не приводят. Первая выполнилась до транзакции на master-е, вторая — после.

Наверно ошибка в том месте, где я реплкацию поместил в тразакцию. Наверняка там как-то по-другому какой-нибудь wal-log просто применяется

Не приводят. Первая выполнилась до транзакции на master-е, вторая — после.

Эмм, вообще-то про слейв речь и две транзации одновременно на слейве. Одна делает просто селект, другая - по сути insert

Наверно ошибка в том месте, где я реплкацию поместил в тразакцию. Наверняка там как-то по-другому какой-нибудь wal-log просто применяется

> Наверно ошибка в том месте, где я реплкацию поместил в тразакцию. Как раз этим путём можно добиться правильной работы. > Наверняка там как-то по-другому какой-нибудь wal-log просто применяется Во встроенной физической / логической репликации именно он и применяется.

> Наверно ошибка в том месте, где я реплкацию поместил в тразакцию. Как раз этим путём можно добиться правильной работы. > Наверняка там как-то по-другому какой-нибудь wal-log просто применяется Во встроенной физической / логической репликации именно он и применяется.

Окей, тогда я всё-таки не понял, где у меня ошибка.

Давайте тогда для простоты уберём репликацию

Эмм, вообще-то про слейв речь и две транзации одновременно на слейве. Одна делает просто селект, другая - по сути insert

Значит, они a) конкурентны b) в логической последовательности SELECT идёт перед INSERT (вообще не вижу, как это связано с репликацией, кстати).

Рассмотрим insert to table и select sum() from table.

Давайте тогда для простоты уберём репликацию

Вот-вот.

Я так понимаю, что разный порядок таких тразакции в serializable имеет разный результат и какая-то из них вернёт ошибку, так?

Я так понимаю, что разный порядок таких тразакции в serializable имеет разный результат и какая-то из них вернёт ошибку, так?

Нет. Вы внимательно прочитали то, что я написал про произвольный порядок? ;)

Чёрт, всё наоборот. Я 10 раз спросил и всё равно не так понял про порядок.

Окей, значит постгрес выберет какой-то порядок, к примеру, вначале select, а потом insert и всё будет хорошо...

Чёрт, всё наоборот. Я 10 раз спросил и всё равно не так понял про порядок.

Вот полное определение из стандарта SQL: — The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins. — Вот и всё.

Окей, значит постгрес выберет какой-то порядок, к примеру, вначале select, а потом insert и всё будет хорошо...

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

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

Я понимаю, что он не выбирает ничего, просто я пытаюсь мыслить по простому, а не вдаваться в сложную логику работы pg. Я понял, что я не могу придумать пример, когда serializable может вернуть ошибку. Т.е. поидее всегда можно набор транзакции в каком-то порядке выполнить. Видимо ингда возникает ситуация, когда постгрес даёт ложное срабатывание по какой-то причине...

Понял

https://www.postgresql.org/docs/10/static/transaction-iso.html Вот тут есть пример

> Я понял, что я не могу придумать пример, когда serializable может вернуть ошибку. Т.е. поидее всегда можно набор транзакции в каком-то порядке выполнить. Так дело-то в том, что клиенты выполняют их параллельно. Так-то конечно можно — блокируй всю базу (хотя бы, для записи), как только приходит первая пишущая транзакция, до её завершения, и дело с концом. (sqlite так и поступает, например.)

Да, я понял, Yaroslav, спасибо

Пример плохой для мастер-слейв и сериалайзабл не удалось придумать.

Пример плохой для мастер-слейв и сериалайзабл не удалось придумать.

То-то. ;) Любой из этих: https://wiki.postgresql.org/wiki/SSI#Read_Only_Transactions

Он все может

кроме работы с расхождением часов

всем времени

пару вопросов нубскх есть ))

ставлю посгри, и везде пишут что надо задавать пас для "postgres"

или можно не задавать ?

или можно не задавать ?

Лучше задавать, наверное... Иначе как вы думаете дистанционно подключаться этим пользователем?

ок. теперь про схему. можно в двух словах.

ок. теперь про схему. можно в двух словах.

Задавайте конкретные вопросы.

или можно не задавать ?

Когда доступ этим пользователем разрешён только локально и в пг_хбяа.конф либо траст, либо пир.

Лучше задавать, наверное... Иначе как вы думаете дистанционно подключаться этим пользователем?

Может не стоит извне ходить данным пользователем?

Может не стоит извне ходить данным пользователем?

Да, может быть, и не стоит. Зависит от того, как в общем настраивается security в организации, наверное.

Задавайте конкретные вопросы.

сча проблему решу. задам.

Господа, а есть у кого repmgr + postgresql 10 ? При клонировании слейва получаю ошибку /usr/lib/postgresql/10/bin/pg_basebackup: unrecognized option '--xlog-method=s' Судя по исходникам repmgr - в базе должны быть вот такие таблички, но у меня их нет. Что может быть не так ? https://github.com/2ndQuadrant/repmgr/blob/master/repmgr--4.1.sql

Господа, а есть у кого repmgr + postgresql 10 ? При клонировании слейва получаю ошибку /usr/lib/postgresql/10/bin/pg_basebackup: unrecognized option '--xlog-method=s' Судя по исходникам repmgr - в базе должны быть вот такие таблички, но у меня их нет. Что может быть не так ? https://github.com/2ndQuadrant/repmgr/blob/master/repmgr--4.1.sql

А конкретные версии PostgreSQL и repmgr какие? Как вы ставили repmgr (это upgrade или новая установка)?

А конкретные версии PostgreSQL и repmgr какие? Как вы ставили repmgr (это upgrade или новая установка)?

новая установка, версии последнии из apt postgres. PostgreSQL 10.4 repmgr 4.0.6 Сейчас проверю - может быть я shared_libs не указал.

новая установка, версии последнии из apt postgres. PostgreSQL 10.4 repmgr 4.0.6 Сейчас проверю - может быть я shared_libs не указал.

> Судя по исходникам repmgr - в базе должны быть вот такие таблички, но у меня их нет. Какие таблички, кстати? > При клонировании слейва получаю ошибку /usr/lib/postgresql/10/bin/pg_basebackup: unrecognized option '--xlog-method=s' А как именно вы клонируете? Тут настораживает вот это: unrecognized option '--xlog-method=s' Вы эту опцию нигде руками не указали, случайно?

Это штатное переименование xlog => wal в 10ке

Для pg_basebackup от Postgresql 10 нужная опция теперь называется --wal-method или кратко так же как в старом pg_basebackup -X

vacuum не двигает для временных таблиц relfrozenxid

Что-то у меня не получилось воспроизвести на 9.6

Да, переименование штатное. По sql по ссылке я вижу, что должны быть таблички repmgr.nodes, итп Но я их у себя не вижу: postgres@pgmaster-preprod:~$ psql repmgr repmgr=# \dt Did not find any relations. Суть в том, что repmgr пытается найти переменную server_version_num

А create extension repmgr; нормально отрабатывает?

А create extension repmgr; нормально отрабатывает?

Внешне - да: postgres=# create extension repmgr; CREATE EXTENSION postgres=# \c repmgr You are now connected to database "repmgr" as user "postgres". repmgr=# \dt Did not find any relations.

А если сказать \dt repmgr.*

?

Привет! Есть следующая ситуация: внутри транзакции создаю пару временных таблиц, а потом выполняю селект с использованием этих временных таблиц. Хочу завершить транзакцию (чтобы удалились временные таблицы) и тут же получить результат селекта из транзакции. Это вообще возможно?

не хотелось бы разрывать транзакцию на отдельные запросы из приложения — а вдруг всё к чертям упадёт как раз после селекта и до коммита?

BEGIN; CREATE TEMP TABLE table_1 ON COMMIT DROP ... CREATE TEMP TABLE table_2 ON COMMIT DROP ... SELECT ... COMMIT;

На выходе получаю просто сообщение COMMIT без данных

Что-то у меня не получилось воспроизвести на 9.6

Имелось в виду для "чужих", наверное...

ERROR: S client not available

Имелось в виду для "чужих", наверное...

Каких таких "чужих" ?

BEGIN; CREATE TEMP TABLE table_1 ON COMMIT DROP ... CREATE TEMP TABLE table_2 ON COMMIT DROP ... SELECT ... COMMIT;

а если сначала селект а потом дроп?

Каких таких "чужих" ?

Других сессий.

а если сначала селект а потом дроп?

опять же придётся разрывать на два запроса из приложения, потому что как я понял в ответ всегда возвращается результат последней команды

Других сессий.

Для autovacuum все сессии должны быть "чужими"

Для autovacuum все сессии должны быть "чужими"

Да, конечно.

не хотелось бы разрывать транзакцию на отдельные запросы из приложения — а вдруг всё к чертям упадёт как раз после селекта и до коммита?

Вы так не сможете нормально работать, IMHO (потому что тогда у вас получается одна транзакция = один запрос). По-моему, это какое-то слишком сильное ограничение.

А если сказать \dt repmgr.*

Так таблички находит. Но всё равно даёт ошибку, как будто не получает корректную версию postgres: https://github.com/2ndQuadrant/repmgr/blob/cb46fb6410d9724f2dfaa870de7e117e6d6f8910/configfile.c#L1838

итак вернмся к схемам. как я понял, схемы , это типа группировки бд.

может ли одна бд быть сразу в двух схемах ?

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

Так таблички находит. Но всё равно даёт ошибку, как будто не получает корректную версию postgres: https://github.com/2ndQuadrant/repmgr/blob/cb46fb6410d9724f2dfaa870de7e117e6d6f8910/configfile.c#L1838

А что говорит SELECT setting FROM pg_catalog.pg_settings WHERE name = 'server_version_num' INTO server_version_num;

может ли одна бд быть сразу в двух схемах ?

В одной бд может быть много схем. Схемы с теми же наименованиями могут быть и в другой БД.

тогда я несовсем понимаю, для чего нужны схемы. пусть одна "public"

итак вернмся к схемам. как я понял, схемы , это типа группировки бд.

Нет, вы поняли совершенно неправильно. О, уже ответили. :) Тем не менее, можете думать о схемах как о каталогах в файловой системе, только одноуровневой (без вложенности, т.е. подкаталогов нет).

тогда я несовсем понимаю, для чего нужны схемы. пусть одна "public"

А для чего нужны directories в FS?

может ли одна бд быть сразу в двух схемах ?

Наоборот, у тебя не БД в схемах, а схемы внутри БД.

похожу он просто троилт )

похожу он просто троилт )

нет. я пытаюсь разобратся

Наоборот, у тебя не БД в схемах, а схемы внутри БД.

получается что это нормально

Так таблички находит. Но всё равно даёт ошибку, как будто не получает корректную версию postgres: https://github.com/2ndQuadrant/repmgr/blob/cb46fb6410d9724f2dfaa870de7e117e6d6f8910/configfile.c#L1838

Скорее всего, какая-то "глупая" ошибка. ;) Например, вы не к тому серверу подключаетесь. Или указали этот параметр явно в файле конфигурации repmgr. И т.п.

похожу он просто троилт )

нет, пытается разобраться

А что говорит SELECT setting FROM pg_catalog.pg_settings WHERE name = 'server_version_num' INTO server_version_num;

repmgr=# SELECT setting repmgr-# FROM pg_catalog.pg_settings repmgr-# WHERE name = 'server_version_num' repmgr-# INTO server_version_num; ERROR: syntax error at or near "INTO" LINE 4: INTO server_version_num; ^ repmgr=# SELECT setting FROM pg_catalog.pg_settings WHERE name = 'server_version_num' ; setting --------- 100004 (1 row)

repmgr=# SELECT setting repmgr-# FROM pg_catalog.pg_settings repmgr-# WHERE name = 'server_version_num' repmgr-# INTO server_version_num; ERROR: syntax error at or near "INTO" LINE 4: INTO server_version_num; ^ repmgr=# SELECT setting FROM pg_catalog.pg_settings WHERE name = 'server_version_num' ; setting --------- 100004 (1 row)

Проверьте по моим вопросам тогда... я понимаю, глупо, но бывает. Кстати, текущие значения можно смотреть просто: "SHOW server_version_num;"

Проверьте по моим вопросам тогда... я понимаю, глупо, но бывает. Кстати, текущие значения можно смотреть просто: "SHOW server_version_num;"

Спасибо, понял как переменую смотреть В общем, это называется "не используйте чужие роли ansible" :( Параметр действительно передавался в напрямую в repmgr.conf Спасибо.

Спасибо, понял как переменую смотреть В общем, это называется "не используйте чужие роли ansible" :( Параметр действительно передавался в напрямую в repmgr.conf Спасибо.

Да не за что. :)

привет. есть вопрос. читаю слайды обучающие по постгресу, про транзакции инаписано:Если прерванная транзакция успела создать новые версии строк, эти версии не уничтожаются (не происходит «физического» отката данных). Благодаря информации о статусах другие транзакции увидят, что транзакция, создавшая или удалившая версии строк, на самом деле прервана, и не станут принимать ее изменения во внимание.

не происходит «физического» отката данных - хорошо, не происходит, моя строка изменилась одна, а вторая нет, как он вернет данные в первоначальный вид?

у первой строки

тут он пишет никак

они не записываются в базу ведь так?, только если транзакция успещна, строки записываются в базу?