| From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
|---|---|
| To: | Daniel Farina <daniel(at)heroku(dot)com> |
| Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, simon(at)2ndquadrant(dot)com, heikki(dot)linnakangas(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Sync Rep v17 |
| Date: | 2011-02-22 13:04:08 |
| Message-ID: | 4D63B448.6010204@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Daniel Farina wrote:
> As it will be somewhat hard to prove the durability guarantees of
> commit without special heroics, unless someone can suggest a
> mechanism.
Could you introduce a hack creating deterministic server side crashes in
order to test this out? The simplest thing that comes to mind is a rule
like "kick shared memory in the teeth to force a crash after every 100
commits", then see if #100 shows up as expected. Pick two different
small numbers for the interval and you could probably put that on both
sides to simulate all sorts of badness.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-02-22 13:16:08 | Re: CopyReadLineText optimization revisited |
| Previous Message | Cédric Villemain | 2011-02-22 13:03:35 | Re: UNLOGGED tables in psql \d |