Погодите. Если была космическая транзакция, потом комит, а потом другая, которая все это читает.

Она часть из wal будет читать ?

да не читает она ничего из вал

всё что нужно есть в табличках

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

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

просто сперва в вал, а потом в табличку

Она часть из wal будет читать ?

она на локе повиснет

ну ты кот даешь, какие нахуй локи

ридерс донт блок райтерс

mvcc

Погодите. Я спрошу.

Данные пишутся сначала в журнал а потом в таблицы. Эт понятно.

Вопрос в том, когда именно в таблицы? По каждой тупле ? По коммтту все разом ?

ридерс донт блок райтерс

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

В фоне как получится ?

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

Недостаточно понятно

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

представь что вала нет, и всё пишется в файлик с табличкой

представь что вала нет, и всё пишется в файлик с табличкой

Окей

какой теперь твой вопрос?

Тогда вопрос про асинхронные коммиты.

Там типа коммит не коммит вобще. А чот типа барьера.

Хотя погоди. Щас подумаю.

при коммите в списоньке открытых транзакций помечается что всё закончилось

новая транзакция при снапшоте получит новый список и увидит что прошлые тюпли валидные

Во. Я сформулировал вопрос.

Допустим я делаю космическую транзакцию. Все пишется в журнал и в фоне еще и в табличное пространство по принципу "как получится" . Я делаю коммит. Постгрес дожидается пока бетонно запишется в журнал. И говорит мол коммит успешен. На этот момент времени в памяти туева хуча не прописанных в табличные данные туплей. Соответственно, пока они туда не пропишутся, другая транзакция делать ничего не может с этим набором данных. В итоге стоим и ждем.

О.

неверно

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

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

Хмммм. Тоесть держание в памяти не обязательное ?

и будет пробираться в них ища то что она видит в своём снапшоте

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

Про версии это отдельно. Ок ?

ну из памяти оно линуксом скинется на диск

вот и всё

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

вот прям два

Вот щас понятно

Спасибо.

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

Ну так там речь про метаинформацию. Мол какие тупли можно смотреть а какие нельзя. Эт другое.

ну вот есть мета инфа ака clog и куча говна в файликах

от всех прошлых транзакций

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

например

вот прям два

А почему не сделать как в ext4 например? Там же данные в журнал не пишутся...

ну конечно, dataordered, writeback

нахрена эти опции

Это кагбе другое

а, потому что в фс нет mvcc!

Надо читать мне. Срочно.

ну фс она просто перезаписывает блочек данных и говорит что fsync прошел например

от постгреса порой хотят больше чем просто чтото записать

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

если писать данные в журнал и фсинкать его - он пишется последовательно. если писать данные в файлы и фсинкать - это рандом иопс

Тоесть тот самый redo. Он зачем ? Не нужно доделывать оборванную работу. Пусть откатывается целиком…

если не фсинкать - проебали то что закоммитли

Про фсинки эта тема понятна. Я про другое. Щас сформулирую.

Уф. Сложно. Проще спросить как и когда используются тупли из вала.

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

больше вал никогда не читается

ну при условии конечно что тразакция из вала была закомичена

Окей. Теперь супервопрос

Реально. Понимание приходит.

ERROR: S client not available

Минутку.

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

В случае рекавери журнала с 10 асинк транзакциями

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

хотя сказал клиенту что всё записал!

Я понимаю

О чем и спрашиваю

Надо ли писать данные в журнал в этом случае? Мне кажется что нет.

ну так синк раз в секунду в асинке

а не вообще никогда

Вопрос еще раз про писание туплей еще и в журнал для этого режима.

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

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

Я понимаю. Я ожидаю что при крэше отпадет хз сколько последних транзакций

В случае с асинк коммитами.

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

ну то есть, чем это отличается от того что его нет воообще

Инфу о том где эти данные

И номер версии (или как там) которые можно считать засинкаными точно.

Соответственно фсинкать раз в секунду или раз в час. Кому как удобно.

Фстнкать таблицы

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

что теперь

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

А ка профсинкаются все 10 тогда в журнале и гасить флажок трешовости

а куда тогда 5 старых блоков деть, которые перезаписали

Дак не перезаписали же. А дописали в конец какогото табличного файла грубо говоря

Постгрес же не перписывает тупли поверх никогда.

Только поверх мусора (вроде) или вобще только всегда в конец. Я не знаю точно.

так то блоки а то тюпли

но я понял что ты хочешь

ты хочешь аппенд онли