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.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Add new catalog called pg_init_privs