Em 31/10/2012 16:34, Tom Lane escreveu:
Lonni J Friedman <netll...@gmail.com> writes:
On Wed, Oct 31, 2012 at 11:01 AM, Edson Richter
<edsonrich...@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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
