PostgreSQL - просто так исчезла БД из списка

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

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

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

SELECT именно в таком порядке

Порядок SELECT без ORDER BY (или с сортировкой по неуникальным кортежам) неопределён и может произвольно меняться от вставок, удалений, vacuum и т. д. В общем, он почти как ORDER BY RANDOM(), только ещё и не RANDOM (выдаёт один и тот же порядок много раз подряд, пока ЧТО-ТО не случится).

Добавляй auto increment колонку и делай ORDER BY по ней. Или делай колонку created_at timestamp default current_timestamp и сортируй по ней.

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

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

систематическая ошибка выжившего.

А если бы использовалась sqlite – шансов на восстановление базы возрастали бы.

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

Это UB.

Если у тебя в SELECT нет ORDER BY – никакого определённого порядка выдачи ты ждать не имеешь права.

началось всё с того, что в одной из таблиц список вида:

который всегда выдавал SELECT именно в таком порядке, как он изначально прописан в sql-файле…

опустим вопрос «а чё это было?»

и правда, с такими вводными может быть всё, что угодно.

слушай, я бы понял, если бы было, что угодно
но когда вылазит конкретная строка
которая за годы (НИ В ОДНОМ СПРАВОЧНИКЕ) никогда НЕ вылезала
при этом, даже если её закомментить, то сразу вылезет следующая
когда во всех остальных справочниках всё идеально
то
я это записываю в баги
как минимум, в отклонение от нормы

я это записываю в баги

У тебя проблема с чтением документации. СУБД не обязана тебе выводить строки в предсказуемом порядке, если не указаны поля для сортировки.

After a query has produced an output table (after the select list has been processed) it can optionally be sorted. If sorting is not chosen, the rows will be returned in an unspecified order. The actual order in that case will depend on the scan and join plan types and the order on disk, but it must not be relied on. A particular output ordering can only be guaranteed if the sort step is explicitly chosen.

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

Вы ведь даже примерно не представляете как внутри БД работает? Там такие оптимизации есть, которые могут вот так порядок вывода шатать легко. О том что порядок вывода не определён если нет ORDER BY написано на первых 10 страницах любого учебника по SQL

Расскажи об этой проблеме разработчикам PostgreSQL. https://www.postgresql.org/docs/current/bug-reporting.html

Ты сам сказал, что vacuum сломал порядок. Аналогично, может сломать порядок удаление строки, обновление версии БД и т д.

В логи постгри мы конечно смотреть не будем.

нет, вакуум был для исправления

Добавляй auto increment колонку

У него там есть уже поле с целочисленным представлением времени, ему надо было добавить ORDER BY … NULLS FIRST но видимо он слишком крут для такого.

Попробую другую БД, там порядок строк строго детерминированный. Локальная версия называется Excel; облачная, продвинутая — Google Sheets.

а теперь расскажи нам как ты ее оптимизировал?

а уж как велики они были бы на простых файлах, мммм ))) (вместо sqlite-то))