Re: xlog viewer proposal

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

In response to

Responses

Browse pgsql-hackers by date

  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