Markus Wanner wrote: > > Hook for WALSender > > ------------------ > > This hook is for introducing WALSender. There are the following > > three ideas of how to introduce WALSender. A required hook > > differs by which idea is adopted. > > > > a) Use WALWriter as WALSender > > > > This idea needs WALWriter hook which intercepts WALWriter > > literally. WALWriter stops the local WAL write and focuses on > > WAL sending. This idea is very simple, but I don't think of > > the use of WALWriter hook other than WAL sending.
The problem with this approach is that you are not sending WAL to the disk _while_ you are, in parallel, sending WAL to the slave; I think this is useful for performance reasons in synrchonous replication. > > b) Use new background process as WALSender > > > > This idea needs background-process hook which enables users > > to define new background processes. I think the design of this > > hook resembles that of rmgr hook proposed by Simon. I define > > the table like RmgrTable. It's for registering some functions > > (e.g. main function and exit...) for operating a background > > process. Postmaster calls the function from the table suitably, > > and manages a start and end of background process. ISTM that > > there are many uses in this hook, e.g. performance monitoring > > process like statspack. I think starting/stopping a process for each WAL send is too much overhead. > > c) Use one backend as WALSender > > > > In this idea, slave calls the user-defined function which > > takes charge of WAL sending via SQL e.g. "SELECT pg_walsender()". > > Compared with other ideas, it's easy to implement WALSender > > because postmater handles the establishment and authentication > > of connection. But, this SQL causes a long transaction which > > prevents vacuum. So, this idea needs idle-state hook which > > executes plugin before transaction starts. I don't think of > > the use of this hook other than WAL sending either. > > The above cited wiki page sounds like you've already decided for b). I assumed that there would be a background process like bgwriter that would be notified during a commit and send the appropriate WAL files to the slave. > I'm unclear on what you want hooks for. If additional processes get > integrated into Postgres, those certainly need to get integrated very > much like we integrated other auxiliary processes. I wouldn't call that > 'hooking', but YMMV. Yea, I am unclear how this is going to work using simple hooks. It sounds like Fujii-san is basically saying they can only get the hooks done for 8.4, not the actual solution. But, as I said above, I am unclear how a hook solution would even work long-term; I am afraid it would be thrown away once an integrated solution was developed. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
