Re: Proposal: Generic WAL logical messages - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Proposal: Generic WAL logical messages
Date
Msg-id 568EEBFE.9050908@2ndquadrant.com
Whole thread Raw
In response to Re: Proposal: Generic WAL logical messages  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Proposal: Generic WAL logical messages
List pgsql-hackers
On 2016-01-07 17:22, Simon Riggs wrote:
>
> * You call them "logical messages" here, but standby messages in code.
> But they only apply to logical decoding, so "logical message" seems a
> better name. Can we avoid calling them "messages" cos that will get
> confusing.
>

Yes it's slightly confusing, the "Standby" in the code is mostly for 
consistency with other "Standby*" stuff in neighbouring code, but that 
can be changed. I don't have better name than "messages" though, 
"records" is too generic.

>     For standard WAL reply, these are basically noop
>
>
> We should document that.

Okay.

>
>     These messages can be both transactional (decoded on commit) or
>     non-transactional (decoded immediately). Each message has prefix to
>     differentiate between individual plugins. The prefix has to be
>     registered exactly once (in similar manner as security label
>     providers) to avoid conflicts between plugins.
>
>
> I'm not sure what "transactional" means, nor is that documented.
> (Conversely, I think "immediate" fairly clear)
>
> Are they fired only on commit? (Guess so)
> Are they fired in the original order, if multiple messages in same
> transaction? (Hope so)
> Are they fired as they come in the original message sequence, or before
> anything else or after everything else? For example, cache invalidation
> messages are normally fired right at the end of a transaction, no matter
> when they were triggered.
>

Transnational message is added to the stream same way as any DML 
operation is and has same properties (processed on commit, original 
order, duplicate messages are delivered as they are).

The immediate as you say is obvious, they get to logical decoding 
immediately without dealing with any regards to what's happening around 
(wal order is still preserved though).

Will make this clearer in the docs.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Windows: Make pg_ctl reliably detect service status
Next
From: Michael Paquier
Date:
Subject: Re: Function and view to retrieve WAL receiver status