-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Gaetano Mendola <[EMAIL PROTECTED]> writes:
|
|>>I think we should just call gettimeofday() at postmaster start and store
|>>it somewhere.
|
|
|>Isn't the shared memory a good place ?
|
|
| Depends. Do you want to reset it during a ba
Gaetano Mendola <[EMAIL PROTECTED]> writes:
>> I think we should just call gettimeofday() at postmaster start and store
>> it somewhere.
> Isn't the shared memory a good place ?
Depends. Do you want to reset it during a backend-crash-recovery cycle?
You'll have to, if it's only stored in shared
Bruce Momjian wrote:
Andreas Pflug wrote:
Guess what I just implemented...
pg_postmaster_starttime() RETURNS timestamp, currently implemented in
the admin module for win32 using GetProcessTimes(PostmasterHandle).
What's the equivalent for posix? Interpreting popen("ps...") might get
messy.
I
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >
> > I think we should just call gettimeofday() at postmaster start and store
> > it somewhere.
>
> No objections, but that's probably not done in 8.0 any more, right?
Right.
--
Bruce Momjian| http://candle.pha.pa.us
Bruce Momjian wrote:
I think we should just call gettimeofday() at postmaster start and store
it somewhere.
No objections, but that's probably not done in 8.0 any more, right?
Regards,
Andreas
---(end of broadcast)---
TIP 2: you can get off all lists
Andreas Pflug wrote:
> Robert Treat wrote:
>
> >
> > If we do add this function, I guarantee you that you'll see it added to
> > phppgadmin and pgadmin, because it helps make these remote
> > administration tools more complete.
>
> :-)
> Guess what I just implemented...
>
> pg_postmaster_start
Robert Treat wrote:
If we do add this function, I guarantee you that you'll see it added to
phppgadmin and pgadmin, because it helps make these remote
administration tools more complete.
:-)
Guess what I just implemented...
pg_postmaster_starttime() RETURNS timestamp, currently implemented in
the
On Fri, 2004-08-20 at 05:41, Gaetano Mendola wrote:
> Tom Lane wrote:
>
> > I'd like to see more than one person requesting this (and with solider
> > rationales) before it gets added to TODO. If I wanted to be picky I
> > would suggest that knowledge of the server start time might be useful
>
Tom Lane wrote:
> I'd like to see more than one person requesting this (and with solider
rationales) before it gets added to TODO. If I wanted to be picky I
would suggest that knowledge of the server start time might be useful
information to an attacker. It would for instance narrow down the
num
Richard Huxton wrote:
Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Does anyone have any 'benefits' to implementing such a thing that we
can list? The cons appear to be easy, what about pros?
That's exactly what's bugging me --- I have not seen any particularly
strong defense of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Kings-Lynne wrote:
|> It seems that there is no way to know the postgres
|> uptime, a sort of uptime() function could be usefull.
|> I had recently the necessity of detect a node fail over,
|> and the only way I can do it with a SQL connecti
Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Does anyone have any 'benefits' to implementing such a thing that we can
list? The cons appear to be easy, what about pros?
That's exactly what's bugging me --- I have not seen any particularly
strong defense of why we *should* have
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Good point(s) ... but, what would that give an attacker? Being able to
> isolate the random seed, that is?
Well, the random seed determines the salt values that will be used to
challenge password logins. So it might help you execute a
password-re
On Fri, 20 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Fri, 20 Aug 2004, Gavin Sherry wrote:
However, I'm not sure why an uptime is all that useful?
Bragging rights? :)
The folks who have a legitimate interest in that number can surely find
it out from "ps". What I
On Fri, 20 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Thu, 19 Aug 2004, Tom Lane wrote:
I'd like to see more than one person requesting this (and with solider
rationales) before it gets added to TODO. If I wanted to be picky I
would suggest that knowledge of the se
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Fri, 20 Aug 2004, Gavin Sherry wrote:
>> However, I'm not sure why an uptime is all that useful?
> Bragging rights? :)
The folks who have a legitimate interest in that number can surely find
it out from "ps". What I'm having a hard time with he
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Thu, 19 Aug 2004, Tom Lane wrote:
>> I'd like to see more than one person requesting this (and with solider
>> rationales) before it gets added to TODO. If I wanted to be picky I
>> would suggest that knowledge of the server start time might be
Marc G. Fournier wrote:
> On Thu, 19 Aug 2004, Tom Lane wrote:
>
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Is the uptime kept internally anywhere? Or even the start time?
> >
> > No, and no (at least not in any globally accessible variable).
> >
> >> If it is, it would be quite trivial
On Thu, 19 Aug 2004, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Is the uptime kept internally anywhere? Or even the start time?
No, and no (at least not in any globally accessible variable).
If it is, it would be quite trivial to provide access to it
Not really --- in the EXEC_BACK
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Is the uptime kept internally anywhere? Or even the start time?
>
> No, and no (at least not in any globally accessible variable).
>
> > If it is, it would be quite trivial to provide access to it
>
> Not really --- in the EXEC_BA
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Is the uptime kept internally anywhere? Or even the start time?
No, and no (at least not in any globally accessible variable).
> If it is, it would be quite trivial to provide access to it
Not really --- in the EXEC_BACKEND case, we'd have to do some
Marc G. Fournier wrote:
> On Fri, 20 Aug 2004, Gavin Sherry wrote:
>
>>
>> On Thu, 19 Aug 2004, Alvaro Herrera wrote:
>>
>>> On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne
>>> wrote:
> It seems that there is no way to know the postgres uptime, a sort
> of uptime() fun
On Fri, 20 Aug 2004, Gavin Sherry wrote:
On Thu, 19 Aug 2004, Alvaro Herrera wrote:
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detec
On Thu, 19 Aug 2004, Alvaro Herrera wrote:
> On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
> > >It seems that there is no way to know the postgres
> > >uptime, a sort of uptime() function could be usefull.
> > >I had recently the necessity of detect a node fail over,
>
Added to TODO:
* Add a function that returns the 'uptime' of the postmaster
---
Alvaro Herrera wrote:
> On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
> > >It seems that there is no way to
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
> >It seems that there is no way to know the postgres
> >uptime, a sort of uptime() function could be usefull.
> >I had recently the necessity of detect a node fail over,
> >and the only way I can do it with a SQL connection i
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detect a node fail over,
and the only way I can do it with a SQL connection is asking
the engine uptime. Of course I can do it with PS but
now that windows versio
Hi all,
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detect a node fail over,
and the only way I can do it with a SQL connection is asking
the engine uptime. Of course I can do it with PS but
now that window
28 matches
Mail list logo
