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 might
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
Tom Lane t...@sss.pgh.pa.us 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
I wrote:
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 that
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us 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
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 allowed to
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Florian Pflug f...@phlo.org 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Florian Pflug f...@phlo.org 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us 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 kevin.gritt...@wicourts.gov 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
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 should
Florian Pflug f...@phlo.org 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.
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 source of
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 common
Florian Pflug f...@phlo.org 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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 conditions are
30 matches
Mail list logo
