Re: Re: xReader, double-effort (was: Temporary tables under hot standby)
От | Simon Riggs |
---|---|
Тема | Re: Re: xReader, double-effort (was: Temporary tables under hot standby) |
Дата | |
Msg-id | CA+U5nMLv91h9oSrKyCryuiTFjEexWu3DPCk4s2S-57GjfNQGUg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: xReader, double-effort (was: Temporary tables under hot standby) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, Apr 28, 2012 at 4:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> Tom Lane wrote: >>> Simon Riggs writes: >>>> Translating WAL is a very hard task. >>> No kidding. I would think it's impossible on its face. > >> Well, the xReader approach (Aakash's GSoC project) is to serve as a >> proxy for a WAL stream going to a hot standby, to interpret each >> incoming WAL record by "cheating" and querying the HS before passing >> the WAL along, and then using sync rep to the HS regardless of >> whether the incoming stream is sync or async. What reliability >> problem do you see with this approach? > > Well, first off, it requires a replica that *is* a physical replica > (else it won't have the same table OIDs, for instance). It's even harder than that because the physical replica needs to be able to be shutdown/restarted. We currently restart WAL from last checkpoint, but if changes have already been made and committed then the catalog will be incorrect when we replay the WAL again. So, I think saying very hard is justified. We basically have a choice of shipping full metadata with every change or finding some way to avoid doing that. Investigating the latter seems like a worthwhile task but there are limits, as you say. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: