@fuckinginterpol вообще-то про естественный ключ тебе и до того говорили :)

так откажись от auto increment и привязывай natural key

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

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

Случайно получилось:

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

ага, пойду письмо в спортлото накатаю что ли, пусть хоть текст WARNING`а поменяют

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

А Postgres этот orphan temp table не зачистит самостоятельно?

А Postgres этот orphan temp table не зачистит самостоятельно?

только когда нужно будет переиспользовать его номер

А Postgres этот orphan temp table не зачистит самостоятельно?

а он и не обязательно должен быть orphan

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

ага, пойду письмо в спортлото накатаю что ли, пусть хоть текст WARNING`а поменяют

Какого?

где про 'roll back prepared transactions' хорошо бы добавить что-то вроде 'дропните все временные схемы'

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

Т.е. корректный shutdown в этом случае помог бы.

только когда нужно будет переиспользовать его номер

Temp схему или relid?

где про 'roll back prepared transactions' хорошо бы добавить что-то вроде 'дропните все временные схемы'

Так это тоже не всё...

Т.е. корректный shutdown в этом случае помог бы.

да, если тебе памяти хватит

вдруг там миллион временных таблиц в этом бэкенде, эту часть до сих пор не оптимизировали вроде

Так это тоже не всё...

это программа-минимум

это программа-минимум

Так если уж будете писать, почему бы не предложить добавить в hint полный список причин? (И вообще, это есть где-нибудь (именно список) в документации?)

В действительности, дубли по уникальному индексу - обычная ошибка, и что произошла при этом потеря данных, ещё нужно доказать.

Так если уж будете писать, почему бы не предложить добавить в hint полный список причин? (И вообще, это есть где-нибудь (именно список) в документации?)

звучит как что-то полезное, поэтому врядли такой список есть

В действительности, дубли по уникальному индексу - обычная ошибка, и что произошла при этом потеря данных, ещё нужно доказать.

В действительности, нет, не обычная. То, что кто-то (именно вы?) "нарвался" на подобную, не даёт права делать подобные заявления, вам не кажется? :(

Потеря данных <> потеря логической целостности

Так, а в самом деле... кто-нибудь видел такой список (причин, которые мешают anti-wraparound vacuum делать свою работу)?

В действительности, дубли по уникальному индексу - обычная ошибка, и что произошла при этом потеря данных, ещё нужно доказать.

Не пугай меня пожалуйста...

Про ide. сделайте что нить приличное на вебе.

В винде есть sql manager коммерческий, его хватает

Про ide. сделайте что нить приличное на вебе.

Ну хоть какой-то дружественный фидбэк, спасибо. Так на вебе у Вас есть pgAdmin ?

Про ide. сделайте что нить приличное на вебе.

есть позорный pgadmin 4

хватит веба)))

Когда мы только начинали работать с Постргресом, используя его возможности серверного программирования на полную катушку, мы столкнулись с проблемой, о которой упомянул Darafei - SQL исходники должны быть организованы так, чтобы их можно было запускать из того же psql многократно. Мы создали свой собственный инструмент для внутреннего использования, который эту проблему решал. В результате получилось, что мы работаем с обычными SQL файлами привычным образом, и нам не нужно лазить по нарисованным объектам БД в GUI, чтобы редактировать их в мелких окошечках (привет, pgAdmin, ты часто падал, мы тебя быстро закопали).

(это называется идемпотентностью)

Ну и сейчас появилась идея этот инструмент обнародовать. GUI может быть полезен для того, чтобы сделать использование более удобным и наглядным. По большому счёту, он и не нужен. Все возможности инструмента могут быть доступны из командной строки. Возможно, в свете того, что сейчас идёт популяризация VSCode, можно сделать ставку на него, взяв за основу. Нам важно увидеть интерес со стороны сообщества. Если его не будет, то и нам трать своё время резона нет.

Когда мы только начинали работать с Постргресом, используя его возможности серверного программирования на полную катушку, мы столкнулись с проблемой, о которой упомянул Darafei - SQL исходники должны быть организованы так, чтобы их можно было запускать из того же psql многократно. Мы создали свой собственный инструмент для внутреннего использования, который эту проблему решал. В результате получилось, что мы работаем с обычными SQL файлами привычным образом, и нам не нужно лазить по нарисованным объектам БД в GUI, чтобы редактировать их в мелких окошечках (привет, pgAdmin, ты часто падал, мы тебя быстро закопали).

Третий пгадмин не падает

Третий пгадмин не падает

Как раз 3-й у нас и падал. Возможно, сейчас уже исправили, мы не в курсе.

прям падал или просто ругался?

прям падал или просто ругался?

Падал. ОС была Ubuntu Linux.

Падал. ОС была Ubuntu Linux.

на какой версии пг?

на какой версии пг?

Я не помню уже, это было очень давно. Возможно, на первых версиях 9-й линейки, может быть даже на последних версиях 8-й линейки.

Всем привет, подскажите, в чем преимущество мастер-мастер репликации над мастер-слейв. Масштабирование для чтения они обе дают, как я понимаю. Масштабирование по записи вроде у обоих нету.

Всем привет, подскажите, в чем преимущество мастер-мастер репликации над мастер-слейв. Масштабирование для чтения они обе дают, как я понимаю. Масштабирование по записи вроде у обоих нету.

Простота с точки зрения приложения - не надо задумываться куда писать.

Всем привет, подскажите, в чем преимущество мастер-мастер репликации над мастер-слейв. Масштабирование для чтения они обе дают, как я понимаю. Масштабирование по записи вроде у обоих нету.

А вы о каких конкретно решениях говорите?

Всем добрый вечер, как мне быстро подсчитать количество СЛОВ в таблице?? PS: Буква - (набор букв без цифр и без спец символов)

регулярки?

Всем добрый вечер, как мне быстро подсчитать количество СЛОВ в таблице?? PS: Буква - (набор букв без цифр и без спец символов)

select count(*) from words;

о, точно! заджоинить на справочник слов

select count(*) from words;

Я говорю подсчитать количество СЛОВ, а не количество СТРОК в таблице

о, точно! заджоинить на справочник слов

Не понял, можете поподробнее?

Не понял, можете поподробнее?

это стеб, простите )

это стеб, простите )

такое не прощаеться))

готового решения скорее всего тут не дадут

Если вам подходит интерперетация слов утилитой wc, то можно так: создаёте на файловой системе pipe. Командой wc из него вычитываете, из psql командой COPY в этот pipe заливаете

Я говорю подсчитать количество СЛОВ, а не количество СТРОК в таблице

Каждая строка в таблице слов -- это слово

Простота с точки зрения приложения - не надо задумываться куда писать.

Спасибо, ?

А вы о каких конкретно решениях говорите?

?

Если вам подходит интерперетация слов утилитой wc, то можно так: создаёте на файловой системе pipe. Командой wc из него вычитываете, из psql командой COPY в этот pipe заливаете

мне утилиты вообще не нужны, нужна чистое решение на postgre sql

мне утилиты вообще не нужны, нужна чистое решение на postgre sql

звучит как прохождение теста на собеседовании

Каждая строка в таблице слов -- это слово

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

?

Решений для репликации PostgreSQL не одно и не два, вообще-то. У вас про какие конкретно вопрос?

звучит как прохождение теста на собеседовании

ахахах) да не просто я новичек, а вы тут большие, умные дяди, думаю может поможете))

Всем добрый вечер, как мне быстро подсчитать количество СЛОВ в таблице?? PS: Буква - (набор букв без цифр и без спец символов)

Зачем?!

Зачем?!

это сикрет

Решений для репликации PostgreSQL не одно и не два, вообще-то. У вас про какие конкретно вопрос?

Не знал, что в pg есть мастер-мастер репликация. Какие ещё способы есть? Может быть из приложения делать запросы в каждую ноду.

Всем добрый вечер, как мне быстро подсчитать количество СЛОВ в таблице?? PS: Буква - (набор букв без цифр и без спец символов)

select count(*) from (select regexp_matches("field", '\w+', 'g') from "table") as t;

типа такого?

ERROR: S client not available

ахахах) да не просто я новичек, а вы тут большие, умные дяди, думаю может поможете))

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

Не знал, что в pg есть мастер-мастер репликация. Какие ещё способы есть? Может быть из приложения делать запросы в каждую ноду.

Ну есть же BDR, Bucardo, Postgres-XL, Citus...

select count(*) from (select regexp_matches("field", '\w+', 'g') from "table") as t;

это лишь намек на первый шаг к решению ?

ну да, там всякое еще пролезает

но тут надо знать что вообще пишется в таблицу

Ну есть же BDR, Bucardo, Postgres-XL, Citus...

Это форки pg с добавлением каких-то решений?

просто текст или же какая-нибудь html-разметка

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

этот трешак надо пересмотреть в корне

этот трешак надо пересмотреть в корне

всё, я молчу

Это форки pg с добавлением каких-то решений?

По-разному (посмотрите сами, если интересуют). А что вам на самом деле нужно-то?

select count(*) from (select regexp_matches("field", '\w+', 'g') from "table") as t;

спасибо!

По-разному (посмотрите сами, если интересуют). А что вам на самом деле нужно-то?

Я просто узнаю про технологии. У меня, похоже, ни разу в жизни хайлоода не было ?

а напомните, чем нынче хайлоад меряется?

ну то есть что считать таковым

Простота с точки зрения приложения - не надо задумываться куда писать.

Yaroslav вот тут вполне понятно ответили, что в мастер-мастер можно брать просто любой сервер для чтения, а в мастер-слейв видимо отдельно для чтения пул, отдельно для записи сервер.

Я просто узнаю про технологии. У меня, похоже, ни разу в жизни хайлоода не было ?

А, если так... почитайте что-нибудь про multi-master/distributed database вообще. Вкратце, то, чего, наверное, наивно хочется всем тем, кто впервые столкнулся с этой темой (распределённая база, можно писать на любой сервер, маштабируется примерно линейно, ACID гарантируется и т.п.) невозможно даже теоретически.

Yaroslav вот тут вполне понятно ответили, что в мастер-мастер можно брать просто любой сервер для чтения, а в мастер-слейв видимо отдельно для чтения пул, отдельно для записи сервер.

Да, вот этого-то всем и хочется. Только к этому прилагается много всего, эээ... "приятного", "мелким шрифтом".

Бери cocroachdb. Протокол обмена северна и клиента там совместим с постгрес. И нам расскажешь )

Он все может

В мастер-мастер предполагается синхронный вариант работы? Асинхронного же нету?

привет, кто может подсказать. есть клиент psql перед которым стоит балансер. эпизодически кидается сообщение https://github.com/postgres/postgres/blob/08ea7a2291db21a618d19d612c8060cda68f1892/src/interfaces/libpq/fe-exec.c#L1428 по какой причине может быть conn->status != CONNECTION_OK

что такого делает балансер?

В мастер-мастер предполагается синхронный вариант работы? Асинхронного же нету?

Есть всё что угодно. Чего нет и быть не может, так это того, о чём я писал выше (про наивные ожидания). :(

что такого делает балансер?

Например, принудительно рвёт соединения по какому-то таймауту (а почему бы и нет?).

Есть всё что угодно. Чего нет и быть не может, так это того, о чём я писал выше (про наивные ожидания). :(

Окей, а где про это можно почитать? Я ж правильно понял, что в мастер-мастер ACID не гарантируется? а то, что можно писать на любой сервер - это вроде единственное приемущество перед мастер-слейв, как мне кажется.

> Окей, а где про это можно почитать? Не помню. :( Может быть, кто-то ещё подскажет? > Я ж правильно понял, что в мастер-мастер ACID не гарантируется? Теоретически — нет, неправильно (но всегда есть какие-то неприяные ограничения, как, например, в упомянутом CockroachDB). Практически, насколько я помню, full-ACID multi-master для PostgreSQL нет (даже с ограничениями)... но, может быть, вас устроит и не full?

> то, что можно писать на любой сервер - это вроде единственное приемущество перед мастер-слейв, как мне кажется. Full-ACID master/slave у нас, кстати, тоже не вагон. :(

Вот уж не думал, что у msater-slave могут быть проблемы с ACID...

Это видимо при разных уровнях изоляции транзакции, к примеру, serializable?

Вот уж не думал, что у msater-slave могут быть проблемы с ACID...

Во-первых, есть банальное отставание асинхронной реплики.

Это видимо при разных уровнях изоляции транзакции, к примеру, serializable?

А для синхронной реплкики — да, SERIALIZABLE не поддерживается.