Robert Haas <robertmh...@gmail.com> writes: > I think that the basic problem with wal_level is that to increase it > you need to somehow ensure that all the backends have the new setting, > and then checkpoint. Right now, the backends get the value through > the GUC machinery, and so there's no particular bound on how long it > could take for them to pick up the new value. I think if we could > find some way of making sure that the backends got the new value in a > reasonably timely fashion, we'd be pretty close to being able to do > this. But it's hard to see how to do that.
Well, you just said when to force the "reload" to take effect: at checkpoint time. IIRC we already multiplex SIGUSR1, is that possible to add that behavior here? And signal every backend at checkpoint time when wal_level has changed? > I had some vague idea of creating a mechanism for broadcasting > critical parameter changes. You'd make a structure in shared memory > containing the "canonical" values of wal_level and all other critical > variables, and the structure would also contain a 64-bit counter. > Whenever you want to make a parameter change, you lock the structure, > make your change, bump the counter, and release the lock. Then, > there's a second structure, also in shared memory, where backends > report the value that the counter had the last time they updated their > local copies of the structure from the shared structure. You can > watch that to find out when everyone's guaranteed to have the new > value. If someone doesn't respond quickly enough, you could send them > a signal to get them moving. What would really be ideal is if you > could actually make this safe enough that the interrupt service > routine could do all the work, rather than just setting a flag. Or > maybe CHECK_FOR_INTERRUPTS(). If you can't make it safe enough to put > it in someplace pretty low-level like that, the whole idea might fall > apart, because it wouldn't be useful to have a way of doing this that > mostly works except sometimes it just sits there and hangs for a > really long time. > > All pie in the sky at this point... Unless we manage to simplify enough the idea to have wal_level SIGHUP. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers