On Sun, 2009-12-20 at 19:11 -0500, Robert Haas wrote:
On Sun, Dec 20, 2009 at 3:42 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
I put them on the TODO list at
https://wiki.postgresql.org/wiki/Hot_Standby_TODO, under the must-fix
On 22.12.09 9:34 , Simon Riggs wrote:
If you are saying being able to start Hot Standby from a shutdown
checkpoint is an important feature for you, then say so, and why.
I think it's not so much an important feature but more the removal of a
footgun.
Image a reporting database where all
On Tue, Dec 22, 2009 at 8:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you are saying being able to start Hot Standby from a shutdown
checkpoint is an important feature for you, then say so, and why.
Can you explain the consequences of missing this? It sounds to me like
if I lose my
On Tue, 2009-12-22 at 12:32 +0100, Florian Pflug wrote:
On 22.12.09 9:34 , Simon Riggs wrote:
If you are saying being able to start Hot Standby from a shutdown
checkpoint is an important feature for you, then say so, and why.
I think it's not so much an important feature but more the
On Tue, 2009-12-22 at 11:41 +, Greg Stark wrote:
On Tue, Dec 22, 2009 at 8:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you are saying being able to start Hot Standby from a shutdown
checkpoint is an important feature for you, then say so, and why.
Can you explain the
Simon Riggs wrote:
If someone does
add this, it will require careful thought about how to avoid introducing
further subtle ways to break HS, all of which will need testing and
re-testing to avoid regression.
Well, I *did* add that, but you removed it...
--
Heikki Linnakangas
On Tue, 2009-12-22 at 16:09 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
If someone does
add this, it will require careful thought about how to avoid introducing
further subtle ways to break HS, all of which will need testing and
re-testing to avoid regression.
Well, I *did* add
On 22.12.09 13:21 , Simon Riggs wrote:
On Tue, 2009-12-22 at 12:32 +0100, Florian Pflug wrote:
Image a reporting database where all transactions but a few daily
bulk imports are read-only. To spread the load, you do your bulk
loads on the master, but run the reporting queries against a
On Tue, Dec 22, 2009 at 3:32 PM, Florian Pflug fgp.phlo@gmail.com wrote:
Well, you either wait for master to come up again and restart, or you
flip into normal mode and keep running queries from there. You aren't
prevented from using the server, except by your own refusal to
failover.
On Tue, 2009-12-22 at 16:32 +0100, Florian Pflug wrote:
But you are of course free to work on whatever you feel like, and
probably need to satisfy your client's needs first.
Alluding to me as whimsical or mercenary isn't likely to change my mind.
IMHO this isn't one of the more important
On Tue, 2009-12-22 at 15:38 +, Greg Stark wrote:
On Tue, Dec 22, 2009 at 3:32 PM, Florian Pflug fgp.phlo@gmail.com wrote:
Well, you either wait for master to come up again and restart, or you
flip into normal mode and keep running queries from there. You aren't
prevented from using
Simon Riggs wrote:
By add I meant to write the feature, test and then support it
afterwards, not to re-discuss editing the Wiki.
That's exactly what I meant too. I *did* write the feature, but you
removed it before committing.
I can extract the removed parts from the git repository and send
On Tue, 2009-12-22 at 18:17 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
By add I meant to write the feature, test and then support it
afterwards, not to re-discuss editing the Wiki.
That's exactly what I meant too. I *did* write the feature, but you
removed it before committing.
Simon Riggs wrote:
On Tue, 2009-12-22 at 18:17 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
By add I meant to write the feature, test and then support it
afterwards, not to re-discuss editing the Wiki.
That's exactly what I meant too. I *did* write the feature, but you
removed it
On Tue, 2009-12-22 at 18:40 +0200, Heikki Linnakangas wrote:
The issue I mentioned had nothing to do with starting from a shutdown
checkpoint - it's still a problem if you keep the standby running
through the restart cycle in the master) - but maybe you thought it was?
Or was there something
Simon Riggs wrote:
You've been perfectly happy for *years* with the situation that recovery
would fail if max_prepared_transactions was not correctly. You're not
going to tell me you never noticed? Why is avoidance of obvious
misconfiguration of HS such a heavy priority when nothing else ever
Simon Riggs wrote:
On Mon, 2009-12-21 at 18:42 +0900, Hiroyuki Yamada wrote:
Do you think this problem is must-fix for the final release ?
We should be clear that this is a behaviour I told you about, not a
shock discovery by yourself. There is no permanent freeze, just a wait,
from
On Tue, 2009-12-22 at 19:30 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
You've been perfectly happy for *years* with the situation that recovery
would fail if max_prepared_transactions was not correctly. You're not
going to tell me you never noticed? Why is avoidance of obvious
On 22.12.09 16:45 , Simon Riggs wrote:
On Tue, 2009-12-22 at 16:32 +0100, Florian Pflug wrote:
But you are of course free to work on whatever you feel like, and
probably need to satisfy your client's needs first.
Alluding to me as whimsical or mercenary isn't likely to change my
mind.
On Tue, 2009-12-22 at 19:53 +0100, Florian Pflug wrote:
None of this was meant as an insult of any kind.
Then I apologise completely.
I've clearly been working too hard and will retire for some rest (even
though that is not listed as a task on the Wiki).
--
Simon Riggs
On Dec 22, 2009, at 11:02 AM, Simon Riggs wrote:
I've clearly been working too hard and will retire for some rest (even
though that is not listed as a task on the Wiki).
Someone add it!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Tue, Dec 22, 2009 at 11:04:29AM -0800, David Wheeler wrote:
On Dec 22, 2009, at 11:02 AM, Simon Riggs wrote:
I've clearly been working too hard and will retire for some rest (even
though that is not listed as a task on the Wiki).
Someone add it!
Done! :)
Cheers,
David.
--
David
Simon Riggs wrote:
On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
I put them on the TODO list at
https://wiki.postgresql.org/wiki/Hot_Standby_TODO, under the must-fix
category.
I notice you also re-arranged other items on there, specifically the
notion that starting from a
The problem you mention here has been documented and very accessible for
months and not a single person mentioned it up to now. What's more, the
equivalent problem happens in the latest production version of Postgres
- users can delay VACUUM endlessly in just the same way, yet I've not
seen this
On Mon, 2009-12-21 at 18:42 +0900, Hiroyuki Yamada wrote:
Do you think this problem is must-fix for the final release ?
We should be clear that this is a behaviour I told you about, not a
shock discovery by yourself. There is no permanent freeze, just a wait,
from which the Startup process
On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
Well, that was the criteria I used to decide whether to commit or not.
Not everyone agreed to begin with, and the reason I used that criteria
was a selfish one: I didn't want to be forced to fix loose ends after
the commitfest
On Sat, 2009-12-19 at 14:20 +0200, Peter Eisentraut wrote:
Do people want more time to play with hot standby? Otherwise alpha3
should go out on Monday or Tuesday.
No thanks. There were no known bugs in the code I committed, excepting
the need to address VACUUM FULL. That will take longer than
On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
I put them on the TODO list at
https://wiki.postgresql.org/wiki/Hot_Standby_TODO, under the must-fix
category.
I notice you also re-arranged other items on there, specifically the
notion that starting from a shutdown checkpoint is
On Sat, 2009-12-19 at 23:22 +0900, Hiroyuki Yamada wrote:
Do people want more time to play with hot standby? Otherwise alpha3
should go out on Monday or Tuesday.
Well, I want to know whether the problem I refered to
in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
is
On Sun, Dec 20, 2009 at 3:42 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2009-12-19 at 20:59 +0200, Heikki Linnakangas wrote:
I put them on the TODO list at
https://wiki.postgresql.org/wiki/Hot_Standby_TODO, under the must-fix
category.
I notice you also re-arranged other items on
Do people want more time to play with hot standby? Otherwise alpha3
should go out on Monday or Tuesday.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Do people want more time to play with hot standby? Otherwise alpha3
should go out on Monday or Tuesday.
Well, I want to know whether the problem I refered to
in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
is must-fix or not.
This problem is a corollary of the deadlock
On Sat, Dec 19, 2009 at 7:20 AM, Peter Eisentraut pete...@gmx.net wrote:
Do people want more time to play with hot standby? Otherwise alpha3
should go out on Monday or Tuesday.
I think we should try to wrap it promptly. It's true that Hot Standby
almost certainly has bugs and/or annoying
Hiroyuki Yamada yam...@kokolink.net writes:
Well, I want to know whether the problem I refered to
in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
is must-fix or not.
This problem is a corollary of the deadlock problem. This is less catstrophic
but more likely to happen.
Tom Lane wrote:
Hiroyuki Yamada yam...@kokolink.net writes:
Well, I want to know whether the problem I refered to
in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
is must-fix or not.
This problem is a corollary of the deadlock problem. This is less catstrophic
but more
On Sat, 2009-12-19 at 18:12 +0100, Stefan Kaltenbrunner wrote:
Seems like something we should fix ASAP, but I do not see why it
need
hold up an alpha release. Alpha releases are expected to have bugs,
and this one doesn't look like it would stop people from finding
other bugs.
yeah
Hiroyuki Yamada yam...@kokolink.net writes:
Well, I want to know whether the problem I refered to
in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
is must-fix or not.
This problem is a corollary of the deadlock problem. This is less catstrophic
but more likely to
Hiroyuki Yamada wrote:
Hiroyuki Yamada yam...@kokolink.net writes:
Well, I want to know whether the problem I refered to
in http://archives.postgresql.org/pgsql-hackers/2009-12/msg01641.php
is must-fix or not.
This problem is a corollary of the deadlock problem. This is less
catstrophic
Well, that was the criteria I used to decide whether to commit or not.
Not everyone agreed to begin with, and the reason I used that criteria
was a selfish one: I didn't want to be forced to fix loose ends after
the commitfest myself. The big reason for that was that I didn't know
how much time I
39 matches
Mail list logo
