Re: Analysis of ganged WAL writes

Поиск
Список
Период
Сортировка
От Curtis Faith
Тема Re: Analysis of ganged WAL writes
Дата
Msg-id DMEEJMCDOJAKPPFACMPMKEGCCEAA.curtis@galtair.com
обсуждение исходный текст
Ответ на Re: Analysis of ganged WAL writes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Analysis of ganged WAL writes
Список pgsql-hackers
> > Since in your case all transactions A-E want the same buffer written,
> > the memory (not it's content) will also be the same.
>
> But no, it won't: the successive writes will ask to write different
> snapshots of the same buffer.

Successive writes would write different NON-OVERLAPPING sections of the
same log buffer. It wouldn't make sense to send three separate copies of
the entire block. That could indeed cause problems.

If a separate log writing process was doing all the writing, it could
pre-gang the writes. However, I'm not sure this is necessary. I'll test the
simpler way first.

> > The problem I can see offhand is how the kaio system can tell which
> > transaction can be safely notified of the write,
>
> Yup, exactly.  Whose snapshot made it down to (stable) disk storage?

If you do as above, it can inform the transactions when the blocks get
written to disk since there are no inconsistent writes. If transactions A,
B and C had commits in block 1023, and the aio system writes that block to
the disk, it can notify all three that their transaction write is complete
when that block (or partial block) is written to disk.

It transaction C's write didn't make it into the buffer, I've got to assume
the aio system or the disk cache logic can handle realizing that it didn't
queue that write and therefore not inform transaction C of a completion.

- Curtis



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Curtis Faith"
Дата:
Сообщение: Re: Analysis of ganged WAL writes
Следующее
От: iafmgc@unileon.es
Дата:
Сообщение: genetic query optimization