Re: [HACKERS] xlog viewer proposal

2006-06-25 Thread Diogo Biazus
Alright, I'm working on a fast prototype using the SRF.On 6/23/06, Simon Riggs <[EMAIL PROTECTED]> wrote: On Fri, 2006-06-23 at 10:59 -0300, Diogo Biazus wrote:> On 6/23/06, Simon Riggs < [EMAIL PROTECTED]> wrote:> > - give more flexibility for managing the xlogs remotely>> Not sure

Re: [HACKERS] xlog viewer proposal

2006-06-23 Thread Simon Riggs
On Fri, 2006-06-23 at 10:59 -0300, Diogo Biazus wrote: > On 6/23/06, Simon Riggs <[EMAIL PROTECTED]> wrote: > > - give more flexibility for managing the xlogs remotely > > Not sure what you mean. > > > - I think it's faster to implement and to have a worki

Re: [HACKERS] xlog viewer proposal

2006-06-23 Thread Simon Riggs
On Fri, 2006-06-23 at 11:03 -0300, Diogo Biazus wrote: > On 6/23/06, Diogo Biazus <[EMAIL PROTECTED]> wrote: > On 6/23/06, Simon Riggs <[EMAIL PROTECTED]> wrote: > > - give more flexibility for managing the xlogs > remotely > >

Re: [HACKERS] xlog viewer proposal

2006-06-23 Thread Diogo Biazus
On 6/23/06, Diogo Biazus <[EMAIL PROTECTED]> wrote: On 6/23/06, Simon Riggs < [EMAIL PROTECTED] > wrote: > - give more flexibility for managing the xlogs remotelyNot sure what you mean.I can connect to the server if I want to query xlogs in a remote machine. If i depend on a standalone tool that re

Re: [HACKERS] xlog viewer proposal

2006-06-23 Thread Diogo Biazus
On 6/23/06, Simon Riggs <[EMAIL PROTECTED] > wrote: > - give more flexibility for managing the xlogs remotelyNot sure what you mean.> - I think it's faster to implement and to have a working and usable> tool.Why do you think that? It sounds like you've got more work since you effectively need to re

Re: [HACKERS] xlog viewer proposal

2006-06-23 Thread Simon Riggs
On Thu, 2006-06-22 at 14:57 -0300, Diogo Biazus wrote: > Agree, the project must choose one path as the starting point. But the > two options can be given in the long run. I'm acting as Diogo's mentor for the SoC, so I'm trying to let Diogo discuss his ideas in the community manner without too muc

Re: [HACKERS] xlog viewer proposal

2006-06-22 Thread Jonah H. Harris
On 6/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: Jonah, I've been working with this system for years, and it's not that easy to "handle the differences with a few macros". True, it is harder than just that. I didn't mean to make light of it at all, just that a good amount of design upfront woul

Re: [HACKERS] xlog viewer proposal

2006-06-22 Thread Diogo Biazus
Diogo, are you working from my old xlogdump hack?  If so what version?I can send you the latest off-list.  I add stuff to it periodically when I need it, and I don't think I've published it lately.Yup, I've got a version that was posted here some time ago. If you could send me the latest version I

Re: [HACKERS] xlog viewer proposal

2006-06-22 Thread Diogo Biazus
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 eas

Re: [HACKERS] xlog viewer proposal

2006-06-22 Thread Tom Lane
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > On 6/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: >> 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. >

Re: [HACKERS] xlog viewer proposal

2006-06-22 Thread Jonah H. Harris
On 6/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: 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. No, this wouldn't really be that hard, especially if he

Re: [HACKERS] xlog viewer proposal

2006-06-22 Thread Tom Lane
"Jonah H. Harris" <[EMAIL PROTECTED]> 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 erro

Re: [HACKERS] xlog viewer proposal

2006-06-22 Thread Jonah H. Harris
On 6/22/06, Tom Lane <[EMAIL PROTECTED]> wrote: it'd make it impossible to use the viewer to work on extracting data from a failed cluster; which is, at least in my mind, one of the primary use-cases for the thing. While I too see this as something which could be used for this outside the datab

Re: [HACKERS] xlog viewer proposal

2006-06-22 Thread Tom Lane
"Diogo Biazus" <[EMAIL PROTECTED]> writes: > The idea I've been discussing with Simon Riggs is to create a set of > functions that can be called from within the database. I'd question that at the very start. I don't see any strong reason to do it that way, and as you admit further down it'd make

[HACKERS] xlog viewer proposal

2006-06-22 Thread Diogo Biazus
I'm developing the summer of code project to create a xlog viewer.The tool we want to create is a DBA tool used for inspect the xlog files, looking for some operations, statistcs of database usage and status of transactions. Some use cases:* Some user made a mistake and commited it to the database.