Re: [HACKERS] xlog viewer prototype and new proposal

[Diogo Biazus]

On 7/7/06, Martijn van Oosterhout  wrote:
Something I've been thinking of while reading this thread. One bigdisadvantage of doing it in the backend is that your methods ofreturning data are limited. Your resultset can only return one "type".
For example, if you start decoding all the different types of xlogpackets, you're going to get different information for each. To displaythat as the output of a function you're going to have to munge theminto a common format. An external program does not suffer this
limitation.In the future it may be worthwhile making a library that can be used byboth an external program and the postgres backend, but really, thatseems a lot less work than doing the actual decoding itself...
Hope this helps,Sure, but in the backend idea it could be handled with a functions for the comon data, and other functions to extract especific data from diferent operations.But I was hoping to get more input about the functionality expected in the standalone tool, what could improve the existing xlogdump?
-- Diogo Biazus - [EMAIL PROTECTED]Móvel Consultoriahttp://www.movelinfo.com.br
http://www.postgresql.org.br

Re: [HACKERS] xlog viewer prototype and new proposal

[Martijn van Oosterhout]

On Fri, Jul 07, 2006 at 11:59:41AM -0300, Diogo Biazus wrote:
> On 07 Jul 2006 09:58:29 -0400, Greg Stark <[EMAIL PROTECTED]> wrote:
> > 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?

Something I've been thinking of while reading this thread. One big
disadvantage of doing it in the backend is that your methods of
returning data are limited. Your resultset can only return one "type".
For example, if you start decoding all the different types of xlog
packets, you're going to get different information for each. To display
that as the output of a function you're going to have to munge them
into a common format. An external program does not suffer this
limitation.

In the future it may be worthwhile making a library that can be used by
both an external program and the postgres backend, but really, that
seems a lot less work than doing the actual decoding itself...

Hope this helps,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to 
> litigate.


signature.asc
Description: Digital signature

Re: [HACKERS] xlog viewer prototype and new proposal

[Diogo Biazus]

On 07 Jul 2006 09:58:29 -0400, Greg Stark <[EMAIL PROTECTED]
> wrote:
"Diogo Biazus" <[EMAIL PROTECTED]> 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 thatinformation?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 thatcase.

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 toanalyze 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 canalways 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 - 

[EMAIL PROTECTED]Móvel Consultoriahttp://www.movelinfo.com.br
http://www.postgresql.org.br

Re: [HACKERS] xlog viewer prototype and new proposal

[Greg Stark]

"Diogo Biazus" <[EMAIL PROTECTED]> 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.

> - 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.

> - 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.

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.

-- 
greg


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq