Hi Bruce,

I started to work on the uptime() for the postmaster yesterday. A
couple of questions:

a) is the name uptime() OK?

b) is the return-type 'Interval' OK?

c) does it make sense (... fit in the scheme?) to place the code here:
src/backend/utils/misc/uptime.c

d) Can I piggy-back on 'BackendParameters' to get postmasters
start-time to the backends?

happy new year,

Matthias


----------------------------------------------------------------------
Matthias Schmidt
Viehtriftstr. 49

67346 Speyer

Tel.: +49 6232 4867
Fax.: +49 6232 640089


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Matthias Schmidt <schmidtm@mock-software.de> writes:
> a) is the name uptime() OK?

Probably should use pg_uptime(), or something else starting with pg_.

> b) is the return-type 'Interval' OK?

It might be better to return the actual postmaster start time (as
timestamptz) and let the user do whatever arithmetic he wants.
With an interval, there's immediately a question of interpretation
--- what current timestamp did you use in the computation?
I'm not dead set on this, but it feels cleaner.

> c) does it make sense (... fit in the scheme?) to place the code here:
> src/backend/utils/misc/uptime.c

No. This sort of stuff should go into utils/adt/. I'd be inclined to
drop the function into one of the existing timestamp-related files
rather than make a whole new file just for it. Someplace near the
now() function would make sense, for instance.

> d) Can I piggy-back on 'BackendParameters' to get postmasters
> start-time to the backends?

AFAICS you have no other choice.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Hi Tom,

Am 31.12.2004 um 20:18 schrieb Tom Lane:

> Matthias Schmidt <schmidtm@mock-software.de> writes:
>> a) is the name uptime() OK?
>
> Probably should use pg_uptime(), or something else starting with pg_.

What about 'pg_starttime()' since it is not a period but a
point-in-time?

>
>> b) is the return-type 'Interval' OK?
>
> It might be better to return the actual postmaster start time (as
> timestamptz) and let the user do whatever arithmetic he wants.
> With an interval, there's immediately a question of interpretation
> --- what current timestamp did you use in the computation?
> I'm not dead set on this, but it feels cleaner.

you're right. Let's go for timestamptz and let the users decide ...
>
>> c) does it make sense (... fit in the scheme?) to place the code here:
>> src/backend/utils/misc/uptime.c
>
> No. This sort of stuff should go into utils/adt/. I'd be inclined to
> drop the function into one of the existing timestamp-related files
> rather than make a whole new file just for it. Someplace near the
> now() function would make sense, for instance.

yep - so the stuff goes to: utils/adt/timestamp.c, where now() and many
other time-related functions are.

>
>> d) Can I piggy-back on 'BackendParameters' to get postmasters
>> start-time to the backends?
>
> AFAICS you have no other choice.
>
> regards, tom lane
>
>

cheers,

Matthias

----------------------------------------------------------------------
Matthias Schmidt
Viehtriftstr. 49

67346 Speyer

Tel.: +49 6232 4867
Fax.: +49 6232 640089


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Matthias Schmidt wrote:
> Hi Tom,
>
> Am 31.12.2004 um 20:18 schrieb Tom Lane:
>
>> Matthias Schmidt <schmidtm@mock-software.de> writes:
>>
>>> a) is the name uptime() OK?
>>
>>
>> Probably should use pg_uptime(), or something else starting with pg_.
>
>
> What about 'pg_starttime()' since it is not a period but a point-in-time?
>
>>
>>> b) is the return-type 'Interval' OK?
>>
>>
>> It might be better to return the actual postmaster start time (as
>> timestamptz) and let the user do whatever arithmetic he wants.
>> With an interval, there's immediately a question of interpretation
>> --- what current timestamp did you use in the computation?
>> I'm not dead set on this, but it feels cleaner.
>
>
> you're right. Let's go for timestamptz and let the users decide ...
>

Well, the unix guys have the abit to have the uptime as an interval, I'm
inclined to have boths: pg_uptime ( interval ) and pg_starttime (
timestamptz )


Regards
Gaetano Mendola


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Gaetano Mendola <mendola@bigfoot.com> writes:

> Well, the unix guys have the abit to have the uptime as an interval, I'm
> inclined to have boths: pg_uptime ( interval ) and pg_starttime ( timestamptz )

Well for the OS these are not redundant values. The clock could have been
adjusted at any time. So you can't just calculate uptime by subtracting the
current time from the start time.

I suppose this argument is true for Postgres as well. But I'm not sure
Postgres can really make the distinction as easily as the kernel. To return
the actual uptime without being deceived by clock changes it would need to
store not the wall clock time on startup, but the system uptime. And then
calculate the difference in the current system uptime. I'm not sure if there
is a portable interface to get a system uptime.

--
greg


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend