Re: Synchronous commit not... synchronous?
От | Daniel Farina |
---|---|
Тема | Re: Synchronous commit not... synchronous? |
Дата | |
Msg-id | CAAZKuFbQAq90g0gqMEV-D1W=+GqVAsgdPbJawAbs4r6aV=vwDA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronous commit not... synchronous? (Hannu Krosing <hannu@krosing.net>) |
Список | pgsql-hackers |
On Fri, Nov 2, 2012 at 5:08 PM, Hannu Krosing <hannu@krosing.net> wrote: > On 11/02/2012 09:46 PM, Daniel Farina wrote: >> >> The bar for "reliable" non-volatile storage for me are things like >> Amazon's S3, and I think a lot of that has to do with the otherwise >> relatively impoverished semantics it has, so I think this reliability >> profile will be or has been duplicated elsewhere. >> >> In general, this has some relation to remastering issues. >> >> In the future, I'd like to be able to turn off the local pg_xlog, at my >> option. > > Have you tried things like mounting remote RAM drive > over NFS or similar for pg_xlog ? > > You probably could even play with DRBD and have one or both > of the drives be RAM drives. > > Hannu I'm not so interested in such creative workarounds, especially because the operational maintenance cost is huge when magnified when all I wish I could do is buffer WAL and forward to a socket, and then unblock commits when my replication partner says 'alright', just as they do in spirit for flushing pg_xlog -- what I want is simpler than a full blown network file system. I also don't need this kind of thing in the near future -- I'm way behind what's possible as-is. And then there are issues like transport encryption and being able to do this across a geography, ugh. -- fdr
В списке pgsql-hackers по дате отправления: