From: | Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSI and Hot Standby |
Date: | 2011-01-20 02:06:17 |
Message-ID: | 20110120020617.GA87714@csail.mit.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kevin's suggestion seems eminently reasonable to me and probably the
best approach one can do for SSI and hot standby. Pulling it off in
time for 9.1 would be a stretch; 9.2 seems quite doable.
It's worth noting that one way or another, the semantics of
SERIALIZABLE transactions on hot standby replicas could be surprising
to some. There's no getting around this; serializability in distributed
systems is just a hard problem in general. Either we go with Kevin's
suggestion of treating SERIALIZABLE transactions as DEFERRABLE (whether
now or for 9.2), causing them to have to use an older snapshot or block
until an acceptable snapshot becomes available; or we require them to
be downgraded to REPEATABLE READ either implicitly or explicitly.
Now, neither of these is as alarming as they might sound, given that
replication lag is a fact of life for hot standby systems and
REPEATABLE READ is exactly the same as the current (9.0) SERIALIZABLE
behavior. But it's definitely something that should be addressed in
documentation.
Dan
--
Dan R. K. Ports MIT CSAIL http://drkp.net/
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-01-20 02:06:53 | Re: pg_basebackup for streaming base backups |
Previous Message | Nathan Boley | 2011-01-20 02:06:10 | Re: estimating # of distinct values |