Re: pg_basebackup for streaming base backups
От | Dimitri Fontaine |
---|---|
Тема | Re: pg_basebackup for streaming base backups |
Дата | |
Msg-id | m2hbd34ciy.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: pg_basebackup for streaming base backups (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_basebackup for streaming base backups
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@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
В списке pgsql-hackers по дате отправления: