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
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
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
>
>
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
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
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
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
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
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
"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.
>
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
"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
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
"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
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.
15 matches
Mail list logo