From: | "Diogo Biazus" <diogob(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: xlog viewer proposal |
Date: | 2006-06-22 17:57:16 |
Message-ID: | eca519a10606221057n3ff21201o333a8e85ac1e3bcb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Agree, the project must choose one path as the starting point. But the two
options can be given in the long run.
I still think that as a starting point the functions inside the database are
a good option.
The reasons are:
- using SQL to agregate and transform data in any way from the logs.
- it's easier for the DBA in the other use cases where the cluster is still
active.
- give more flexibility for managing the xlogs remotely
- I think it's faster to implement and to have a working and usable tool.
And there is one option to minimize the problem in the failed cluster case:
the wrapper program could give the option to initdb a temporary area when no
connection is given, creating a backend just to analyze a set of xlogs.
After this summer project I could go on and try to use parts of this code to
implement a realy standalone tool.
Other option is to start by the standalone tool and create a wrapper
function inside postgresql that would just call this external program and
extract data from the xlogs using this program's output (with some option to
output all data in a CSV format).
On 6/22/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> > I think it should certainly be able to run on it's own, but it
> > wouldn't be that hard to extend the functions so that they were usable
> > from within the database or vice-versa.
>
> Yes it would. The most obvious point is that memory management and
> error handling conventions inside the backend are quite different from
> what you'd expect to employ in a standalone program. Also the means
> you'd use for consulting the system catalogs (in that option to provide
> readable names for OIDs) are entirely different.
>
> I think asking for support of both environments is a good way to ensure
> that this summer project doesn't get finished :-(
>
> regards, tom lane
>
--
Diogo Biazus - diogob(at)gmail(dot)com
Móvel Consultoria
http://www.movelinfo.com.br
http://www.postgresql.org.br
From | Date | Subject | |
---|---|---|---|
Next Message | Lukas Smith | 2006-06-22 18:03:13 | Re: vacuum, performance, and MVCC |
Previous Message | Mark Woodward | 2006-06-22 17:56:56 | Re: vacuum, performance, and MVCC |