Re: pg_logical_emit_message() misses a XLogFlush()

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

In response to

Responses

Browse pgsql-hackers by date

  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)