Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: tracking commit timestamps
Дата
Msg-id CA+U5nM+W8XB8b-MvddCsSprxkKq4L6RYqGV1CrjCDeZfd6EXSw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: tracking commit timestamps  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 13 November 2014 21:24, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Nov 13, 2014 at 8:18 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Ordering transactions in LSN order is very precisly the remit of the
>> existing logical decoding API. Any user that wishes to see a commits
>> in sequence can do so using that API. BDR already does this, as do
>> other users of the decoding API. So Slony already has access to a
>> useful ordering if it wishes it. We do not need to anything *on this
>> patch* to enable LSNs for Slony or anyone else. I don't see any reason
>> to provide the same facility twice, in two different ways.
>
> Perhaps you could respond more specifically to concerns expressed
> upthread, like:
>
> http://www.postgresql.org/message-id/BLU436-SMTP28B68B9312CBE5D9125441DC870@phx.gbl
>
> I don't see that as a dumb argument on the face of it.

We have a clear "must have" argument for timestamps to support
replication conflicts.

Adding LSNs, when we already have a way to access them, is much more
of a nice to have. I don't really see it as a particularly nice to
have either, since the SLRU is in no way ordered.

Scope creep is a dangerous thing, so we shouldn't, and elsewhere
don't, collect up ideas like a bag of mixed sweets. It's easy to
overload things to the point where they don't fly at all. The whole
point of this is that we're building something faster than trigger
based systems.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Segmentation fault in pg_dumpall from master down to 9.1 and other bug introduced by RLS
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: using custom scan nodes to prototype parallel sequential scan