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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers