Е
Выставляю пользователя постгре
Size: a a a
2020 May 28
YS
так вот да и я себе уже не верю...пересматриваю уже 3 раз ..... понял,значит сейчас будут кардинальные действия....спасибо большое за ответ
Там же даже конкретное значение указано ("CA0238683"), поищите его, да и всё. ;)
EK
Yaroslav Schekin
Там же даже конкретное значение указано ("CA0238683"), поищите его, да и всё. ;)
а это значение ?????😅 я думал это код ошибки....спасибо)))))
Ð
Будет падать только процесс, которому не хватило памяти. Это не будет вызывать падение всего кластера.
у меня текли клиентские процессы, а оом рубил постмастера и весь кластер
VY
так вот именно,что только числовые.Коллега от страху поставил character varying вот сейчас хочу исправить но что то не получается
такой запрос попробуйте (
id — предположение, что это PK и присутствует в таблице )SELECT id, service_provider_unp FROM ebol_all
WHERE translate(service_provider_unp, '0' || translate(service_provider_unp, '_1234567890', '_'), '0') IS DISTINCT FROM service_provider_unp;
EK
такой запрос попробуйте (
id — предположение, что это PK и присутствует в таблице )SELECT id, service_provider_unp FROM ebol_all
WHERE translate(service_provider_unp, '0' || translate(service_provider_unp, '_1234567890', '_'), '0') IS DISTINCT FROM service_provider_unp;
хмммм,интересно,спасибо, щас попробую
МШ
Здравствуйте, как исключить эту проблему?
Попробуйте привести ТЕКСТ ошибки а не скрин экрана
МШ
Постгрес использует malloc внутри бэкенда для "рабочей" памяти при обработке запроса.
Если malloc возвращает NULL, то просто репортится ошибка:
src/backend/utils/mmgr/mcxt.c:
if (unlikely(ret == NULL))
{
MemoryContextStats(TopMemoryContext);
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of memory"),
errdetail("Failed on request of size %zu in memory context \"%s\".",
size, context->name)));
}
После чего абортируется текущая транзакция. И сам постгрес и даже бэкенд продолдают работу.
Размер временной памяти задаётся work_mem параметром, но это не жётское ограничение но "пожелание" посгресу не выходить за эту границу.
Но недостаток памяти в системе может сказаться не только на malloc-е.
И для shared memory может не хватить физической памяти (особенно если выключен свап)
Тогда придёт страшный OOM killer и прибьёт первого попавшегося. Это с большой вероятностью приведёт к перезагрузке всего постгреса.
Справиться с этим на уровне посгреса никак нельзя. Можно пытаться ограничить аппетиты бэкендов и других процессов с помощью квот или cgroups. Ну или иметь достаточный СВАП.
Ну а самое правильное - не запускать такие процессы которые выжрают всю память:)
Если malloc возвращает NULL, то просто репортится ошибка:
src/backend/utils/mmgr/mcxt.c:
if (unlikely(ret == NULL))
{
MemoryContextStats(TopMemoryContext);
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of memory"),
errdetail("Failed on request of size %zu in memory context \"%s\".",
size, context->name)));
}
После чего абортируется текущая транзакция. И сам постгрес и даже бэкенд продолдают работу.
Размер временной памяти задаётся work_mem параметром, но это не жётское ограничение но "пожелание" посгресу не выходить за эту границу.
Но недостаток памяти в системе может сказаться не только на malloc-е.
И для shared memory может не хватить физической памяти (особенно если выключен свап)
Тогда придёт страшный OOM killer и прибьёт первого попавшегося. Это с большой вероятностью приведёт к перезагрузке всего постгреса.
Справиться с этим на уровне посгреса никак нельзя. Можно пытаться ограничить аппетиты бэкендов и других процессов с помощью квот или cgroups. Ну или иметь достаточный СВАП.
Ну а самое правильное - не запускать такие процессы которые выжрают всю память:)
* режим зануды включен
Специально сейчас полез в исходники. malloc не нашёл. Нашёл, что используется собственное выделение памяти, подобное SysV malloc.
Специально сейчас полез в исходники. malloc не нашёл. Нашёл, что используется собственное выделение памяти, подобное SysV malloc.
KK
* режим зануды включен
Специально сейчас полез в исходники. malloc не нашёл. Нашёл, что используется собственное выделение памяти, подобное SysV malloc.
Специально сейчас полез в исходники. malloc не нашёл. Нашёл, что используется собственное выделение памяти, подобное SysV malloc.
Я там привёл и имя файла и номер строчки:)
МШ
Номера строчки в упор не вижу. На гитхабе в этом файле malloc отсутствует, как класс. Но зато присутствует в src/backend/utils/mmgr/aset.c
KK
Номера строчки в упор не вижу. На гитхабе в этом файле malloc отсутствует, как класс. Но зато присутствует в src/backend/utils/mmgr/aset.c
Ну так есть таки malloc?
МШ
Есть, но не там.
ЗЫ. я ещё не лазил (и не полезу) смотреть, что за malloc тама используется. А то вполне себе окажется, что на самом деле malloc - это своя реализация, которая с SysV malloc имеет только одно и то же название.
ЗЫ. я ещё не лазил (и не полезу) смотреть, что за malloc тама используется. А то вполне себе окажется, что на самом деле malloc - это своя реализация, которая с SysV malloc имеет только одно и то же название.
KK
malloc - это не sysv
АФ
Всем привет, возник вопрос по таймзонам.
На сервере стоит таймзона UTC, даты хранятся в обычном timestamp,
когда я пишу select created_at at time zone 'Europe/Moscow' я ожидаю увидеть сохранённое время +3 часа, но получаю -3.
Почему это так работает? Как получать дату и время скорректированные под таймзону текущего юзера (она известна, хранится в виде строки)
На сервере стоит таймзона UTC, даты хранятся в обычном timestamp,
когда я пишу select created_at at time zone 'Europe/Moscow' я ожидаю увидеть сохранённое время +3 часа, но получаю -3.
Почему это так работает? Как получать дату и время скорректированные под таймзону текущего юзера (она известна, хранится в виде строки)
DG
created_at at time zone ‘UTC’АФ
created_at at time zone ‘UTC’выводит ровно то, что записано в бд
DG
но зато теперь с типом timestamptz! :)
Хорошо, значит дальше так:
Хорошо, значит дальше так:
(created_at at time zone ‘UTC’) at time zone ‘<нужная TZ>’АФ
но зато теперь с типом timestamptz! :)
Хорошо, значит дальше так:
Хорошо, значит дальше так:
(created_at at time zone ‘UTC’) at time zone ‘<нужная TZ>’мда) Так правильно) Но всё равно странно как-то) Да ещё и двойное преобразование.
Если тип поля на timestamptz сменить, можно будет обойтись одним?
Если тип поля на timestamptz сменить, можно будет обойтись одним?
DG
АФ
понял, спасибо