On Fri, 2011-01-21 at 02:32 -0500, Dan Ports wrote:
On Fri, Jan 21, 2011 at 08:44:59AM +0200, Heikki Linnakangas wrote:
We have enough information in the standby to reconstruct all writes done
in the master. I gather that's not enough, in order to roll back
read-only transaction T3 on the
On 21.01.2011 11:10, Simon Riggs wrote:
So any xid that commits in a different sequence to the order in which
the xid was assigned creates a potential for unserialization? Or?
It's not the order in which the xid was assigned that matters, but the
order the transactions started and got their
On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
On 21.01.2011 11:10, Simon Riggs wrote:
So any xid that commits in a different sequence to the order in which
the xid was assigned creates a potential for unserialization? Or?
It's not the order in which the xid was assigned that
On 01/21/2011 03:25 AM, Florian Pflug wrote:
The COMMIT order in the actual, concurrent, schedule doesn't not necessarily
represent the order of the transaction in an equivalent serial schedule. Here's
an example
T1: BEGIN SERIALIZABLE; -- (Assume snapshot is set here)
T1: UPDATE D1 ... ;
T2:
On Jan21, 2011, at 12:55 , Anssi Kääriäinen wrote:
On 01/21/2011 03:25 AM, Florian Pflug wrote:
The COMMIT order in the actual, concurrent, schedule doesn't not necessarily
represent the order of the transaction in an equivalent serial schedule.
Here's
an example
T1: BEGIN SERIALIZABLE;
On Jan21, 2011, at 10:19 , Heikki Linnakangas wrote:
On 21.01.2011 11:10, Simon Riggs wrote:
So any xid that commits in a different sequence to the order in which
the xid was assigned creates a potential for unserialization? Or?
It's not the order in which the xid was assigned that matters,
2011/1/21 Anssi Kääriäinen anssi.kaariai...@thl.fi:
Sorry for bothering all of you, but I just don't get this. What if T2 rolls
back instead of committing? Then the snapshot of T3 would have been valid,
right? Now, for the snapshot of T3 it doesn't matter if T2 commits or if it
doesn't,
Heikki Linnakangas wrote:
It's not the order in which the xid was assigned that matters, but
the order the transactions started and got their snapshots. The
xids might be assigned a lot later, after the transactions have
already read data.
From the Apparent Serial Order of Execution
On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2011/1/21 Anssi Kääriäinen anssi.kaariai...@thl.fi:
Sorry for bothering all of you, but I just don't get this. What if T2 rolls
back instead of committing? Then the snapshot of T3 would have been valid,
right?
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
(1) A read write transaction might need to be canceled to
prevent the view of the data a committed read only transaction has
already seen from becoming inconsistent. (Dan's example)
And this one seems entirely a theoretical possibility. I
On 01/21/2011 02:21 PM, Florian Pflug wrote:
Still, the would dump reflects a database state that *logically* never existed
(i.e. not in any serial schedule). If you dump for disaster recovery, you might
not care. If you dump to copy the data onto some reporting server you might.
best
Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
This has been discussed before; in [1] I summarized:
IOW, one could say that the backup is consistent only if it were
never compared against the system as it continued running after
the dump took
2011/1/21 Robert Haas robertmh...@gmail.com:
On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
2011/1/21 Anssi Kääriäinen anssi.kaariai...@thl.fi:
Sorry for bothering all of you, but I just don't get this. What if T2 rolls
back instead of committing? Then
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
It's not the order in which the xid was assigned that matters, but the
order the transactions started and got their snapshots. The xids might
be assigned a lot later, after the transactions
On Fri, Jan 21, 2011 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
It's not the order in which the xid was assigned that matters, but the
order the transactions started and got their
Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-21 at 11:19 +0200, Heikki Linnakangas wrote:
It's not the order in which the xid was assigned that matters,
but the order the transactions started and got their snapshots.
The xids might be assigned a
Anssi Kääriäinenanssi.kaariai...@thl.fi wrote:
I am beginning to understand the problem. If you don't mind, here
is a complete example if somebody else is having troubles
understanding this.
Let's say we have tables D1 and D2. Both contain a single column,
id, and a single row. The data
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
When I test your example, though, I'm getting the serialization
failure on T3 rather than T2, so I'd call that a bug. Will
investigate. Thanks again for your tests!
Fixed with this:
I wrote:
We're not talking about passing the backwards. I'm suggesting
that we probably don't even need to pass them forward, but that
suggestion has been pretty handwavy so far. I guess I should fill
it out, because everyone's been ignoring it so far.
It's been too hectic today to flesh
On Fri, 2011-01-21 at 18:52 -0600, Kevin Grittner wrote:
My assumption is that when we have a safe snapshot (which should be
pretty close to all the time), we immediately provide it to any
serializable transaction requesting a snapshot, except it seems to
make sense to use the new DEFERRABLE
Jeff Davis wrote:
On Fri, 2011-01-21 at 18:52 -0600, Kevin Grittner wrote:
My assumption is that when we have a safe snapshot (which should
be pretty close to all the time), we immediately provide it to any
serializable transaction requesting a snapshot, except it seems to
make sense to use
When I test your example, though, I'm getting the serialization
failure on T3 rather than T2, so I'd call that a bug. Will
investigate. Thanks again for your tests! You seem to be able to
shake out issues better than anyone else! Once found, fixing them
is not usually very hard, it's coming up
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 20.01.2011 03:05, Kevin Grittner wrote:
If we don't do something like this, do we just provide REPEATABLE
READ on the standby as the strictest level of transaction
isolation? If so, do we generate an error on a request for
Kevin,
So, based on a more complete description of the issues, any more
opinions on whether to generate the error, as suggested by Heikki?
If it's a choice between generating an error and letting users see
inconsistent data, I'll take the former.
Does anyone think this justifies the
On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
The idea is that whenever we see a valid snapshot which would yield
a truly serializable view of the data for a READ ONLY transaction,
we add a WAL record with that snapshot information.
You haven't explained why this approach is the
Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
The idea is that whenever we see a valid snapshot which would
yield a truly serializable view of the data for a READ ONLY
transaction, we add a WAL record with that snapshot information.
You
On Jan21, 2011, at 00:11 , Simon Riggs wrote:
It's not clear to me what the reason is that this doesn't just work on
HS already. If you started there it might help.
The problem is that snapshots taken on the master sometimes represent a
state of the database which cannot occur under any
I wrote:
Why not? We already generate appropriate snapshots for this in
SSI, so is the problem in getting the appropriate information into
the WAL stream or in having a request for a snapshot within a
serializable transaction while running in hot standby the problem?
I dropped few words.
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
The idea is that whenever we see a valid snapshot which would yield
a truly serializable view of the data for a READ ONLY transaction,
we add a WAL record with that snapshot information.
You
On Fri, 2011-01-21 at 00:26 +0100, Florian Pflug wrote:
On Jan21, 2011, at 00:11 , Simon Riggs wrote:
It's not clear to me what the reason is that this doesn't just work on
HS already. If you started there it might help.
The problem is that snapshots taken on the master sometimes
Tom Lane wrote:
I'm pretty concerned about the performance implications, too. In
particular that sounds like you could get an unbounded amount of
WAL emitted from a *purely read only* transaction flow.
No. Read only transactions wouldn't create any flow at all. And I
suggested that we
What I'm still not clear on is why that HS is different. Whatever rules
apply on the master must also apply on the standby, immutably. Why is it
we need to pass explicit snapshot information from master to standby? We
don't do that, except at startup for normal HS. Why do we need that?
I
On Jan21, 2011, at 01:28 , Simon Riggs wrote:
What I'm still not clear on is why that HS is different. Whatever rules
apply on the master must also apply on the standby, immutably. Why is it
we need to pass explicit snapshot information from master to standby? We
don't do that, except at
Tom Lane wrote:
Simon Riggs writes:
On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
The idea is that whenever we see a valid snapshot which would
yield a truly serializable view of the data for a READ ONLY
transaction, we add a WAL record with that snapshot information.
You
On Thu, Jan 20, 2011 at 8:54 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
As I mentioned in another email, we might want to throttle this. My
thinking was that we could start a timer on capturing a snapshot, and
continue to gather new ones as they become available. When you hit
the
Robert Haas wrote:
Kevin Grittner wrote:
As I mentioned in another email, we might want to throttle this.
My thinking was that we could start a timer on capturing a
snapshot, and continue to gather new ones as they become
available. When you hit the timer limit (maybe 100ms?) you send
the
On 21.01.2011 03:19, Dan Ports wrote:
What I'm still not clear on is why that HS is different. Whatever rules
apply on the master must also apply on the standby, immutably. Why is it
we need to pass explicit snapshot information from master to standby? We
don't do that, except at startup for
On Fri, Jan 21, 2011 at 08:44:59AM +0200, Heikki Linnakangas wrote:
We have enough information in the standby to reconstruct all writes done
in the master. I gather that's not enough, in order to roll back
read-only transaction T3 on the standby which would see an anomaly, we'd
also need to
Here's an issue for feedback from the community -- do we want to
support truly serializable transactions on hot standby machines?
The best way Dan and I have been able to think to do this is to
build on the SERIALIZABLE READ ONLY DEFERRABLE behavior. We are
able to obtain a snapshot and then
On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
Here's an issue for feedback from the community -- do we want to
support truly serializable transactions on hot standby machines?
In this release? Maybe? In later releases? Yes.
If it blocks your excellent contribution in this release,
Simon Riggs si...@2ndquadrant.com wrote:
In this release? Maybe? In later releases? Yes.
If it blocks your excellent contribution in this release, then
from me, no. If you can achieve this in this release, yes.
However, if this is difficult or complex, then I would rather say
not yet
On Wed, Jan 19, 2011 at 8:34 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
I agree it's pretty late in the cycle, but I'm going through all the
loose ends and found this one -- which has been hanging out on the
Wiki page as an RD item for over a full year without discussion.
:-( If we
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
On Wed, 2011-01-19 at 19:34 -0600, Kevin Grittner wrote:
I agree it's pretty late in the cycle, but I'm going through all the
loose ends and found this one -- which has been hanging out on the
Wiki page as an RD item for over a full year without discussion.
:-( If we provide the snapshots
Robert Haas wrote:
Kevin Grittner wrote:
I agree it's pretty late in the cycle, but I'm going through all
the loose ends and found this one -- which has been hanging out on
the Wiki page as an RD item for over a full year without
discussion. :-( If we provide the snapshots (which we can
* Simon Riggs (si...@2ndquadrant.com) wrote:
I gave you a quick response to let you know that HS need not be a
blocker, for this release. If you are saying you have knowingly ignored
a requirement for a whole year, then I am shocked. How exactly did you
think this would ever be committed?
Simon Riggs wrote:
I gave you a quick response to let you know that HS need not be a
blocker, for this release. If you are saying you have knowingly
ignored a requirement for a whole year, then I am shocked. How
exactly did you think this would ever be committed?
I was asked not to
On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
If we don't do something like this, do we just provide REPEATABLE
READ on the standby as the strictest level of transaction isolation?
If so, do we generate an error on a request for SERIALIZABLE, warn
and provide degraded behavior, or
On 20.01.2011 03:05, Kevin Grittner wrote:
If we don't do something like this, do we just provide REPEATABLE
READ on the standby as the strictest level of transaction isolation?
If so, do we generate an error on a request for SERIALIZABLE, warn
and provide degraded behavior, or just quietly give
49 matches
Mail list logo
