кто-нибудь может пояснить?

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

Физически строки никогда не меняются (в обычных таблицах, по крайней мере).

т.е это все происходит в общей памяти и после изменения впечатываются в таблицу?

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

Записываются, конечно. В "худшем" случае — сразу после записи изменений в WAL.

т.е это все происходит в общей памяти и после изменения впечатываются в таблицу?

Нет, ничего подобного... если я правильно вас понял. ;)

блин

т.е это все происходит в общей памяти и после изменения впечатываются в таблицу?

Т.е. страница действительно сначала изменяется в shared buffers, и после записи соотв. изменений в WAL может быть записана на диск (и, если сервер не упадёт, рано или поздно будет записана). Только для понимания механизма работы MVCC это несущественные подробности, IMHO.

ок. спасибо. пошел разбираться дальше

так хорошо, какое поведение будет если у меня в транзакции изменение двух строй

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

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

как он разрулит это?

если он вписал, но не думает откатывать

Ну блин в конце флаг будет в статусе "не завершено" для транзакции и данные при выборке не будут учитываться.

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

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

Ещё раз: строки в базе физически не изменяются (только создаются новые версии). Поэтому "старые" никуда не денутся, и т.к. новые окажутся not committed, старые и будут читаться.

По сути то обновление или вставка, это фактически вставка строки, с номером транзакции

То есть хранится история каждой ячейки, за некоторый период

Ещё раз: строки в базе физически не изменяются (только создаются новые версии). Поэтому "старые" никуда не денутся, и т.к. новые окажутся not committed, старые и будут читаться.

бляяяяя....вот сча просто у меня вселенная открылась, я реально понял че они пытаются впарить....блин гениално. А Вам огоромное спасибо! Реально спасибо.

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

То есть хранится история каждой ячейки, за некоторый период

Ну и вакуумом подчищается постепенно

Ну и вакуумом подчищается постепенно

как раз буду про него читать

Еще посмотрите колонки xmin, xmax, ctid: select xmin, xmax, ctid from test;

Еще посмотрите колонки xmin, xmax, ctid: select xmin, xmax, ctid from test;

спасибо

Внешне - да: 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.

экстеншон создавай в нужной базе

экстеншон создавай в нужной базе

Спасибо. Разобрались. Оказывается опция отдавалась через repmgr.conf.

Удалось воспроизвести багу с pre-wraparound и временной таблицей. Идея в том, что если мы очень долго держим temp-таблицу, то гарантированно получим pre-wraparound В одном из коннектов создал временную таблицу tmp и просто держал коннект открытым. В других коннектах недёргивал txid_current() до того, как получил pre-wraparound. После рестарта осталась перманентно таблица pg_temp_3.tmp; Выполнение vacuum freese pg_temp_3.tmp; даже в single-user режиме не решает проблему.

Удалось воспроизвести багу с pre-wraparound и временной таблицей. Идея в том, что если мы очень долго держим temp-таблицу, то гарантированно получим pre-wraparound В одном из коннектов создал временную таблицу tmp и просто держал коннект открытым. В других коннектах недёргивал txid_current() до того, как получил pre-wraparound. После рестарта осталась перманентно таблица pg_temp_3.tmp; Выполнение vacuum freese pg_temp_3.tmp; даже в single-user режиме не решает проблему.

А это не бага, это фича. :(

> . После рестарта осталась перманентно таблица pg_temp_3.tmp; Кроме вот этой части, пожалуй. Это какая версия PostgreSQL?

PostgreSQL 10.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit

Решает проблему удаление таблицы в single-user mode и последующий vacuumdb -F

Добрый день. У меня есть text поле в таблице с индексом pg_trgm. Раньше все было нормально, недавно появилась ошибка index row requires 19664 bytes, maximum size is 8191. Как можно снять этот лимит? гугл не помогает

привет чат

https://eng.uber.com/mysql-migration/

а эту траблу фиксят вообще

?

в новых версиях

write amplification

или это вообще не проблема а убере не правы

PostgreSQL 10.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit

Вот же... а вроде что-то такое fix-или. Вы пробовали в -hackers поискать?

Это не проблема, для тех задач, для которых это не критично.

Это не проблема, для тех задач, для которых это не критично.

а можешь пояснить что это за задачи

а эту траблу фиксят вообще

Это особенность архитектуры, я думаю. У альтернативной-то тоже есть свои недостатки (только в статье о них, как мне помнится, "забыли").

Это особенность архитектуры, я думаю. У альтернативной-то тоже есть свои недостатки (только в статье о них, как мне помнится, "забыли").

таки да то што особенность архитектуры я понял

мне просто интересно это как то оптимизировали (или планируют) или это норма

мне просто интересно это как то оптимизировали (или планируют) или это норма

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

а можешь пояснить что это за задачи

ну если тебе раз в секунду одну и ту же запись не надо update делать, то PG норм.

Добрый день. У меня есть text поле в таблице с индексом pg_trgm. Раньше все было нормально, недавно появилась ошибка index row requires 19664 bytes, maximum size is 8191. Как можно снять этот лимит? гугл не помогает

А какой индекс? GIST или GIN?

А какой индекс? GIST или GIN?

GIN

Вот же... а вроде что-то такое fix-или. Вы пробовали в -hackers поискать?

http://www.postgresql-archive.org/Fun-fact-about-autovacuum-and-orphan-temp-tables-td5919492.html Интересно это таки приняли?

Автообновление в материализованных представлениях ведь так и не сделано в качестве фичи?

Добрый день. У меня есть text поле в таблице с индексом pg_trgm. Раньше все было нормально, недавно появилась ошибка index row requires 19664 bytes, maximum size is 8191. Как можно снять этот лимит? гугл не помогает

А, похоже google вам и не поможет. :( (Это константа INDEX_SIZE_MASK в исходниках, её изменение вряд ли предусматривалось.) Похоже на то, что вам придётся придумать другое решение.

Автообновление в материализованных представлениях ведь так и не сделано в качестве фичи?

"На лету" (в той же транзакции), в смысле? Нет, не сделано. Аналог можете сделать с помощью триггеров и обычных таблиц, если нужно...

http://www.postgresql-archive.org/Fun-fact-about-autovacuum-and-orphan-temp-tables-td5919492.html Интересно это таки приняли?

Ну, так вроде вот: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a734fd5d1c309cc553b7c8c79fba96218af090f7 И вот: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=dafa0848da11260e9510c699e7060171336cb550

re all. кто-то бакулу с постгресом совокуплял? есть документация

Ну, так вроде вот: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a734fd5d1c309cc553b7c8c79fba96218af090f7 И вот: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=dafa0848da11260e9510c699e7060171336cb550

Спасибо!

GIN

Я вот сейчас подумал... как-то это странновато, всё же (откуда там такие index rows?). Попробуйте спросить в #postgresql (IRC), или в mailing lists (или подождите другого ответа здесь).

у меня текст на 38к символов)

у меня текст на 38к символов)

Ну так, по идее, индексируются-то триграммы (хотя я в структуре никогда не копался). Спросите в #postgresql, там сейчас как раз могут быть люди, которые сходу ответят. ;)

Вот же... а вроде что-то такое fix-или. Вы пробовали в -hackers поискать?

Не пробовал. Буду благодарен, если кто-то найдёт

Не пробовал. Буду благодарен, если кто-то найдёт

Так вон там выше постили ссылки.

ERROR: S client not available

http://www.postgresql-archive.org/Fun-fact-about-autovacuum-and-orphan-temp-tables-td5919492.html Интересно это таки приняли?

да, автовакуум с 10-ки умеет удалять осиротевшие вр. таблицы

да, автовакуум с 10-ки умеет удалять осиротевшие вр. таблицы

А вот же пишут: https://t.me/pgsql/88942 Как так?

а там она не осиротела

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

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

> После рестарта осталась перманентно таблица pg_temp_3.tmp; Я думал, это делает её orphan... нет?

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

и она станет orphan после этого

но сделать с ней уже ничего нельзя будет

фиговый дизайн временных таблиц strikes again

и она станет orphan после этого

Ну так вроде пишут, что был рестарт... > но сделать с ней уже ничего нельзя будет Почему? Разве суть этих патчей не была в том, чтобы чистить их при старте (но я подробно не читал)?

Ну так вроде пишут, что был рестарт... > но сделать с ней уже ничего нельзя будет Почему? Разве суть этих патчей не была в том, чтобы чистить их при старте (но я подробно не читал)?

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

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

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

А, понятно, спасибо!

фиговый дизайн временных таблиц strikes again

Когда же с этим что-нибудь сделают... похоже, (почти) всем пофиг. :(

выносить из каталога их надо

выносить из каталога их надо

Да, согласен. Но как-то все относящиеся к этому обсуждения, патчи и т.п. "завяли", насколько я помню. :(

https://www.postgresql.org/message-id/0c7c2f84-74f5-2cd9-767e-9b2566065d71%40postgrespro.ru

спасибо, может добавить туда честный путь по воспроизведению (без gdb) ?

честно крутить счетчик? долго жеж

всего 3.5 часа заняло

https://www.postgresql.org/message-id/0c7c2f84-74f5-2cd9-767e-9b2566065d71%40postgrespro.ru

У меня тоже получилось. Тоже несколько часов крутил

У меня тоже получилось. Тоже несколько часов крутил

Напишешь в рассылку?

hi there

i have a question for you, I have 3 external databases and a pivot central database. I will use dblink library for send query at the pivot. In next time the pivot query another database and insert a row. My problem is : how i can identify the client and exclude it from the next query? tnx

Hi

There are several approaches. No idea, what will fit your needs.

If you have timestamp, and there is no case "later rows arrival into the staging database" you could use date ranges.

How often you collect data to the central database?

Доброй ночи, подскажите пожалуйста! Работаю с postgresql 9.6х. При отправке такого запроса: SELECT table1.* FROM table1, jsonb_each_text(table1.json_column) LEFT JOIN table2 ON table1.t2_id = table2.id LIMIT 4 posgres дает ошибку: PSQLException ОШИБКА: в элементе предложения FROM неверная ссылка на таблицу "table1" Подсказка: Таблица "table1" присутствует в запросе, но сослаться на неё из этой части запроса нельзя. Позиция: 84 org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse (QueryExecutorImpl.java:2433)

изначально всё работало без jsonb_each_text(table1.json_column), но сейчас он мне нужен, но из-за него он выдает ошибку неверная ссылка на table1