"Kevin Grittner" writes:
> Tom Lane wrote:
>> Lastly, I simplified the added code in InitPostgres down to just a
>> bare assignment to XactIsoLevel. It doesn't seem worthwhile to
>> add all the cycles involved in SetConfigOption(), when we have no
>> desire to change the GUC permanently. (I thi
> Tom Lane wrote:
> "Kevin Grittner" writes:
>> I'll run through my tests again tonight, against your patch, not
>> that I expect any problems with it. Unfortunately I can't test
>> Windows, as I don't have a build environment for that.
>
> FWIW, you can approximate Windows close enough for th
"Kevin Grittner" writes:
> I'll run through my tests again tonight, against your patch, not
> that I expect any problems with it. Unfortunately I can't test
> Windows, as I don't have a build environment for that.
FWIW, you can approximate Windows close enough for this type of problem
by buildin
Tom Lane wrote:
> I tweaked Kevin's error message to keep the same capitalization as
> the existing text for the message in check_XactIsoLevel --- if we
> change that it will cause work for the translators, and I don't
> think it's enough of an improvement to justify that.
That's one of the re
I wrote:
> I poked around this area a bit. I notice that
> check_transaction_read_only has got the same fundamental error: it
> thinks it can safely consult RecoveryInProgress(), which in general
> it cannot.
After rereading the whole thread I saw that Heikki had already pointed
this out, and com
"Kevin Grittner" writes:
> How about we fix the serializable versus HS & Windows bugs in one
> patch, and then look at the other as a separate patch? If that's OK,
> I think this is ready, unless my message text can be improved. (And
> I will have a shot at my first back-patching)
I poked aro
> "Kevin Grittner" wrote:
> Heikki Linnakangas wrote:
>> On 14.08.2012 14:25, Kevin Grittner wrote:
Attached is version 3.
>>> Oh, further testing this morning shows that while *queries* on
>>> the HS seem OK, streaming replication is now broken. I probably
>>> need to override transaction isolat
Heikki Linnakangas wrote:
> On 14.08.2012 14:25, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> On 14.08.2012 08:23, Kevin Grittner wrote:
>> Oh, further testing this morning shows that while *queries* on
>> the HS seem OK, streaming replication is now broken. I probably
>> need to ove
On 14.08.2012 14:25, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 14.08.2012 08:23, Kevin Grittner wrote:
OK, attached is a first cut to confirm that the approach looks
sane to everyone; I *think* it is along the lines that we reached
consensus. After moving the check to the point wher
Heikki Linnakangas wrote:
> we have to somehow fix the crash and the assertion failure on 9.1.
Here's a revision with some changes based on your feedback. I have
to go to my "day job" now, and I was unable to find the right place
to fix the streaming replication problem. I fear I won't be ab
Heikki Linnakangas wrote:
> On 14.08.2012 08:23, Kevin Grittner wrote:
>> OK, attached is a first cut to confirm that the approach looks
>> sane to everyone; I *think* it is along the lines that we reached
>> consensus. After moving the check to the point where we get a
>> serializable snapshot,
On 14.08.2012 08:23, Kevin Grittner wrote:
OK, attached is a first cut to confirm that the approach looks sane
to everyone; I *think* it is along the lines that we reached
consensus. After moving the check to the point where we get a
serializable snapshot, it was still behaving badly. It took a
"Kevin Grittner" wrote:
> OK, attached
[sigh]
This time for sure!
-Kevin
hotstandby-serializable.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas wrote:
> While playing around, I bumped into another related bug, and after
> googling around I found out that it was already reported by Robert
> Haas earlier, but still not fixed:
> Kevin, the last message on that thread says you'll write a patch
> for that. Ping?
OK, at
Heikki Linnakangas wrote:
> While playing around, I bumped into another related bug, and
> after googling around I found out that it was already reported by
> Robert Haas earlier, but still not fixed:
>
http://archives.postgresql.org/message-id/CA%2BTgmoa0UM2W1YkjjneEgJctzxopC3G53ocYPaCyoEOWT3a
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila
Sent: Monday, August 13, 2012 12:47 PM
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki Linnakangas
Sent: Monday, August 13, 2012 12:
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki Linnakangas
Sent: Monday, August 13, 2012 12:14 PM
On 12.08.2012 17:39, Tom Lane wrote:
> Heikki Linnakangas writes:
>>> The problem is that when a postmaster subprocess is launched, it calls
>
Heikki Linnakangas writes:
> On 12.08.2012 17:39, Tom Lane wrote:
>> A larger point is that I think it's broken for any GUC assignment
>> function to be calling something as transient as RecoveryInProgress to
>> start with.
> Hmm, it seems like the logical place to complain if you do a manual "SE
On 12.08.2012 17:39, Tom Lane wrote:
Heikki Linnakangas writes:
The problem is that when a postmaster subprocess is launched, it calls
read_nondefault_variables() very early, before shmem initialization, to
read the non-default config options from the file that postmaster wrote.
When check_Xact
Heikki Linnakangas writes:
> The problem is that when a postmaster subprocess is launched, it calls
> read_nondefault_variables() very early, before shmem initialization, to
> read the non-default config options from the file that postmaster wrote.
> When check_XactIsoLevel() calls RecoveryInPr
A customer reported that when you set
default_isolation_level='serializable' in postgresql.conf on Windows,
and try to start up the database, it crashes immediately. And sure
enough, it does, on REL9_1_STABLE as well as on master.
Stack trace:
postgres!RecoveryInProgress+0x3a
[c:\postgresql\
21 matches
Mail list logo
