Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 come
Tom Lane t...@sss.pgh.pa.us 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.
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 this type of
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
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, it was
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 able
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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.
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 isolation on the
On 12.08.2012 17:39, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 Linnakangasheikki.linnakan...@enterprisedb.com writes:
The problem is that when a postmaster
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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:
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,
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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
21 matches
Mail list logo
