"D" в ACID разве не об этом?

она нужна для защиты от аппаратного сбоя

Я про это

нет

Подитог: Durability - обеспечивается как самой СУБД, так и программистом, Программист должен думать о гарантии исполнения атомарной транзакции. И если таковая не проихошла либо разбирать данный момент, либо повторить её, для записи

Верно?

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

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

Господи, как же я косноязычен. В общем, ACID - это свойства только базы данных, пользователь должен знать о них и понимать, о чем ему говорит БД, но непосредственно в самих процессах он участия не принимает (хоть и может корректировать их поведение).

Ясно. Спасибо за коллетивное разъяснение. -1 рука из жопы :)

Верно?

Думаю, что если в серьёз задумались, то лучше это почитать: https://postgrespro.ru/docs/postgresql/9.6/high-availability.html

Тут перемежаются области программирования и администрирования

Вам то скажут тут

как в общих чертах оно есть, но как конкретно у Вас настроил кто-то сервер

может сильно повлиять на Ваши ожидания/уверенность о сохранности данных

Думаю, что если в серьёз задумались, то лучше это почитать: https://postgrespro.ru/docs/postgresql/9.6/high-availability.html

Спасибо. Я задумался по нескольким причинам. 1. База с которой я работаю - взаимодействует с 5 сервисами. Она не только отдает данные, но и получает от них. Все эти сервисы работаюют либо как тонкий клиент, либо как самостоятельное приложение с собственной БД работающий через API. 2. Некоторые таблицы используются крайне часто для SELECT (например база адресов), а некоторые только для INSERT (например история изменения строк) 3. В неокторых таблицах важно, чтобы ни одна операция не потерялась. Конечно это не фин операции, но если работа менеджера потеряется - звонить клиенту опять не получится. 4. Производительность сейчас обеспечивается встроенным функционалом postgres + добавлением нужных индексов. 5. Сейчас реже, но раньше сервак уходил в глухую оборону (если, например брутфорсили активно).

Вроде разносторонние проблемы. Но упираются они все равно в БД. И если, например, целостность данных не настолько критична, всеравно с каждым днем важность растет. А я не хочу ждать пока по голове хлопнет проблемой и пытаюсь думать об этом наперед. Ну и потом. В этом мире все сталкиваются с чужими ТВАРеньями. А значит вполне может возникнуть ситуация, когда вы будет ковыряться в каше и думать обо мне нехорошо ? Больше всего нехочу этого :)

Поэтому еще раз спасибо за ссылки и консультацию

Вроде разносторонние проблемы. Но упираются они все равно в БД. И если, например, целостность данных не настолько критична, всеравно с каждым днем важность растет. А я не хочу ждать пока по голове хлопнет проблемой и пытаюсь думать об этом наперед. Ну и потом. В этом мире все сталкиваются с чужими ТВАРеньями. А значит вполне может возникнуть ситуация, когда вы будет ковыряться в каше и думать обо мне нехорошо ? Больше всего нехочу этого :)

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

брутфорс решается наполовину админресурсом. Большая часть паттернов закрывается на уровне "до приложения" через denyhosts etc.

В любом случае к БД это доходить не должно

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

Еще вопрос. Я запустил удаление по критериям. Из 10 000 000 будет удалено 9 500 000 строк. Судя по тому что количество записей не изменилось, а удаление происходит уже час - удаление выполняется атомарно.

Я прав?

конечно

А как сделать чтобы это работало налету?

Или это бред?

а в чем твоя проблема-то?

Еще вопрос. Я запустил удаление по критериям. Из 10 000 000 будет удалено 9 500 000 строк. Судя по тому что количество записей не изменилось, а удаление происходит уже час - удаление выполняется атомарно.

возможно дешевле будет скопировать те 500К строк в новую таблицу, а старую дропнуть )

create table temp_myTable as select * from mytable where rows_should_not_be_delete truncate table mytable alter table temp_mytable rename to mytable;

но там еще индексы пересозданть/, и constraint нужно будет доделать

хм... а почему удаление дольше создания?

потому что в удалении тебе надо в 9 500 000 строк написать, что они больше не видны

а потом сделать репак)

но там еще индексы пересозданть/, и constraint нужно будет доделать

или сделать create table temp_myTable (like mytable including all), чтобы скопировать констрейнты

можно и так

или сделать create table temp_myTable (like mytable including all), чтобы скопировать констрейнты

это типа с индексами?

хм... а почему удаление дольше создания?

потому что удаление пишет кучу валов и обновляет индексы

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

это типа с индексами?

ага, копирует полностью структуру таблицы. За исключением каких-то options-ов типа fillfactor и т.п.

Но всё же быстрее в новую таблицу скопировать

ещё лучше эти строки просто не писать в ту таблицу

или сделать create table temp_myTable (like mytable including all), чтобы скопировать констрейнты

SERIAL занчения будут как в начальной таблице?

create table temp_myTable (like mytable including all) as select * from mytable where ... Вот так получится. Верно?

сериал это синтакически сахар оберка вокрут nextval('seq_name')

ну проще говоря id тоже перенесутся без проблем и не с единицы

Я в свое время сталкивался что если в serial давать произвольный int - он ругался

я там ошибся вместо truncate table там begin; drop table myTable; alter table temp_myTable renamte to myTable; end;

ну проще говоря id тоже перенесутся без проблем и не с единицы

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

explain ?

ну вот неделю назад приучился всё страшное и непонятное через эксплейн делать. :)

у датагрипа хороший хайлайтер синтаксиса

ну он и подсвечивает ошибку

если он что-то подчёркивает, то скорее всего оно невалидная конструкция

там опечатка, t в rename лишняя

ну вот неделю назад приучился всё страшное и непонятное через эксплейн делать. :)

в доках написано что expain analyze при страшном update, delete не поможет только через rollback внутри транзакции

если я не ошибаюсь, то CREATE TABLE AS это не та же самая команда, что и обычный CREATE TABLE. Поэтому сначала CREATE TABLE .. (LIKE ...). А потом INSERT INTO temp_myTable SELECT <ваш селект>

ясно

Вроде датагрип не ругается

на вид да я обычно разворачиваю наоборот, как-то вроде begin; create temporary table aaa as (select * from mytable where ....); truncate mytable; insert into mytable select * from aaa; commit;

тогда таблица точно-точно остаётся той же самой :)

это мне больше нравится. lemi gi, без обид. Твоя тоже клевая :)

ERROR: S client not available

на вид да я обычно разворачиваю наоборот, как-то вроде begin; create temporary table aaa as (select * from mytable where ....); truncate mytable; insert into mytable select * from aaa; commit;

Пытался сделать процедуру, чтобы не искать потом. Оказалось не прокатит

@Komzpa

Ну или с Товальдcом... без разницы к кому взывать

главное что б бекап был

Я бэкап разворачивать буду минут 20-30

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

Но это никак не спасет, если в логике баг :)

не тот смайл. :(

1 косяк нашёл. в запросе ? Но вот эти самые транзакции спасли

спасибо

Ну или с Товальдcом... без разницы к кому взывать

со стоунбрекером?

select a.* from mods_monitoring_arguments a join mods_monitoring b on a.sub=b.id

select a.* from mods_monitoring_arguments a join mods_monitoring b on a.sub=b.id

Видимо мне надо внимательно почитать разницу между джойном и вложенным запросом...

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

иногда это хорошо, иногда нежелательно

Вложенный запрос с таким же связью полей разложится в джойн, как выше.

*планировщиком

После ctrl+c выбивает

сделай rollback; и начни с начала

иногда это хорошо, иногда нежелательно

сейчас замучу по обоим вариантам план

Ну так, наглядности ради. тут же есть еще ~800 человек

Чето вложенный селект вообще долгий

план уже минуты 3 крутит

explain, не explain analyse

Сравнение https://explain.depesz.com/s/v0r4 https://explain.depesz.com/s/i0Yz

in (и здесь 500тыс ) ? :)

да :)

Добрый день подскажите пожалуйста ON DUPLICATE KEY UPDATE -в mysql = CONFLICT в постгре? верно же?

просто переписывал sql запрос с mysql на постгрю и выгорает теперь вот такая проблема missing FROM-clause entry for table "tablename" в этом месте insert my_table (id , ... , last_col) select id , ... last_col from tablename where tablename.picture is not null ON CONFLICT (id) DO UPDATE SET my_table.price = tablename.price <-- вот тут ошибка получается подскажите что не так пожалуйста