Dan Ports wrote:
> On Tue, Dec 07, 2010 at 10:14:24AM -0600, Kevin Grittner wrote:
> The only thing I'm worried about here is how much risk of
> starvation remains. You'd need to wait until there are no running
> r/w transactions accessing overlapping data sets; for some
> applications that migh
On Tue, Dec 07, 2010 at 10:14:24AM -0600, Kevin Grittner wrote:
> > Essentially, instead of adding dependencies as you go along and
> > abort once you hit a conflict, SERIALIZABLE READ ONLY DEFERRED
> > transactions would assume the worst case from the start and thus
> > be able to bypass the more
"Kevin Grittner" wrote:
> Done. Version 3 attached.
My final tweaks didn't make it into that diff. Attached is 3a as a
patch over the version 3 patch.
-Kevin
*** a/src/backend/commands/variable.c
--- b/src/backend/commands/variable.c
***
*** 564,570 assign_transaction_rea
Tom Lane wrote:
> GUC_complaint_elevel() can return DEBUGn, and in fact will do so in
> the PGC_S_OVERRIDE case. I'm thinking that the code ought to look
> more like
>
> /* source == PGC_S_OVERRIDE means do it anyway, eg at xact abort
*/
> if (source != PGC_S_OVERRIDE)
> {
>
"Kevin Grittner" writes:
> except that I'm not sure whether I addressed the assign_XactIsoLevel
> issue you mentioned, since you mentioned a debug message and I only
> see things that look like errors to me. If I did miss something,
> I'll be happy to take another look if you can point me to the
Tom Lane wrote:
> What I suggested was to not allow read-only -> read-write state
> transitions except (1) before first snapshot in the main xact
> and (2) at subxact exit (the OVERRIDE case). That seems to
> accomplish the goal. Now it will also allow dropping down to
> read-only mid-subtrans
"Kevin Grittner" writes:
> Florian Pflug wrote:
>> Say you've written a trigger which enforces some complex
>> constraint, but is correct only for SERIALIZABLE transactions. By
>> simply sticking a "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE"
>> at the top of the trigger you'd both document tha
Florian Pflug wrote:
> Hm, I think being able to assert that the isolation level really
> is SERIALIZABLE by simply doing "SET TRANSACTION ISOLATION LEVEL
> SERIALIZABLE" would be a great feature for SSI.
>
> Say you've written a trigger which enforces some complex
> constraint, but is correct
"Kevin Grittner" writes:
> Tom Lane wrote:
>> So the implementation I had in mind would allow SET TRANSACTION
>> operations to occur later in a subxact, as long as they were
>> redundant and weren't actually trying to change the active value.
> It's easy to see how I can allow changes in the su
On Dec8, 2010, at 20:39 , Kevin Grittner wrote:
> The standard is tricky to read, but my reading of it is that only
> "LOCAL" changes are allowed after the transaction is underway (which
> I *think* effectively means a subtransaction), and those can't make
> the setting less strict -- you're allowe
Tom Lane wrote:
> If the standard says that you're allowed to apply a redundant
> setting, I think we'd better accept that.
OK
> So the implementation I had in mind would allow SET TRANSACTION
> operations to occur later in a subxact, as long as they were
> redundant and weren't actually try
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Also, that code is set so that it will throw an error even if
>> you're assigning the currently active setting, which maybe is
>> overly strict? Not sure.
> The standard is tricky to read, but my reading of it is that only
> "LOCAL" changes are all
Tom Lane wrote:
> "Kevin Grittner" writes:
> One thing to watch for is allowing subxact exit to restore the
> previous read-write state.
OK.
> BTW it looks like assign_XactIsoLevel emits a rather useless debug
> message in that case, so that code could stand some cleanup too.
I'll take a
"Kevin Grittner" writes:
> I noticed that the standard seems (if I'm reading it correctly) to
> allow subtransactions to switch to more restrictive settings for
> both transaction isolation and read only status than the enclosing
> transaction, but not looser.
Yeah. My recollection is that we've
Tom Lane < t...@sss.pgh.pa.us > wrote:
> Hmm. This patch disallows the case of creating a read-only
> subtransaction of a read-write parent. That's a step backwards.
> I'm not sure how we could enforce that the property not change
> after the first query of a subxact, but maybe we don't care th
"Kevin Grittner" writes:
> Attached.
> Accomplished more through mimicry (based on setting transaction
> isolation level) than profound understanding of the code involved;
> but it passes all regression tests on both `make check` and `make
> installcheck-world`. This includes a new regression t
I wrote:
> Tom Lane wrote:
>
>> I agree that letting it be changed back to read/write after that
>> is surprising and unnecessary. Perhaps locking down the setting
>> at the time of first grabbing a snapshot would be appropriate.
>> IIRC that's how it works for transaction isolation level, an
Tom Lane wrote:
> I agree that letting it be changed back to read/write after that
> is surprising and unnecessary. Perhaps locking down the setting
> at the time of first grabbing a snapshot would be appropriate.
> IIRC that's how it works for transaction isolation level, and this
> seems lik
"Kevin Grittner" writes:
> Oh, I just went through the code on setting READ ONLY and discovered
> that contrary to the standard *and* the PostgreSQL documentation,
> you can change the status of a transaction between READ ONLY and
> READ WRITE at will. Yeah, that's a problem for my intended use.
Tom Lane wrote:
> I assume this would have to be a "hard" definition of READ ONLY,
> not the rather squishy definition we use now?
Oh, I just went through the code on setting READ ONLY and discovered
that contrary to the standard *and* the PostgreSQL documentation,
you can change the status of a
Florian Pflug wrote:
> reason for a SERIALIZABLE READ ONLY transaction's snapshot to be
> inconsistent that it sees some transaction A as committed and B as
> uncommitted when on the other hand B must happen before A in any
> serial schedule.
Precisely right, and very well stated.
> I'm thus
On Dec6, 2010, at 22:53 , Kevin Grittner wrote:
>> The alternative seems to be to drop the guarantee that a
>> SERIALIZABLE READ ONLY DEFERRABLE won't be starved forever by a
>> stream of overlapping non-READ ONLY transactions. Then a flag in
>> the proc array that marks non-READ ONLY transactions
Heikki Linnakangas wrote:
> On 06.12.2010 22:53, Kevin Grittner wrote:
>> What would be the correct way for a process to put itself to
>> sleep, and for another process to later wake it up?
>
> See ProcWaitSignal/ProcSendSignal. Or the new 'latch' code.
Is there a reason to prefer one over the
On 06.12.2010 22:53, Kevin Grittner wrote:
What would be the correct way for a process to put itself to sleep,
and for another process to later wake it up?
See ProcWaitSignal/ProcSendSignal. Or the new 'latch' code.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent
Florian Pflug wrote:
> On Dec5, 2010, at 16:11 , Kevin Grittner wrote:
>> The simple way to implement SERIALIZABLE READ ONLY DEFERRABLE
>> under SSI would be to have each non-read-only serializable
>> transaction acquire a heavyweight lock which can coexist with
>> other locks at the same level (S
On Dec5, 2010, at 16:11 , Kevin Grittner wrote:
> The simple way to implement SERIALIZABLE READ ONLY DEFERRABLE under
> SSI would be to have each non-read-only serializable transaction
> acquire a heavyweight lock which can coexist with other locks at the
> same level (SHARE looks good) on some com
"Kevin Grittner" writes:
> I reviewed the documentation and played around with this a bit and
> can't find any areas where the current PostgreSQL implementation of
> READ ONLY is incompatible with what is needed for the SSI
> optimizations where it is used. There are a large number of tests
> whi
I wrote:
> Tom Lane wrote:
>> I assume this would have to be a "hard" definition of READ ONLY,
>> not the rather squishy definition we use now?
> I'm excluding temporary tables from SSI on the grounds that they
> are only read and written by a single transaction and therefore
> can't be a sour
Tom Lane wrote:
> "Kevin Grittner" writes:
>> I'm reviving the discussion on the subject topic because I just
>> had an epiphany which makes it seem simple to implement. The
>> concept of this is that if you start a SERIALIZABLE READ ONLY
>> transaction in an SSI environment when certain conditio
"Kevin Grittner" writes:
> I'm reviving the discussion on the subject topic because I just had
> an epiphany which makes it seem simple to implement. The concept of
> this is that if you start a SERIALIZABLE READ ONLY transaction in an
> SSI environment when certain conditions are true, it doesn'
I'm reviving the discussion on the subject topic because I just had
an epiphany which makes it seem simple to implement. The concept of
this is that if you start a SERIALIZABLE READ ONLY transaction in an
SSI environment when certain conditions are true, it doesn't need to
acquire predicate locks
31 matches
Mail list logo
