Здравствуйте.

Возник такой вопрос. Уже с ног сбился искать ответ.

Вот допустим у firebird есть такое понятие как формат записи, который даже хранится в соответствующий таблицах. Ну что то вроде layout полей записи таблицы на диске. Как , в какой последовательности и каких размеров лежат на страницах в базе значения полей как таковых. Ну и при добавлении —удалении полей в таблице формат меняется и у новых строк таблицы соответствующий байт проставляется.

А как это все организовано в postgre? Нашел описание формата страницы, формат тупла. Но в конце заголовка тупла идет просто— user data.

А вроде как постргре в этой user data может и пропускать поля (например которые null), и может даже переставить местами поля, использовать выравнивание. И все это применимо к индивидуальной записи таблицы(хотя могу ошибаться)

Собственно где почитать как сервер понимает где какое поле в user data лежит

Melkijsergq,

по https://www.postgresql.org/docs/current/catalog-pg-attribute.html системной таблице. Структура самой системной таблицы - hardcoded.

sergqможет даже переставить местами поля, использовать выравнивание
переставлять не может. Выравнивание производится всегда.
NULL в user data не пишется, NULL - это битовая маска в заголовке тапла

те перед запросом по этой табличке просто высчитывает смещения.

чтоб не открывать тему еще одну. Что происходит , когда я допустим в одну большую таблицу (по количеству записей) добавляю поле.
тот же fb сформирует описание нового формата и уже новые строки будет вставлять со ссылкой на это описание. быстро и экономично.
А в постгре как? раз "компилированного" формата нет, то получается он должен обновить все записи в базе. ну или на худой конец у всех записей базы поменять null bitmap

Melkijsergqте перед запросом по этой табличке просто высчитывает смещения.
Нет. Перед запросом высчитывать нечего.
Спозиционироваться сразу на нужное поле при обработке конкретного тапла можно только если все поля до него фиксированной длины и not null. Иначе честно разбираем тапл.
Сам тапл в странице берём честно вычитывая структуру страницы.

sergqЧто происходит , когда я допустим в одну большую таблицу (по количеству записей) добавляю поле.
default null - запись в системном каталоге и всё.
default константа - начиная с pg11 запись в системном каталоге, fastdefault отдельно добавленная машинерия
default что-то другое - перепишет всю таблицу.

Ну примерно так и представлял. Единственное в данном случае непонятен такой момент.
Допустим стартовала первая транзакция. Запрос читает из таблицы с тремя полями. Читает с паузами. Какой нибудь sleep после каждой записи. Стартует вторая транзакция. Добавляет поле null. По идее в этот момент во внутренностях сервера (где нибудь в RelationData) добавилось описание четвертого поля. А первая транзакция все читает с паузами. И «думает», что в таблице три поля. Она (вернее запрос в этой транзакции) так и будет думать, что в таблице три поля? Последующие запросы в первой транзакции будут видеть три или четыре поля?

MelkijsergqСтартует вторая транзакция. Добавляет поле null
Вы вот тут вот ошибаетесь: не добавляет. А только хочет добавить, но сначала ждёт все транзакции, которые любым образом затрагивали эту таблицу и потому хоть даже и мелкую читающую ACCESS SHARE блокировку, но удерживают. Потому что add column нужен AccessExclusiveLock, который конфликтует со всем прочим.

При этом alter table себя регистрирует в обычно очереди ожидания блокировок и поэтому здесь есть неприятная картина для активно-используемых таблиц: alter table ещё ничего не делает, т.к. ждёт блокировку, но уже блокирует всё и всех кто приходит после начала ожидания блокировки.

Логично. Есть где почитать более менее доходчиво по типам блокировок и когда они применяются?

Задам еще один вопрос. Надеюсь последний)
Есть такие два флага. Heap_xmin_invalid ну и макс. Что есть invalid? В описании написано invalid/aborted. Aborted можно предположить это rollback
А что есть инвалид? Пробовал ковырять эти флаги. Работа в отдельных транзакциях. Последовательно.

Добавляем запись. Флаги heap_xmax_invalid. Слегка недопонимаю почему инвалид. Тк в данном случае она равна нулю

Потом вычитываем строку. Флаги меняются. Добавляется признак коммита min. Логично. Max так и остается инвалид.

Обновляем запись. В старой версии xmin с признаком commited. Логично. Про max нет флагов. Тоже логично. Тк на момент записи она активна. А у новой версии помимо всего прочего появляется max invalid. И равна она нулю. Тоже логично.

Те получается max invalid стоит только тогда, когда она равна нулю?