-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
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
-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 connection
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
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
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
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
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_starttime() RETURNS
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
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
[EMAIL
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
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
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
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
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 is
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 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,
and the
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
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() function could be usefull.
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
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_BACKEND case,
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
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 to provide access
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 useful
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 here is the
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
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'm
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-replay
28 matches
Mail list logo
