Re: Assertion failure when streaming logical changes

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Assertion failure when streaming logical changes
Дата
Msg-id CAMsr+YFOGMzavXPB=d2etym-fd-E4pTn5ME1Xu41yEUETPJiMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Assertion failure when streaming logical changes  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers


On 10 February 2015 at 21:43, Andres Freund <andres@2ndquadrant.com> wrote:
On 2015-02-10 22:06:34 +0900, Michael Paquier wrote:
> On Tue, Feb 10, 2015 at 9:46 PM, Andres Freund <andres@2ndquadrant.com>
> wrote:
>
> > Yea, it really looks like the above commit is to "blame". The new xmin
> > tracking infrastructure doesn't know about the historical snapshot...
> >
>
> I think that we need a better regression coverage here... For example, we
> could add some tap tests in test_decoding to test streaming of logical
> changes. This would help in the future to detect such problems via the
> buildfarm.

I agree. It's more or less a accident that the assert - which just
should be moved in the regd_count == 0 branch - didn't trigger for the
SQL interface. The snapshot acquired by the SELECT statement prevents it
there.

It's not entirely trivial to add tests for receivelogical though. You
need to stop it programatically after a while.


I reckon we should improve that then.

What about an idle timeout for pg_recvlogical, so we can get it to time out after (say) 5 seconds of no data? Time-based facilities aren't great in tests though.

The SQL interface can stop after a given number of changes received or a target LSN. Is there a practical reason pg_recvlogical doesn't? Or just that there wasn't a reason to implement it? I figured I'd ask before jumping in and trying to add it in case I'd be wasting my time trying.

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

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Sloppy SSPI error reporting code
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Something is rotten in the state of Denmark...