I notice on the documentation page about Asynchronous Commit (
http://www.postgresql.org/docs/8.3/static/wal-async-commit.html*)*, it says
the follow "The user can select the commit mode of each transaction, so that
it is possible to have both synchronous and asynchronous commit transactions
runnin
I'm wrong.
-Dan
On Wed, Jan 12, 2011 at 12:32 PM, Vick Khera wrote:
> On Wed, Jan 12, 2011 at 12:03 AM, Dan Birken wrote:
> > If I commit asynchronously and then follow that with
> a synchronous commit,
> > does that flush the asynchronous commit as well?
>
> I'
(I am not the OP, but recently went through the same thing so I'll chime in)
Reading through the documentation now (albeit with a now pretty good
understanding of how everything works), I think the main confusing thing is
how different bits which apply to file-base log shipping, streaming
replicat
If the standby server cannot pull the WAL file from the master using
streaming replication, then it will attempt to pull it from the archive. If
the WAL segment isn't archived (for example because you aren't using
archiving), then your streaming replication is unrecoverable and you have to
take a
I am running a pg_receivexlog 9.2 client against a 9.1 server. It seems to
work. Comments in the code seem to indicate that this setup is workable.
However, pg_receivexlog is not part of the 9.1 source tree nor the rpm
package (as far as I see), so I am curious if there is some caveat that I
sur
Update: I have successfully used this configuration with a month's worth of
WALs (tens of thousands), run a test restore, and everything appears to
have worked as expected. So at least based on that test, this
configuration seems fine.
-Dan
On Fri, May 24, 2013 at 4:42 PM, Dan Birken
What is your "max_standby_streaming_delay" set at?
If your pg_dump takes longer than your "max_standby_streaming_delay" (which
is likely since the default is 30s), you might get that error as well. This
setting tells your standby how long it should wait to apply conflicting WAL
files to finish a
