On Thu, Jul 11, 2013 at 11:01 AM, hubert depesz lubaczewski <depesz@xxxxxxxxxx> wrote: > On Thu, Jul 11, 2013 at 11:29:24PM +0530, Raghavendra wrote: >> On Thu, Jul 11, 2013 at 11:18 PM, hubert depesz lubaczewski < >> depesz@xxxxxxxxxx> wrote: >> >> > >> > Yet, every now and then we're getting: >> > FATAL: requested WAL segment * has already been removed >> > >> > Assuming no part of the system is issuing "set synchronous_commit >> > = off", how can we get in such situation? >> > >> > Best regards, >> > >> > depesz >> > >> > >> Increasing the wal_keep_segments ? > > I know that I can increase wal_keep_segments to "solve" it, but > shouldn't it be *impossible* to happen with synchronous replication? If a single transaction spans over both log switch boundaries and checkpoint boundaries (at least two of the later, I think) it is possible for a file to be recycled before the commit, and hence before any attempt to synch-to-standby has occured. > After all - all commits should wait for slave to be 100% up to date! But if the file isn't there on the sending end, no amount of waiting can help. It looks like what is needed is to invoke the SyncRepWaitForLSN code just before log file recycle, as well as upon transaction commit. I'm not sure why that isn't already done indirectly. Doesn't the checkpointer insert a WAL record upon completion of a checkpoint indicating that completion, before any recycling is attempted? Surely the LSN of that record is higher than that in any file becoming eligible for recycling. But I guess that that record is not a commit record, so does not trigger the sync rep. Cheers, Jeff -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
