Re: pg_background (and more parallelism infrastructure patches)
От | Petr Jelinek |
---|---|
Тема | Re: pg_background (and more parallelism infrastructure patches) |
Дата | |
Msg-id | 544ADECA.5090507@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: pg_background (and more parallelism infrastructure patches) (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 24/10/14 23:07, Robert Haas wrote: > On Fri, Oct 24, 2014 at 4:53 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> The only case I can think of would be actually connecting to a remote >> database; in that case would we even want something as raw as this? I >> suspect not, in which case I don't see an issue. On the other hand, if we >> ever think we might want to do that, we should probably at least stick a >> version number field in there... >> >> But my suspicion is if we ever wanted to do something more with this then >> we'd want some kind of text-based format that could be passed into a SQL >> command (ie: SET ENVIRONMENT TO blah;) > > I mean, I don't think this is much different than what we're already > doing to transfer variables from the postmaster to other backends in > EXEC_BACKEND builds; see write_nondefault_variables(). It doesn't > have a version number or anything either. I don't see a reason why > this code needs to be held to a different standard; the purpose is > fundamentally quite similar. > I really do think that the GUC patch is ok as it is, we might want to do 1/0 for bools but I don't really see that as important thing. And it works for the use-cases it's intended for. I don't see why this should be required to work cross version really. Loading of the modules by bgworker is probably bigger issue than just GUCs, and I think it's out of scope for the current patch(set). -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: