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

Тем не менее, что вообще в pg_locks / pg_stat_activity? А, да, на всякий случай, в pg_prepared_xacts пусто?

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

теперь только логи курить

теперь уже не воспроизвести видимо

ладно завтра может новое что повторится

думаю на этом пока все

думаю на этом пока все

Вы хоть сохраните результаты этих запросов, если повторится... а то вообще никаких подробностей. :(

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

Индексы на проде однозначно через конкурентли

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

с новыми релизами что только не создается)

эпопея продолжается

А не знаете случайно, кто такой этот Anthony Iliopoulos? Кто-то из linux kernel hackers? ;)

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

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

Да это вообще единственный гарантированно надёжный метод накатывания произвольного DDL, к сожалению (т.к. иначе можно огрести полной пурги в параллельно выполняющихся запросах). :(

А не знаете случайно, кто такой этот Anthony Iliopoulos? Кто-то из linux kernel hackers? ;)

ну от него вроде есть какие-то коммиты и переписки в lkml

Ясно, спасибо! А я-то думаю, чего это он так упорно защищает явно долбанутое поведение Linux. ;)

ну он норм защищает, даже крейг согласился что постгрес дофига хочет порой

Привет, есть девочки?

Аххаха

ERROR: S client not available

Привет, есть девочки?

Мальчик, ты чей?)

так

меня обманули)

ты от @bobrovskiy_roman, знаете такого?

ну он норм защищает, даже крейг согласился что постгрес дофига хочет порой

Это совсем не "норм" —- это грубое нарушение POSIX. Кстати, цитата в тему (Robert Haas): —- Well, then the man page probably shouldn't say CONFORMING TO 4.3BSD, POSIX.1-2001, which on the first system I tested, it did. Also, the summary should be changed from the current "fsync, fdatasync - synchronize a file's in-core state with storage device" by adding ",possibly by randomly undoing some of the changes you think you made to the file". —- Если они (linux kernel hackers) считают это нормальным, то, опять-таки: —- > Hey, why bother having a kernel at all, except for drivers? I believe this is how Oracle views the kernel, so there is precedent for this approach, though I am not advocating it.

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

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

Потому что, при таком поведении linux kernel, их нет. :( Это вообще жесть: > Speaking of, there's not necessarily any lost page write error in the logs > AFAICS. My tests often just show "Buffer I/O error on device dm-0, logical > block 59393" or the like. I assume that is the kernel logs. I am thinking the kernel logs have to be monitored, but how many administrators do that? The other issue I think you are pointing out is how is the administrator going to know this is a Postgres file? I guess any sync error to a device that contains Postgres has to assume Postgres is corrupted. ?

ты от @bobrovskiy_roman, знаете такого?

не знаю