Обсуждение: Re: [DOCS] max_worker_processes on the standby
Adding CC to hackers, since this is clearly not just a docs issue. Also CCing Petr and Craig since they are the ones that know how this is used in BDR. Robert Haas wrote: > On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: > > The alternative is to turn the feature on automatically if it sees that > > the master also has it on, i.e. the value would not be what the config > > file says it is. Doing this would be a bit surprising IMO, but given > > the behavior above maybe it's better than the current behavior. > > I think it's totally reasonable for the standby to follow the master's > behavior rather than the config file. That should be documented, but > otherwise, no problem. If it were technologically possible for the > standby to follow the config file rather than the master in all cases, > that would be fine, too. But the current behavior is somewhere in the > middle, and that doesn't seem like a good plan. So I discussed this with Petr. He points out that if we make the standby follows the master, then the problem would be the misbehavior that results once the standby is promoted: at that point the standby would no longer "follow the master" and would start with the feature turned off, which could be disastrous (depending on what are you using the commit timestamps for). To solve that problem, you could suggest that if we see the setting turned on in pg_control then we should follow that instead of the config file; but then the problem is that there's no way to turn the feature off. And things are real crazy by then. Given this, we're leaning towards the idea that the standby should not try to follow the master at all. Instead, an extension that wants to use this stuff can check the value for itself, and raise a fatal error if it's not already turned on the config file. That way, a lot of the strange corner cases disappear. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2015-08-05 00:13, Alvaro Herrera wrote: > Robert Haas wrote: >> On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera >> <alvherre@2ndquadrant.com> wrote: > >>> The alternative is to turn the feature on automatically if it sees that >>> the master also has it on, i.e. the value would not be what the config >>> file says it is. Doing this would be a bit surprising IMO, but given >>> the behavior above maybe it's better than the current behavior. >> >> I think it's totally reasonable for the standby to follow the master's >> behavior rather than the config file. That should be documented, but >> otherwise, no problem. If it were technologically possible for the >> standby to follow the config file rather than the master in all cases, >> that would be fine, too. But the current behavior is somewhere in the >> middle, and that doesn't seem like a good plan. > > So I discussed this with Petr. He points out that if we make the > standby follows the master, then the problem would be the misbehavior > that results once the standby is promoted: at that point the standby > would no longer "follow the master" and would start with the feature > turned off, which could be disastrous (depending on what are you using > the commit timestamps for). > > Given this, we're leaning towards the idea that the standby should not > try to follow the master at all. Instead, an extension that wants to > use this stuff can check the value for itself, and raise a fatal error > if it's not already turned on the config file. That way, a lot of the > strange corner cases disappear. > Actually, after thinking bit more about this I think the behavior of these two will be similar - you suddenly lose the commit timestamp info. The difference is that with fist option you'll lose it after restart while with second one you lose it immediately after promotion since there was never any info on the slave. Extensions can do sanity checking in both scenarios. The way I see it the first option has following advantages: - it's smaller change - it's more consistent with how wal_log_hints behaves - fixing the config does not require server restart since the in-memory state was set from WAL record automatically However the second option has also some: - one can have slave which doesn't have overhead of the commit timestamp SLRU if they don't need it there - it's theoretically easier to notice that the track_commit_timestamps is off in config because the the SQL interface will complain if called on the slave So +0.5 from me towards following master and removing the error message -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> I think it's totally reasonable for the standby to follow the master's >> behavior rather than the config file. That should be documented, but >> otherwise, no problem. If it were technologically possible for the >> standby to follow the config file rather than the master in all cases, >> that would be fine, too. But the current behavior is somewhere in the >> middle, and that doesn't seem like a good plan. > > So I discussed this with Petr. He points out that if we make the > standby follows the master, then the problem would be the misbehavior > that results once the standby is promoted: at that point the standby > would no longer "follow the master" and would start with the feature > turned off, which could be disastrous (depending on what are you using > the commit timestamps for). That seems like an imaginary problem. If it's critical to have commit timestamps, don't turn them off on the standby. > To solve that problem, you could suggest that if we see the setting > turned on in pg_control then we should follow that instead of the config > file; but then the problem is that there's no way to turn the feature > off. And things are real crazy by then. There's no existing precedent for a feature that lets the standby be different from the master *in any way*. So I don't see why we should start here. I think the reasonable definition is that the GUC controls whether the master tries to update the SLRU (and generate appropriate WAL records, presumably). The standby should not get a choice about whether to replay those WAL records. Note that if you do allow the standby to decide not to replay the WAL records for this feature, then the data on the standby could be partially there but not completely there after promotion, because the DBA might have flipped the switch on and off at different times. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company