Em 31/10/2012 16:34, Tom Lane escreveu:
> Lonni J Friedman <netllama@gmail.com> writes:
>> On Wed, Oct 31, 2012 at 11:01 AM, Edson Richter
>> <edsonrichter@hotmail.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.
Your assumption is right: the slave server is a slow mono processor, low
memory, cloud computer, and would have taken very long time to delete
everything.
>
> In any case, it should have been able to catch up automatically if WAL
> archiving was configured properly.
I don't use WAL archiving - both servers are miles away from each other,
and don't have anything except PostgreSQL async replication over VPN
connecting them.
Edson
>
> regards, tom lane
>
>
