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
|
Список | 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 по дате отправления: