From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_logical_emit_message() misses a XLogFlush() |
Date: | 2023-08-15 09:37:32 |
Message-ID: | 4e680b60-9bce-7c4a-0419-f478a30d30e3@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2023-08-15 09:40:29 | Re: pgbench: allow to exit immediately when any client is aborted |
Previous Message | Fabien COELHO | 2023-08-15 09:26:55 | Re: LLVM 16 (opaque pointers) |