Re: [ADMIN] pg_basebackup blocking all queries with horrible performance
От | Fujii Masao |
---|---|
Тема | Re: [ADMIN] pg_basebackup blocking all queries with horrible performance |
Дата | |
Msg-id | CAHGQGwEPBrECq9ht1MnEYPK5Bpy4ozv1VYyLO6LJY_6OFi2SYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [ADMIN] pg_basebackup blocking all queries with horrible performance (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [ADMIN] pg_basebackup blocking all queries with
horrible performance
Re: [ADMIN] pg_basebackup blocking all queries with horrible performance |
Список | pgsql-hackers |
On Thu, Jun 21, 2012 at 3:18 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jun 20, 2012 at 7:18 AM, Magnus Hagander <magnus@hagander.net> wrote: >>>>> You agreed to add something like NOSYNC option into START_REPLICATION command? >>>> >>>> I'm on the fence. I was hoping somebody else would chime in with an >>>> opinion as well. >>> >>> +1 >> >> Nobody else with any opinion on this? :( > > I don't think we really need a NOSYNC flag at this point. Just not > setting the flush location in clients that make a point of flushing in > a timely fashion seems fine. Okay, I'm in the minority, so I'm writing the patch that way. WIP patch attached. In the patch, pg_basebackup background process and pg_receivexlog always return invalid location as flush one, and will never become sync standby even if their name is in synchronous_standby_names. The timing of their sending the reply depends on the standby_message_timeout specified in -s option. So the write position may lag behind the true position. pg_receivexlog accepts new option -S (better option character?). If this option is specified, pg_receivexlog returns true flush position, and can become sync standby. It sends back the reply to the master each time the write position changes or the timeout passes. If synchronous_commit is set to remote_write, synchronous replication to pg_receivexlog would work well. The patch needs more documentation. But I think that it's worth reviewing the code in advance, so I attached the WIP patch. Comments? Objections? The patch is based on current HEAD, i.e., 9.3dev. If the patch is applied, we need to write the backport version of the patch for 9.2. Regards, -- Fujii Masao
Вложения
В списке pgsql-hackers по дате отправления: