On Mon, Apr 30, 2012 at 10:26 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Simon Riggs 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 ad
Robert Haas wrote:
> Simon Riggs 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 is that someone will presumably
> b
On Sun, Apr 29, 2012 at 8:20 AM, Simon Riggs 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 to go that route, be
> 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 ever
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 works,
>> albeit n
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
> forwar
On Sun, Apr 29, 2012 at 1:40 PM, Kevin Grittner
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 implement that if we agree
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 us
On Sat, Apr 28, 2012 at 5:56 AM, 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 usefu
> "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
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, and doesn't seem like it would be hard, from what
I recall of that code. I know I've fal
"Kevin Grittner" writes:
> Tom Lane 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
> default to serializable? Nobody
Tom Lane wrote:
> Robert Haas 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 varia
On Fri, Apr 27, 2012 at 11:02 AM, Tom Lane wrote:
> Robert Haas 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_isolatio
Robert Haas 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 10:21 AM, Kevin Grittner
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 failing to start. We could
th
Robert Haas 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 (PID 290
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 ro
18 matches
Mail list logo
