> You introduced the state machine using the flag "flush_flg" into
> pg_receivexlog.
> That's complicated and would reduce the readability of the source code.
> I think that the logic should be simpler like walreceiver's one.
> Maybe I found one problematic path as follows:
> 1. WAL is written and flush_flag is set to 1 2. PQgetCopyData() returns
> 0 and flush_flg is incremented to 2 3. PQconsumeInput() is executed 4.
> PQgetCopyData() reads keepalive message 5. After processing keepalive
> message, PQgetCopyDate() returns 0 6. Since flush_flg is 2, WAL is
> flushed and flush_flg is reset to 0
> But new message can arrive while processing keepalive message. Before
> flushing WAL, such new message should be processed.
Together with the readability, fixed to the same process as the loop of 

> +        Enables synchronous mode. If replication slot is disabled then
> +        this setting is irrelevant.
> Why is that irrelevant in that case?
> Even when replication slot is not used, thanks to this feature,
> pg_receivexlog can flush WAL more proactively and which may improve the
> durability of WAL which pg_receivexlog writes.
It's mean, report the flush position or not.
If the SLOT is not used, it is not reported.
Fixed to be reported only when using the SLOT.

> +    printf(_("  -m, --sync-mode        synchronous mode\n"));
> I think that calling this feature "synchronous mode" is confusing.
Modified the "synchronous mode" to "this mode is written some records, flush 
them to disk.".


Furuya Osamu

Attachment: pg_receivexlog-add-synchronous-mode-v4.patch
Description: pg_receivexlog-add-synchronous-mode-v4.patch

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to