Re: pg_logical_emit_message() misses a XLogFlush()
От | Tomas Vondra |
---|---|
Тема | Re: pg_logical_emit_message() misses a XLogFlush() |
Дата | |
Msg-id | 4e680b60-9bce-7c4a-0419-f478a30d30e3@enterprisedb.com обсуждение исходный текст |
Ответ на | pg_logical_emit_message() misses a XLogFlush() (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_logical_emit_message() misses a XLogFlush()
|
Список | pgsql-hackers |
On 8/15/23 08:38, Michael Paquier wrote: > Hi all, > > While playing with pg_logical_emit_message() and WAL replay, I have > noticed that LogLogicalMessage() inserts a record but forgets to make > sure that the record has been flushed. So, for example, if the system > crashes the message inserted can get lost. > > I was writing some TAP tests for it for the sake of a bug, and I have > found this the current behavior annoying because one cannot really > rely on it when emulating crashes. > > This has been introduced in 3fe3511 (from 2016), and there is no > mention of that on the original thread that led to this commit: > https://www.postgresql.org/message-id/flat/5685F999.6010202%402ndquadrant.com > > This could be an issue for anybody using LogLogicalMessage() out of > core, as well, because it would mean some records lost. So, perhaps > this should be treated as a bug, sufficient for a backpatch? > Shouldn't the flush be done only for non-transactional messages? The transactional case will be flushed by regular commit flush. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: