Hot Standby and handling max_standby_delay
in [PgSql]
|
From: Simon Riggs on 16 Jan 2010 12:51 On Fri, 2010-01-15 at 20:50 +0200, Heikki Linnakangas wrote: > That would change the meaning of max_standby_delay. Currently, it's the > delay between *generating* and applying a WAL record, your proposal > would change it to mean delay between receiving and applying it. That > seems a lot less useful to me. It would be good if there was a keepalive WAL record with a timestamp on it generated every N seconds while in streaming mode. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 16 Jan 2010 13:20 On Sat, 2010-01-16 at 11:37 -0500, Tom Lane wrote: > Simon Riggs <simon(a)2ndQuadrant.com> writes: > > I'm wondering if it wouldn't just be easier to put in a plugin for > > recovery conflict handling, so the user can decide what to do > > themselves. That seems like a better plan than chewing through these > > issues now. > > Making it a plugin doesn't solve anything. This is not the kind of > thing where people can come up with some random policy and it will > work well. Anyone competent to invent a better policy would be quite > capable of modifying the source to suit themselves. Agreed, with some regrets. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 16 Jan 2010 15:12 On Sat, 2010-01-16 at 18:20 +0000, Simon Riggs wrote: > On Sat, 2010-01-16 at 11:37 -0500, Tom Lane wrote: > > Simon Riggs <simon(a)2ndQuadrant.com> writes: > > > I'm wondering if it wouldn't just be easier to put in a plugin for > > > recovery conflict handling, so the user can decide what to do > > > themselves. That seems like a better plan than chewing through these > > > issues now. > > > > Making it a plugin doesn't solve anything. This is not the kind of > > thing where people can come up with some random policy and it will > > work well. Anyone competent to invent a better policy would be quite > > capable of modifying the source to suit themselves. > > Agreed, with some regrets. Although I agree in principle, I have to say that a plugin might make sense. Yes... the person is good enough to modify the code, but should they? A plugin allows them to make those decisions without running a custom code base for core. Just a thought. Joshua D. Drake > > -- > Simon Riggs www.2ndQuadrant.com > > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 17 Jan 2010 15:57 Simon Riggs wrote: > On Fri, 2010-01-15 at 20:50 +0200, Heikki Linnakangas wrote: > >>> So in either case, when we are waiting for new input we reset the timer >>> as soon as new WAL is received. The resolution/accuracy of standby_delay >>> will be no more than the time taken to replay a single file. This >>> shouldn't matter, since sane settings of max_standby_delay are either 0 >>> or a number like 5-20 (seconds). >> That would change the meaning of max_standby_delay. Currently, it's the >> delay between *generating* and applying a WAL record, your proposal >> would change it to mean delay between receiving and applying it. That >> seems a lot less useful to me. > > Remember that this proposal is about responding to your comments. You > showed that the time difference between generating and applying a WAL > record lacked useful meaning in cases where the generation was not > smooth and continuous. Yeah, I remember that. What the DBA cares about is the time between a commit record being generated in the master, and the same record being applied in the standby. That's easy to explain and tune for, and that's what max_standby_delay should be. Let's not redefine it into something less useful just because there's corner cases where we can't calculate it easily. The standby would really need to know the timestamp of the *next* commit record in the WAL. Next from the record that's being applied. We don't want to peek ahead, and we might not even have received the next commit record yet even if it's already been generated in master, so we approximate the timestamp of next commit record with timetamp of previous commit record. > It would be good if there was a keepalive WAL record with a timestamp on > it generated every N seconds while in streaming mode. Yeah, that would help. In streaming replication we could also send such timestamp as a separate message, not within WAL. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 17 Jan 2010 16:51 On Sun, 2010-01-17 at 22:57 +0200, Heikki Linnakangas wrote: > > > It would be good if there was a keepalive WAL record with a > timestamp on it generated every N seconds while in streaming mode. > > Yeah, that would help. In streaming replication we could also send > such timestamp as a separate message, not within WAL. Is that something you're working on? Do we need a new record type for that, is there a handy record type to bounce from? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: [HACKERS] Hot Standby and handling max_standby_delay Next: Mammoth in Core? |