Re: synchronous_commit = remote_flush
От | Jim Nasby |
---|---|
Тема | Re: synchronous_commit = remote_flush |
Дата | |
Msg-id | b861cfbd-f319-c025-309e-f7a39d8dd082@BlueTreble.com обсуждение исходный текст |
Ответ на | synchronous_commit = remote_flush (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: synchronous_commit = remote_flush
|
Список | pgsql-hackers |
On 8/17/16 11:22 PM, Thomas Munro wrote: > Hi hackers, > > To do something about the confusion I keep seeing about what exactly > "on" means, I've often wished we had "remote_flush". But it's not > obvious how the backwards compatibility could work, ie how to keep the > people happy who use "local" vs "on" to control syncrep, and also the > people who use "off" vs "on" to control asynchronous commit on > single-node systems. Is there any sensible way to do that, or is it > not broken and I should pipe down, or is it just far too entrenched > and never going to change? I'm wondering if we've hit the point where trying to put all of this in a single GUC is a bad idea... changing that probably means a config compatibility break, but I don't think that's necessarily a bad thing at this point... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461
В списке pgsql-hackers по дате отправления: