Re: pg_receivexlog --status-interval add fsync feedback

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, furuyao(at)pm(dot)nttdata(dot)co(dot)jp, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, teranishih(at)nttdata(dot)co(dot)jp
Subject: Re: pg_receivexlog --status-interval add fsync feedback
Date: 2014-10-23 14:39:58
Message-ID: CAHGQGwH3-mOwECkGP8Mv1ALWHH+0fneMw7gz-5KrXe66KGg0OQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 22, 2014 at 10:47 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 22 October 2014 14:26, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
>
>> We seem to be going in circles. You suggested having two options,
>> --feedback, and --fsync, which is almost exactly what Furuya posted
>> originally. I objected to that, because I think that user interface is too
>> complicated. Instead, I suggested having just a single option called
>> --synchronous

I'm OK with this. But the option name "synchronous" seems confusing
because pg_receivexlog with sync option can work as async standby.
So the better name is needed.

> or even better, have no option at all and have the server
>> tell the client if it's participating in synchronous replication, and have
>> pg_receivexlog automatically fsync when it is, and not otherwise [1]. That
>> way you don't need to expose any new options to the user. What did you think
>> of that idea?
>
> Sorry, if we're going in circles.
>
> Yes, I like the idea.
>
> The master setting of synchronous_standby_names defines which
> standbys/rep clients will have their feedback used to release waiting
> COMMITs. That uses application_name, which is set at the replication
> client connection. (That has a default value, but lets assume the user
> sets this). So when a replication client connects, the WALSender knows
> its priority, as defined in sync_standby_names.
>
> I guess we can have WALSender send a protocol message to the client
> every time the sync priority changes (as a result of a changed value
> of sync_standby_names). Which is the function SyncRepInitConfig()

Sorry, I'm going around in the circle. But I'd like to say again, I don't think
this is good idea. It prevents asynchronous pg_receivexlog from fsyncing
WAL data and sending feedbacks more frequently at all. They are useful,
for example, when we want to monitor the write location of asynchronous
pg_receivexlog in almost realtime. But if we adopt the idea, since feedback
cannot be sent soon in async mode, pg_stat_replication always returns
the not-up-to-date location.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-10-23 14:48:01 Re: Simplify calls of pg_class_aclcheck when multiple modes are used
Previous Message Florian Pflug 2014-10-23 14:37:46 KEY UPDATE / UPDATE / NO KEY UPDATE distinction vs. README.tuplock