On Thu, Jul 11, 2013 at 11:31 PM, hubert depesz lubaczewski
<depesz@depesz.com> 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@depesz.com> wrote:
>>
>> > We are seeing situation like this:
>> > 1. 9.2.4 database
>> > 2. Master settings:
>> > name | setting
>> > ---------------------------+---------------
>> > fsync | on
>> > synchronize_seqscans | on
>> > synchronous_commit | remote_write
>> > synchronous_standby_names | *
>> > wal_sync_method | open_datasync
>> > (5 rows)
>> >
>> > 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?
> After all - all commits should wait for slave to be 100% up to date!
>
Is it possible that xlog recycling might have caused this wherein the
xlog segment which is yet to be archived/shipped is recycled? I
remember something of that sort. Check this discussion:
http://www.postgresql.org/message-id/51779B3B.1020003@lab.ntt.co.jp
Is this logged on the master or a standby?
--
Amit Langote