On 2014-03-17 08:00:22 -0400, Robert Haas wrote:
> > Yea. The reason it reports the flush position is that it allows to test
> > sync rep. I don't think other usecases will appreciate frequent
> > fsyncs... Maybe make it optional?
>
> Well, as I'm sure you recognize, if you're actually trying to build a
> replication solution with this tool, you can't let the database throw
> away the state required to suck changes out of the database unless
> you've got those changes safely stored away somewhere else.
Hm. I don't think a replication tool will use pg_recvlogical, do you
really forsee that? The main use cases for it that I can see are
testing/development of output plugins and logging/auditing.
That's not to say safe writing method isn't interesting tho.
> Perhaps there could be a switch for an fsync interval, or something
> like that. The default could be, say, to fsync every 10 seconds. And
> if you want to change it, then go ahead; 0 disables. Writing to
> standard output would be documented as unreliable. Other ideas
> welcome.
Hm. That'll be a bit nasty. fsync() is async signal safe, but it's still
forbidden to be called from a signal on windows IIRC. I guess we can
couple it with the standby_message_timeout stuff.
Unless you have a better idea?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services