Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel
Дата
Msg-id 17220.1349922681@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel  (Greg Stark <stark@mit.edu>)
Ответы Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel  (Andres Freund <andres@2ndquadrant.com>)
Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel  (Hannu Krosing <hannu@krosing.net>)
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Isn't there an even more serious problem, namely that this assumes
>> *all* transactions are serializable?  What happens when they aren't?
>> Or even just that the effective commit order is not XID order?

> I don't think it assumes the transactions are serializable because
> it's only concerned with writes, not reads. So the transaction it's
> replaying may or may not have been able to view the data written by
> other transactions that commited earlier but it doesn't matter when
> trying to reproduce the effects using constants.

I would believe that argument if the "apply" operations were at a
similar logical level to our current WAL records, namely drop these bits
into that spot.  Unfortunately, they're not.  I think this argument
falls to the ground entirely as soon as you think about DDL being
applied by transactions A,B,C and then needing to express what
concurrent transactions X,Y,Z did in "source" terms.  Even something as
simple as a few column renames could break it, let alone anything as
esoteric as changing the meaning of datatype literals.
        regards, tom lane



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Warnings from fwrite() in git head