Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: tracking commit timestamps
Дата
Msg-id CA+U5nMKubjE2-DBXCkBmnaGgDzuaYUBa5v0AGxg8z+tfsiWA8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Petr Jelinek <petr@2ndquadrant.com>)
Ответы Re: tracking commit timestamps  (Petr Jelinek <petr@2ndquadrant.com>)
Список pgsql-hackers
On 19 November 2014 02:12, Petr Jelinek <petr@2ndquadrant.com> wrote:

> Maybe we need better explanation of the LSN use-case(s) to understand why it
> should be stored here and why the other solutions are significantly worse.

We should apply the same standard that has been applied elsewhere. If
someone can show some software that could actually make use of LSN and
there isn't a better way, then we can include it.

PostgreSQL isn't a place where we speculate about possible future needs.

I don't see why it should take 2+ years of prototypes, designs and
discussions to get something in from BDR, but then we simply wave a
hand and include something else at last minute without careful
thought. Even if that means that later additions might need to think
harder about upgrades.

Timestamp and nodeid are useful for a variety of cases; LSN doesn't
meet the same standard and should not be included now.

We still have many months before even beta for people that want LSN to
make a *separate* case for its inclusion as a separate feature.

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



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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: postgres_fdw behaves oddly
Следующее
От: Albe Laurenz
Дата:
Сообщение: Unlogged tables can vanish after a crash