>> Если закрывать соединения к базе после рестарта до момента синхронизации > синхронных реплик, тогда база откроется после фейловера. Нет, тогда именно эта база не откроется...
>> В это самое "почти", я полагаю, не должны входить потери после рестарта экземпляра Предложите хоть одно реалистичное решение. Хотя... какие конкретно потери Вы имеете в вид...
>> Приведите кейс, когда не откроется, с учётом, конечно, что кластер в конце концов соберётся) Именно этот кластер баз PostgreSQL будет уничтожен (или "перемотан" pg_rewind) ...
>> вступает в дело HA обвязка, либо будет автофейловер Хорошо, это плюс в такой ситуации. А если не вступает, что дальше будет? тут либо никаких фейлов нет и синхронный комм...
> Т.е. в любом подобном случае (the connection is closed before it receives a response) закомиттилась транзакция или нет — не определено (это, кстати, вообще прямо предписывае...
> Объясните, чего конкретно Вы хотите добиться на практике / в каком ключе вести дальнейшую дискуссию в -hackers? это будет как отдельный фич реквест (или баг репорт) с расчё...
> Execution-time partition pruning currently only occurs for the Append and MergeAppend node types. It is not yet implemented for the ModifyTable node type, but that is likely...
> Он задал вопрос, ему объяснили, что это нормально Пример Брюса может быть не самый удачный, но *где* ему отвечают, что поведение нормальное? На самом деле, желание предприн...
>> то же самое будет и при отмене отдельной COMMIT команды. А вот этого я не видел. Можете показать? воспроизводится на раз-два # show synchronous_standby_names ; synchronou...
> ORLY? ;) А мне кажется, что это то, чем всё кончится — ничего изменено не будет (всё и так работает нормально, IMHO). Ну далее же более предметно разговор идёт. И о ненорма...
> "Открытий" учебников по распределённым базам данных, что ли? ;) Это всё нюансы реализации > Ладно, шутки шутками, а Вы в -hackers уже писали что-то (может, я пропустил)? ...
>А вот это верно: > Мастер вначале должен удостовериться в том, что реплики приняли изменения, и только потом у себя принять? ? мастер уже принял у себя изменения до принятия...
> Т.е. pruning здесь работает быстрее, если partitions очень много... что уже само по себе проблема и до сих пор! ;) что за проблема? не понял тут вашу мысль > Т.е. (см. выш...
в том треде https://www.postgresql.org/message-id/658c420e-9899-5c24-87b0-d34ba81e17a7%40gmail.com мы на это указали, только у нас был пример с автокоммитом. Считать это багом...
> Если Вы про отслеживание самого Patroni, то если он умрёт - он выпадает из списка участников кластера, если это был мастер - ключ лидера устаревает. После, он выпадает из ко...
Кстати, хотел спросить, каким образом зависшие транзакции и настройки автовакуума влияют на переполнение в pg_wal?
> Но это кейс про всех прочих. А вообще — почему это у Вас приложения не обрабатывают такую ситуацию как положено, а? ;) Отработать как положено - это проверить статус транза...
> Не надо делать ручками то, что уже есть. С вероятностью, стремящейся к 100% будет хужее. Возможно, но можно воссоздать подмножество того окружения для версионирования, кото...
а пгпрошный pgbouncer тянется от какого-то общего пакета? Вообще в пгпро старались пути к бинарникам свои проставлять, чтобы не было конфликта с ванилой, так что в патрони и в...
> Т.е. сколько у Вас обычно partitions, какая длина ключей индексов? Для timescaledb партиции разбиваются по timestamp'у. Обычно их бьют по короткому интервалу, так что их на...