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 what you mean. - I
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 much
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
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 reads
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
Not
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 working and
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 it
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
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
error
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:
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
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
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
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 would
14 matches
Mail list logo
