On Fri, 2008-12-19 at 20:54 +0000, Gregory Stark wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>
> > PostgreSQL is much less prone to serialization failures, but it is
> > certainly understandable if hot standby replication introduces new
> > cases of it.
>
> In this case it will be possible to get this error even if you're just running
> a single SELECT query -- and that's the *only* query in the database at all.
>
> A vacuum being replayed -- even in a different database -- could trigger the
> error. Or with the btree split issue, a data load -- again even in a different
> database -- would be quite likely cause your SELECT to be killed.
Quite likely? "You're all doomed I say!", his eyes rolling wildly. :-)
The standby is an extension of the primary and is quite literally
running the same transactions. This "only query" idea isn't the right
way to think about it. It's fairly easily possible to predict it will
happen and it will happen only in same database as transactions on the
primary. And as we just said, you can control whether and/or after how
long this will happen in some detail.
Industry context: In the worst case this is as bad as Oracle 11g. In
many/most cases it is much better.
Perhaps we should listen to the people that have said they don't want
queries cancelled, even if the alternative is inconsistent answers. That
is easily possible yet is not currently an option. Plus we have the
option I referred to up thread, which is to defer query cancel until the
query reads a modified data block. I'm OK with implementing either of
those, as non-default options. Do we need those options or are we ok?
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support