Re: xlog viewer prototype and new proposal

On 07 Jul 2006 09:58:29 -0400, Greg Stark <gsstark(at)mit(dot)edu> wrote:
>
> "Diogo Biazus" <diogob(at)gmail(dot)com> writes:
>
> > I exposed the idea of bringing the xlogdump functionality to a backend
> > module. The main drawback is the use case where the database is down.
> But
> > the access to a failed cluster isn't impossible, just a little bit more
> > dificult, requiring another cluster to be initialized.
>
> Does that mean you're planning to not use the backend's system tables at
> all?
> You'll look at the database cluster under analysis to get all that
> information?
>
> If so then that removes a lot of the objections to running in a backend.
> You're basically just using the backend as a convenient context for
> manipulating and storing table-like data.
>
> It also seems to remove a lot of the motivation for doing it in the
> backend.
> You're not going to get any advantages on the implementation side in that
> case.

Yes, that's correct,

> - I already have a database connection in cases where I want to translate
> > oid to names.
>
> You can't do that if you want to allow people to initialize a new cluster
> to
> analyze a downed cluster.

Sure it would be possible to make the translations only in cases where the
backend is the same generetaing the xlogs.

> - I can connect directly to the postgresql server if I want to query xlogs
>
> > in a remote machine (don't need remote access to the system).
> > - Easier to integrate with existing admin tools, like PgAdmin.
>
> These are unconvincing to non-windows people. In any case a stand-alone
> program could always have a postgres module tacked on to call out to it.

Sure, that's one of the solutions I was thinking about, now I see it can be
the best one.
Using just a backend interface to call the standalone tool.
What I still don't know is:
Is it better to make this interface just calling the program and reading
it's output than using a set of shared macros/functions?

That's the main reason I think a stand-alone module makes more sense. You
> can
> always take a stand-alone module and stick an interface to it into the
> server.
> You can't take code meant to run in the server and build a stand-alone
> environment to run it.

Sure.
On the last part off the proposal I've suggested some improvements to the
stand-alone tool, any other ideas?

--
Diogo Biazus - diogob(at)gmail(dot)com
Móvel Consultoria
http://www.movelinfo.com.br
http://www.postgresql.org.br