kris pal <[EMAIL PROTECTED]> writes:
> Actually I just noticed something. Previously for some reason, I
> thought the data directory corresponded to 'regression'. But I double
> checked it now with oid2name and it corresponds to our main database
> say "dds".
Ah, that makes more sense.
> But the
Actually I just noticed something. Previously for some reason, I thought the data directory corresponded to 'regression'. But I double checked it now with oid2name and it corresponds to our main database say "dds".
But the issue still remains. In the sense that pg_attribute etc are still so hug
Okay, that's helpful. I found the relevant code in /backend/tcop/postgres.c
and it's as you say, process start vs query start ...
OK, so these numbers are OS-level page faults. Can you help me understand
what a page fault on an update would mean? Is it that the disk page
containing some or all of
Hi tom,
It is actually named 'regression'. I spoke with the person who build the server but apparently he is not well worsed in Postgres. He didn't explicitly create 'regression', I guess he selected some default installation options.
I am not sure how to find out what is causing the 'regress
Making the setting in the postgresql.conf file worked after i HUP'd the
postmaster, and logged back into my psql sessions.
timezone = 'EST5EDT'
Thanks a million.
- Ericson
"set local" was probably not what you wanted to use here. Per the man page:
Note that SET LOCAL will appear to have no ef
Ericson Smith <[EMAIL PROTECTED]> writes:
> I realized I made a mistake in that initial email (should have said 12am
> instead of pm). However, I tried:
>>> set local time zone 'EST5EDT';
> SET
>>> select now();
"set local" was probably not what you wanted to use here. Per the man page:
No
Tom Lane wrote:
Ericson Smith <[EMAIL PROTECTED]> writes:
When using date oriented functions on Postgresql, the time is an hour
off, or in certain times, one hour ahead.
System Timezone: EST
System Time (date command): Thu Aug 26 09:44:28 EDT 2004
SELECT now(); : 2004-08-26 08:44:31.307
Ericson Smith <[EMAIL PROTECTED]> writes:
> When using date oriented functions on Postgresql, the time is an hour
> off, or in certain times, one hour ahead.
> System Timezone: EST
> System Time (date command): Thu Aug 26 09:44:28 EDT 2004
> SELECT now(); : 2004-08-26 08:44:31.307343-05
> SELECT
Steve Lane <[EMAIL PROTECTED]> writes:
> I realize no one may have any insight in the whole problem, but can anyone
> at least tell me the significance of each of these numbers from the stats:
> 261/10 [691/281] page faults/reclaims, 0 [0] swaps
It's just repeating what getrusage() told it. See t
On Thu, Aug 26, 2004 at 09:47:26AM -0400, Ericson Smith scratched on the wall:
> Hi,
>
> When using date oriented functions on Postgresql, the time is an hour
> off, or in certain times, one hour ahead.
>
> System Timezone: EST
^^^
> System Time (date command): Thu Aug 26 09:4
Hi,
When using date oriented functions on Postgresql, the time is an hour
off, or in certain times, one hour ahead.
System Timezone: EST
System Time (date command): Thu Aug 26 09:44:28 EDT 2004
SELECT now(); : 2004-08-26 08:44:31.307343-05
SELECT date_part('epoch', '2004-08-26'::timestamp) ; : 10
My odd "double" queries continue. On the theory that I had some kind of
page-faulting issue tied into large, frequent updates of a table, I vacuumed
the whole database and began to watch it closely this morning. Already,
after very little activity, I get this in the log:
2004-08-26 07:01:26 [22056
12 matches
Mail list logo
