Robert Haas robertmh...@gmail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
* throw a WARNING if serializable is stated in other cases, and
downgrade the request to repeatable read
I think this would be reasonable, but it's still my second choice.
The advantage of throwing an ERROR
On Mon, Apr 30, 2012 at 10:26 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
* throw a WARNING if serializable is stated in other cases, and
downgrade the request to repeatable read
I think this would
On Sat, Apr 28, 2012 at 5:56 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
But if you set it in the postgresql.conf file, it's not pretty:
kevin@kevin-desktop:~$ psql -p 5433 test
psql: FATAL: can not create a serializable snapshot during recovery
Ideas?
The patch as submitted
Simon Riggs wrote:
Kevin Grittner wrote:
But if you set it in the postgresql.conf file, it's not pretty:
kevin@kevin-desktop:~$ psql -p 5433 test
psql: FATAL: can not create a serializable snapshot during
recovery
Ideas?
The patch as submitted doesn't do anything useful for the case
On Sun, Apr 29, 2012 at 1:40 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
IMHO the desired behaviour would be
* prevent default_transaction_isolation = serializable as a default
setting when we enter Hot Standby by throwing a FATAL error from
the startup process. I can help
Simon Riggs wrote:
The only way default_transaction_isolation = serializable would be
acceptable when hot_standby = on is if we silently downgrade the
isolation level to read committed. That way everything just works,
albeit not quite as requested. So I think that's the best way
forwards.
On Sun, Apr 29, 2012 at 5:54 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Simon Riggs wrote:
The only way default_transaction_isolation = serializable would be
acceptable when hot_standby = on is if we silently downgrade the
isolation level to read committed. That way everything
Simon Riggs wrote:
On Sun, Apr 29, 2012 at 5:54 PM, Kevin Grittner
wrote:
Simon Riggs wrote:
The only way default_transaction_isolation = serializable would
be acceptable when hot_standby = on is if we silently downgrade
the isolation level to read committed. That way everything just
On Sun, Apr 29, 2012 at 8:20 AM, Simon Riggs si...@2ndquadrant.com wrote:
* prevent default_transaction_isolation = serializable as a default
setting when we enter Hot Standby by throwing a FATAL error from the
startup process. I can help implement that if we agree.
I am strongly disinclined
When I do this:
rhaas=# set default_transaction_isolation = 'serializable';
SET
rhaas=# begin;
BEGIN
rhaas=# select 1;
Then I get this:
TRAP: FailedAssertion(!(!RecoveryInProgress()), File: predicate.c,
Line: 1637)
LOG: server process (PID 290) was terminated by signal 6: Abort trap
The root
Robert Haas robertmh...@gmail.com wrote:
When I do this:
rhaas=# set default_transaction_isolation = 'serializable';
SET
rhaas=# begin;
BEGIN
rhaas=# select 1;
Then I get this:
TRAP: FailedAssertion(!(!RecoveryInProgress()), File:
predicate.c, Line: 1637)
LOG: server process
On Fri, Apr 27, 2012 at 10:21 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
My first thought was that if we can detect that we are in HS, we
should probably throw an ERROR on an attempt to set
default_transaction_isolation = 'serializable'.
I think that would result in the server
Robert Haas robertmh...@gmail.com writes:
Or, maybe there's a way to throw an error when serializable mode is
used rather than when it's requested.
Couldn't we check and throw an error at the place in transaction startup
where default_transaction_isolation is copied to the active variable?
On Fri, Apr 27, 2012 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Or, maybe there's a way to throw an error when serializable mode is
used rather than when it's requested.
Couldn't we check and throw an error at the place in transaction startup
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Or, maybe there's a way to throw an error when serializable mode
is used rather than when it's requested.
Couldn't we check and throw an error at the place in transaction
startup where default_transaction_isolation
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Couldn't we check and throw an error at the place in transaction
startup where default_transaction_isolation is copied to the
active variable?
Wouldn't that leave users stuck if the postgresql.conf set the
Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, it would definitely be nicer if BEGIN; SET TRANSACTION LEVEL
would work too. Maybe the place to put the check is where we
establish the transaction snapshot.
That makes sense, and doesn't seem like it would be hard, from what
I recall of that code.
Kevin Grittner wrote:
Tom Lane wrote:
Yeah, it would definitely be nicer if BEGIN; SET TRANSACTION LEVEL
would work too. Maybe the place to put the check is where we
establish the transaction snapshot.
That makes sense,
I'll take a shot at it sometime today,
Attached. With a
18 matches
Mail list logo
