"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
> 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 sen
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 DEFERRABL
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 fl
"Kevin Grittner" 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:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=b
Anssi Kääriäinen 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 in the beginning is
Tom Lane wrote:
> Simon Riggs 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 transa
On Fri, Jan 21, 2011 at 10:32 AM, Tom Lane wrote:
> Simon Riggs 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 assi
Simon Riggs 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 have already r
2011/1/21 Robert Haas :
> On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
> wrote:
>
>> 2011/1/21 Anssi Kääriäinen :
>>
>>> 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, f
Robert Haas 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 place."
>
> B
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 regards,
"Kevin Grittner" 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 spent a
little time lo
On Fri, Jan 21, 2011 at 8:05 AM, Nicolas Barbier
wrote:
> 2011/1/21 Anssi Kääriäinen :
>
>> 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 mat
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"
2011/1/21 Anssi Kääriäinen :
> 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, because it can't see the
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 mat
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 SER
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: BE
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 assigne
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 sn
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 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
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 norm
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 se
On Thu, Jan 20, 2011 at 8:54 PM, 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
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.
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 st
> 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?
>
>
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
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
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 haven't explain
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 word
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 (vali
Simon Riggs 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 haven't exp
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
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 compa
Heikki Linnakangas 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
>> SERIALIZABLE, warn and provide
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
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, o
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 dis
* 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?
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 R&D item for over a full year without
>> discussion. :-( If we provide the snapshots (which
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 R&D item for over a full year without discussion.
> :-( If we provide the snapsh
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 rep
On Wed, Jan 19, 2011 at 8:34 PM, 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 R&D item for over a full year without discussion.
> :-( If we provide the snapshots
Simon Riggs 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" quickly now, tha
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,
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 che
49 matches
Mail list logo
