Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
От | Andres Freund |
---|---|
Тема | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
Дата | |
Msg-id | 20131202181910.GC15336@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2013-12-02 09:59:12 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > I think we also needs support for testing xid/multixid wraparound. It > > currently isn't realistically testable because of the timeframes > > involved. > > When I've wanted to do that in the past, I've used pg_resetxlog to > adjust a cluster's counters. I've done that as well, but it's painful and not neccessarily testing the right thing. E.g. I am far from sure we handle setting the anti-wraparound limits correctly when promoting a standby - a restart to adapt pg_control changes things and it might get rolled back because of a already logged checkpoints. What I'd love is a function that gives me the opportunity to *efficiently* move forward pg_clog, pg_multixact/offset,members by large chunks. So e.g. I could run a normal pgbench alongside another pgbench moving clog forward in 500k chunks, but so it creates the necessary files I could possibly need to access. If you do it naivly you get into quite some fun with hot standby btw. I can tell you that from experience :P Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: