From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Lonni J Friedman <netllama(at)gmail(dot)com> |
Cc: | Edson Richter <edsonrichter(at)hotmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: dropdb breaks replication? |
Date: | 2012-10-31 18:34:19 |
Message-ID: | 14197.1351708459@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Lonni J Friedman <netllama(at)gmail(dot)com> writes:
> On Wed, Oct 31, 2012 at 11:01 AM, Edson Richter
> <edsonrichter(at)hotmail(dot)com> wrote:
>> May the cause not having enough segments (currently 80) for dropdb command?
>> Is dropdb logged in transaction log page-by-page excluded?
> I can't read portugese(?), but i think the gist of the error is that
> the WAL segment was already removed before the slave could consume it.
> I'm guessing that you aren't keeping enough of them, and dropping the
> database generated a huge volume which flushed out the old ones before
> they could get consumed by your slave.
dropdb generates one, not very large, WAL record saying "go rm -rf this
directory". So sheer WAL volume is not the correct explanation. It's
possible though that the slave spent long enough executing the rm -rf
to fall behind the master.
In any case, it should have been able to catch up automatically if WAL
archiving was configured properly.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Edson Richter | 2012-10-31 18:34:48 | Re: dropdb breaks replication? |
Previous Message | Mike Christensen | 2012-10-31 18:25:26 | Re: Boolean type storage format |