Re: Reporting the commit LSN at commit time

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reporting the commit LSN at commit time
Дата
Msg-id 19253.1407441276@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Reporting the commit LSN at commit time  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: Reporting the commit LSN at commit time  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
Craig Ringer <craig@2ndquadrant.com> writes:
> Hi all
> To support transparent client-side failover in BDR, it's necessary to
> know what the LSN of a node was at the time a transaction committed and
> keep track of that in the client/proxy.

> I'm thinking about adding a new message type in the protocol that gets
> sent immediately before CommandComplete, containing the LSN of the
> commit. Clients would need to enable the sending of this message with a
> GUC that they set when they connect, so it doesn't confuse clients that
> aren't expecting it or aware of it.

FWIW, I think it's a seriously bad idea to expose LSNs in the protocol
at all.   What happens five years from now when we switch to some other
implementation that doesn't have LSNs?

I don't mind if you expose some other way to inquire about LSNs, but
let's *not* embed it into the wire protocol.  Not even as an option.

This position also obviates the need to complain about having a GUC
that changes the protocol-level behavior, which is also a seriously
bad idea.
        regards, tom lane



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: B-Tree support function number 3 (strxfrm() optimization)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: B-Tree support function number 3 (strxfrm() optimization)