Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
От | Simon Riggs |
---|---|
Тема | Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE. |
Дата | |
Msg-id | CANP8+jJsW4e3WcSM2u2K4i-JbrL6Kdc++gD3uZesWybnn2zc+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE. (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
|
Список | pgsql-hackers |
On 15 April 2016 at 20:01, Andres Freund <andres@anarazel.de> wrote:
--
On 2016-04-15 19:59:06 +0100, Simon Riggs wrote:
> For me, the issue is that we need to do something to catch bugs. The
> existing code does not have any test at all to check whether we are doing
> the wrong thing - it just lets the wrong thing happen.
But sending the message, without assigning an xid, *IS* the right thing
to do here? We shouldn't assign an xid, and we need to send the message
out to the standbys.
> Fixing it by forcing a new behaviour might be the right thing to do going
> forwards, but I don't much like the idea of forcing new behaviour in back
> branches. It might fix this bug, but can easily cause others.
What's your alternative? Assigning an xid in the middle of vacuum isn't
ok, breaking vacuum isn't either?
In my understanding we have two choices for this bug
1) assign an xid so it forces sending a message (message plus xid)
2) send a message without assigning an xid (message only)
(1) seems like it is worse for backpatching, IMHO, though I am willing to hear other thoughts or options
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: