From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Markus Wanner <markus(at)bluegap(dot)ch> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Synchronous Log Shipping Replication |
Date: | 2008-09-07 02:09:17 |
Message-ID: | 200809070209.m8729HX01696@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2008-09-07 02:23:05 | Re: hash index improving v3 |
Previous Message | David Rowley | 2008-09-07 02:03:57 | Re: [PATCHES] TODO item: Implement Boyer-Moore searching (First time hacker) |