Hot Standby: Relation-specific deferred conflict resolution
Conflict resolution improvements are important to include in this
release, as discussed many times. Proposal given here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php
presents a viable design to improve this.
Following patch is a complete working implementation of that design.
I'm still testing it, but its worth publishing as early as possible to
allow discussion. Not for commit, just yet, but soon.
standby.c changes are to decide whether to defer recovery based upon
relfilenode of WAL record. If resolution deferred, re-check for conflict
during LockAcquire() and fail with snapshot error, just as if resolution
had never been deferred. Also, an optimisation of conflict processing to
avoid continual re-evaluation of conflicts since some are now deferred.
API changes in heapam and nbtxlog to pass thru RelFileNode
API changes in indexcmds, no behaviour changes
procarray changes to implement LatestRemovedXid cache
backend/access/heap/heapam.c | 6 -
backend/access/nbtree/nbtxlog.c | 2
backend/commands/indexcmds.c | 4 -
backend/storage/ipc/procarray.c | 55 +++++++++++-
backend/storage/ipc/standby.c | 112 +++++++++++++++++++++++------
backend/storage/lmgr/lock.c | 124 ++++++++++++++++++++++++++++++--
include/storage/lock.h | 8 ++
include/storage/proc.h | 5 +
include/storage/standby.h | 9 ++
9 files changed, 292 insertions(+), 33 deletions(-)
--
Simon Riggs www.2ndQuadrant.com
Attachments:
relation_specific_conflict_resolution.patchtext/x-patch; charset=UTF-8; name=relation_specific_conflict_resolution.patchDownload+325-177
Simon Riggs wrote:
Conflict resolution improvements are important to include in this
release, as discussed many times. Proposal given here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php
presents a viable design to improve this.Following patch is a complete working implementation of that design.
I'm still testing it, but its worth publishing as early as possible to
allow discussion. Not for commit, just yet, but soon.
Um, you're not considering this for 9.0, are you? I think it's time to
concentrate on the must-fix issues and fix the rough edges in what we have.
For example, the "can't start hot standby mode from a shutdown
checkpoint" issue is a must-fix issue in my opinion, about 10x as
important as this. When that was last discussed, many others agreed. I
run into that all the time when testing streaming replication, and every
time I go "Huh, why isn't the standby opening up for connections?", and
then, "Ahh, it's this stupid shutdown checkpoint issue again".
And the VACUUM FULL issue is still hanging too. And maybe you could help
with some other things on the open items or commitfest list.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Fri, 2010-01-29 at 08:26 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Conflict resolution improvements are important to include in this
release, as discussed many times. Proposal given here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php
presents a viable design to improve this.Following patch is a complete working implementation of that design.
I'm still testing it, but its worth publishing as early as possible to
allow discussion. Not for commit, just yet, but soon.Um, you're not considering this for 9.0, are you? I think it's time to
concentrate on the must-fix issues and fix the rough edges in what we have.
Yes, it is important.
For example, the "can't start hot standby mode from a shutdown
checkpoint" issue is a must-fix issue in my opinion, about 10x as
important as this. When that was last discussed, many others agreed. I
run into that all the time when testing streaming replication, and every
time I go "Huh, why isn't the standby opening up for connections?", and
then, "Ahh, it's this stupid shutdown checkpoint issue again".
That was not the feedback I have received. Nobody has commented on that
to me, though many have commented on the need for the current patch. As
mentioned, I went to the trouble of running a meeting to gain additional
feedback and the result was very clear.
Of course, if we ignore any feature, then someone will say "its that
stupid issue again", but that won't imply we got our priority wrong.
And the VACUUM FULL issue is still hanging too.
Yes, that is a must fix.
--
Simon Riggs www.2ndQuadrant.com
On Fri, Jan 29, 2010 at 9:03 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
That was not the feedback I have received. Nobody has commented on that
to me, though many have commented on the need for the current patch. As
mentioned, I went to the trouble of running a meeting to gain additional
feedback and the result was very clear.
I don't have a technical opinion about this problem yet as I haven't
tested HS+SR yet but I'm not sure it's a good idea to base technical
decisions and priorities on user polls (I'm pretty sure most of them
don't use HS+SR as much as Heikki these days).
If you ask people what they want in their future cars, they won't
answer they want wheels or an engine: it's something obvious for them.
AFAICS (but I might be wrong), you asked this question to people who
are interested in HS+SR but don't have any idea of what it's like to
use HS+SR daily with or without this limitation.
There are perhaps better arguments for not doing it but this one seems
a bit weird to me.
--
Guillaume
On Fri, 2010-01-29 at 09:20 +0100, Guillaume Smet wrote:
On Fri, Jan 29, 2010 at 9:03 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
That was not the feedback I have received. Nobody has commented on that
to me, though many have commented on the need for the current patch. As
mentioned, I went to the trouble of running a meeting to gain additional
feedback and the result was very clear.I don't have a technical opinion about this problem yet as I haven't
tested HS+SR yet but I'm not sure it's a good idea to base technical
decisions and priorities on user polls (I'm pretty sure most of them
don't use HS+SR as much as Heikki these days).
If you ask people what they want in their future cars, they won't
answer they want wheels or an engine: it's something obvious for them.
AFAICS (but I might be wrong), you asked this question to people who
are interested in HS+SR but don't have any idea of what it's like to
use HS+SR daily with or without this limitation.
Well, you are correct that a larger group of users *could* have avoided
an obvious and important issue. Though if you deploy that argument it
can be applied both ways: Heikki may also be missing an obvious and
important issue. Where does that leave us?
I am not against putting both into this release. If I am forced to
choose just one, I've at least given reasons why that should be so.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs wrote:
On Fri, 2010-01-29 at 08:26 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Conflict resolution improvements are important to include in this
release, as discussed many times. Proposal given here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php
presents a viable design to improve this.Following patch is a complete working implementation of that design.
I'm still testing it, but its worth publishing as early as possible to
allow discussion. Not for commit, just yet, but soon.Um, you're not considering this for 9.0, are you? I think it's time to
concentrate on the must-fix issues and fix the rough edges in what we have.Yes, it is important.
For example, the "can't start hot standby mode from a shutdown
checkpoint" issue is a must-fix issue in my opinion, about 10x as
important as this. When that was last discussed, many others agreed. I
run into that all the time when testing streaming replication, and every
time I go "Huh, why isn't the standby opening up for connections?", and
then, "Ahh, it's this stupid shutdown checkpoint issue again".That was not the feedback I have received. Nobody has commented on that
to me,
Yes they have. I have on several occasions, as have other people on this
mailing list:
http://archives.postgresql.org/message-id/603c8f070912201611h4951087craa080ff6b48a97cd@mail.gmail.com
http://archives.postgresql.org/message-id/4B30AE53.6020202@gmail.com
http://archives.postgresql.org/message-id/407d949e0912220738je1e0141m87d7b688dd4ba27f@mail.gmail.com
I even *fixed* that already, but you decided to take it out before
committing. I then added it to the list of must-fix items in the TODO
list, but you took that out too. I have no objection to doing things in
smaller steps, but this *is* a must-fix item before release. I still
don't understand why you took it out, nor why you're objecting to that.
though many have commented on the need for the current patch.
Who?
As
mentioned, I went to the trouble of running a meeting to gain additional
feedback and the result was very clear.
So what was the clear result?
If you're looking for things to do, I agree with Greg Stark that the
removal of max_standby_delay=-1 option is not good. That should be fixed
too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
So what was the clear result?
I have spoken clearly enough. You were welcome to attend the Hot Standby
User Group. The fact that you did not expresses your own priorities
quite well, ISTM. Your protestations to know more about the wishes of
users than they do themselves isn't hugely impressive.
There are many features we should add. I will add them in priority order
until forced to stop.
If you or anyone else believes features are essential, then either add
them yourselves or have the courage to stand up and say the release
should be delayed so that I can. To do otherwise is to admit you do not
actually consider them essential. It cannot be both ways.
--
Simon Riggs www.2ndQuadrant.com
Heikki Linnakangas wrote:
Simon Riggs wrote:
Conflict resolution improvements are important to include in this
release, as discussed many times. Proposal given here
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php
presents a viable design to improve this.Following patch is a complete working implementation of that design.
I'm still testing it, but its worth publishing as early as possible to
allow discussion. Not for commit, just yet, but soon.Um, you're not considering this for 9.0, are you? I think it's time to
concentrate on the must-fix issues and fix the rough edges in what we have.
I agree - this looks like a completely new feature development to me
that tries to move the goalpost quite far for 9.0.
For example, the "can't start hot standby mode from a shutdown
checkpoint" issue is a must-fix issue in my opinion, about 10x as
important as this. When that was last discussed, many others agreed. I
run into that all the time when testing streaming replication, and every
time I go "Huh, why isn't the standby opening up for connections?", and
then, "Ahh, it's this stupid shutdown checkpoint issue again".
Yeah I ran into that one during testing as well - and I consider it a
serious issue
And the VACUUM FULL issue is still hanging too. And maybe you could help
with some other things on the open items or commitfest list.
yeah and we keep finding major bugs nearly daily so I don't think we
should add features that way now.
First is stability and reliability, optimization and new features are
imho clearly 9.1+ material. Just calling the release 9.0 and saying "we
do that because it is a radical change and we expect some instability"
should NOT mean we are free to put in every feature at the last minute
with "yeah thats fine because people expect instability anyways".
Stefan
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
So what was the clear result?
I have spoken clearly enough. You were welcome to attend the Hot Standby
User Group. The fact that you did not expresses your own priorities
quite well, ISTM. Your protestations to know more about the wishes of
users than they do themselves isn't hugely impressive.
huh? traditionally discussions of that kind had to happen on -hackers
and not in some online place some unnamed people attended.
There are many features we should add. I will add them in priority order
until forced to stop.
we are past the point of adding new features for 9.0 imho
If you or anyone else believes features are essential, then either add
them yourselves or have the courage to stand up and say the release
should be delayed so that I can. To do otherwise is to admit you do not
actually consider them essential. It cannot be both ways.
bugfix and stabilization mode is what we are in now (except for the
stuff that already made it into the commitfest).
Stefan
On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote:
yeah and we keep finding major bugs nearly daily
Facts, please?
--
Simon Riggs www.2ndQuadrant.com
2010/1/29 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>:
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
So what was the clear result?
I have spoken clearly enough. You were welcome to attend the Hot Standby
User Group. The fact that you did not expresses your own priorities
quite well, ISTM. Your protestations to know more about the wishes of
users than they do themselves isn't hugely impressive.huh? traditionally discussions of that kind had to happen on -hackers and not in some online place some unnamed people attended.
+1.
Haven't we had enough communications failures with off-hackers groups
trying to come up with something only to have it not be agreed upon by
hackers later on?
(win32 would be the biggest thing so far, but it's not like we haven't
done it before in more cases)
There are many features we should add. I will add them in priority order
until forced to stop.we are past the point of adding new features for 9.0 imho
If you or anyone else believes features are essential, then either add
them yourselves or have the courage to stand up and say the release
should be delayed so that I can. To do otherwise is to admit you do not
actually consider them essential. It cannot be both ways.bugfix and stabilization mode is what we are in now (except for the stuff that already made it into the commitfest).
Well, per some recent discussions, it seems small features are still
ok. But I doubt this qualifies as such.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Fri, 2010-01-29 at 11:12 +0100, Stefan Kaltenbrunner wrote:
There are many features we should add. I will add them in priority order
until forced to stop.we are past the point of adding new features for 9.0 imho
So presumably we cannot add the new feature to start hot standby at
shutdown checkpoints then either?
If you or anyone else believes features are essential, then either add
them yourselves or have the courage to stand up and say the release
should be delayed so that I can. To do otherwise is to admit you do not
actually consider them essential. It cannot be both ways.bugfix and stabilization mode is what we are in now (except for the
stuff that already made it into the commitfest).
That's where we'd like to be, but these new features have not been in
the tree long enough for what you say to be the actual position. We can
pretend it is, but that doesn't make it so.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote:
yeah and we keep finding major bugs nearly daily
Facts, please?
5 seconds of time spent on archives.postgresql.org show at least the
following SR/HS related bugs in the last 7 days or so:
http://archives.postgresql.org/pgsql-committers/2010-01/msg00400.php
http://archives.postgresql.org/pgsql-committers/2010-01/msg00410.php
http://archives.postgresql.org/pgsql-committers/2010-01/msg00396.php
http://archives.postgresql.org/pgsql-committers/2010-01/msg00323.php
some of those you might call "minor" but they are bugs and given the
current rate we are seeing them is imho a clear sign of "code by far not
stable enough to consider new features that late in the cycle"
Stefan
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:12 +0100, Stefan Kaltenbrunner wrote:
There are many features we should add. I will add them in priority order
until forced to stop.we are past the point of adding new features for 9.0 imho
So presumably we cannot add the new feature to start hot standby at
shutdown checkpoints then either?
well as far as I recall that ones has been proposed much earlier than
mid of december(like the patch in discussion here) and I agree with
heikki that I'm not clear on what your actual objections to that patch
were - care to provide a link to the archives please?
If you or anyone else believes features are essential, then either add
them yourselves or have the courage to stand up and say the release
should be delayed so that I can. To do otherwise is to admit you do not
actually consider them essential. It cannot be both ways.bugfix and stabilization mode is what we are in now (except for the
stuff that already made it into the commitfest).That's where we'd like to be, but these new features have not been in
the tree long enough for what you say to be the actual position. We can
pretend it is, but that doesn't make it so.
Not sure I follow (maybe because I'm not a native speaker) but are you
trying to say that we can simply add new features late in the release
cycle to stuff commited because it is not long in the tree instead of
focusing stabilizing what we have?
If you are so sure that we NEED those features to be releaseworthy -
maybe it was premature to commit HS and SR for this cycle?
Stefan
On Fri, 2010-01-29 at 11:20 +0100, Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote:
yeah and we keep finding major bugs nearly daily
Facts, please?
5 seconds of time spent on archives.postgresql.org show at least the
following SR/HS related bugs in the last 7 days or so:http://archives.postgresql.org/pgsql-committers/2010-01/msg00400.php
http://archives.postgresql.org/pgsql-committers/2010-01/msg00410.php
http://archives.postgresql.org/pgsql-committers/2010-01/msg00396.php
http://archives.postgresql.org/pgsql-committers/2010-01/msg00323.phpsome of those you might call "minor" but they are bugs and given the
current rate we are seeing them is imho a clear sign of "code by far not
stable enough to consider new features that late in the cycle"
I don't think two very minor bugs in Hot Standby, reported and fixed 7
days apart is any indication of instability. It isn't the "daily bugs
reported" you suggested. Personally, I think it indicates quite the
opposite - if those are the only bugs I can find now, I'm ecstatic.
I think your argument does apply to Streaming Rep, at this point. We
should consider releasing Alpha4 and then later going to Beta.
My point of view expressed here is not built in a few seconds, it is
built on discussion and feedback over 18 months. The conflict issue was
discussed by me with hackers at the May 2008 dev meeting. It should be
improved upon in this release and it has been the main issue concerning
the full range of people I have discussed HS with.
--
Simon Riggs www.2ndQuadrant.com
On Fri, Jan 29, 2010 at 5:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
So what was the clear result?
I have spoken clearly enough. You were welcome to attend the Hot Standby
User Group. The fact that you did not expresses your own priorities
quite well, ISTM. Your protestations to know more about the wishes of
users than they do themselves isn't hugely impressive.
This doesn't make any sense at all. It is not the case that people
who attended the Hot Standby user group are the only ones who are
entitled to provide any feedback, and that people who read
pgsql-hackers are not (unless they also happen to have attended the
Hot Standby user group). If anything, that's 100% backwards, but at
any rate Heikki has probably spent more time over the last year on
this feature than anyone in the world with the exception of yourself;
I think that counts for a lot more than one two-hour meeting.
...Robert
On Fri, 2010-01-29 at 07:01 -0500, Robert Haas wrote:
On Fri, Jan 29, 2010 at 5:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
So what was the clear result?
I have spoken clearly enough. You were welcome to attend the Hot Standby
User Group. The fact that you did not expresses your own priorities
quite well, ISTM. Your protestations to know more about the wishes of
users than they do themselves isn't hugely impressive.This doesn't make any sense at all.
I am busy working on the right features for the most number of people,
as expressed to me. I accept there are people that disagree and I am
sorry for that. Others are welcome to add code to do the things I will
not be doing through lack of time, if they are not satisfied with my
priority.
I think we should extend the time available to make sure we have a
sensible set of features for 9.0. The heat of this discussion tells me
that we are going to be lacking features that are must-have to someone,
whether or not they are in the majority.
--
Simon Riggs www.2ndQuadrant.com
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote:
I even *fixed* that already, but you decided to take it out before
committing. I then added it to the list of must-fix items in the TODO
list, but you took that out too. I have no objection to doing things
in smaller steps, but this *is* a must-fix item before release. I
still don't understand why you took it out, nor why you're objecting
to that.
This is a misrepresentation of what has happened. The item you mention
was added to the TODO by me in response to your comments and has never
been removed at any point; it is still there now. You added a duplicate
and the duplicate was removed. I removed code that you mentioned was
buggy because I don't have time to fix it and it is not high enough up
the priority list. We have discussed all of these things before yet you
raise them again as if those things have never been said.
I am working on TODO in a priority order. The priority list has changed
over time in response to comments received from both you and other
people. I understand you don't like my current sequence of actions and
I'm sorry for that. I am trying to be rational and balance what has been
said to me for the benefit of the community from all stakeholders and
have consulted widely to gather thoughts.
I am more than happy for other people to work on items on the list, as
Joachim and Andres have done.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs wrote:
I removed code that you mentioned was
buggy because I don't have time to fix it and it is not high enough up
the priority list. We have discussed all of these things before yet you
raise them again as if those things have never been said.
*sigh*. Yeah, we've been through this. As I've said before, I never said
the code was buggy, that was just a misunderstanding at your end.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
The fundamental disagreement here is over what qualifies as a
"wishlist" item, aka a feature or added functionality. And what
qualifies as a must-fix bug.
Priorities are context sensitive. If this were early in the cycle then
working on bigger impact features like conflict resolution code might
be more important because it's important to get them into the code
base where other people can see if it solves their problems and the
behaviour can be tweaked. Fixing rare but outright broken things might
not be high priority because while they have to be done by release
nobody is blocking on on the solution before then.
On the other hand near release we stop trying to incorporate new
features and focus on basic bug features. The new features don't
become any less important to the users, it's just that they'll make it
into the next release. There will always be more features that can
help users and we'll always think of cool new things to knock off the
rough edges off what we have now and get it out so we can go back to
the playground for the next release.
You said "I think we should extend the time available to make sure we
have a sensible set of features for 9.0." Perhaps part of the problem
is that I couldn't understand what your patch did from the description
you posted and can't evaluate whether it's fixing a problem that makes
the current feature set incoherent. Can you explain what it does in
more detail so we can understand why it's necessary for a sensible set
of features?
