Hello,
I had a problem in my computer system yesterday. Some data has
disappeared. I was looking for a program that might have deleted it
accidentally. Before I found anything, the data suddenly came back. I
thought it must be a transaction id wraparound problem.
The system is running on F
Jim Nasby írta:
Autovacuum doesn't launch a separate daemon; you'll only see an
autovac process when an autovac is actually working.
Where should I see it? The output of "ps ax | grep auto" is empty. Does
it mean that auto vacuum is not running? How can I check if there is a
problem?
Also, 8.
Hi All,
I tried to follow the instructions that are described here:
http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html#SHARED-MEMORY-PARAMETERS
http://www.postgresql.org/docs/8.1/interactive/kernel-resources.html#SYSVIPC
My values config are:
page size = 4096
BLCKSZ = 8
max
Peter Koczan wrote:
Minimum shared mem: 140731400 bytes = 135.0 MB
Maximum shared mem: 268435456 bytes = 256.0 MB
kern.ipc.shmmin="140731400"
kern.ipc.shmmax="268435456"
Nov 13 20:46:19 neptunus postgres[669]: [1-2] DETAIL: Failed system
call was shmget(key=5432001, size=21725184, 03600).
Steve Holdoway wrote:
On Tue, 13 Nov 2007 21:00:02 +0100
Laszlo Nagy <[EMAIL PROTECTED]> wrote:
[snip]
What are postgres's ulimits???
Output of "cat /etc/login.conf" (part of it):
default:\
:passwd_format=md5:\
:copyright=/etc/COPYRIGHT:\
Hello,
I've been reading previous posts and I think I have some tables in my
database that would better be stored with fillfactor=90 or less. We are
going to upgrade and reinstall our server soon. I thought this would be
a good time to change fillfactor. Just I don't know how. First I need to
Tom Lane wrote:
Huh, that's weird. We've fixed some bugs in the past that led the stats
collector to consume excessive CPU --- but that was all pre-8.3.
The server was rebooting intermittently, so we replaced the RAM (we got
a kernel page fault). But it was a week ago. The server is now st
Tom Lane wrote:
Laszlo Nagy <[EMAIL PROTECTED]> writes:
The processi is using 100% CPU for 52 hours! Here it is:
%ps axl | grep 677
70 677 666 757 107 0 22396 5460 select Rs?? 3144:50.88
postgres: stats collector process(postgres)
Huh, that's we
This is what I see in "top" since two days:
last pid: 95702; load averages: 2.48, 2.69,
2.75
up 3+02:08:49 10:27:58
257 processes: 3 running, 246 sleeping, 8 zombie
CPU states: 15.5% user, 0.0% nice, 22.1% sy
The collector is pretty self-contained by design, so it's hard to see
what else would affect it. I'm wondering a bit if the OP's hardware is
still flaky :-(. In any case it would sure be interesting to see a few
stack traces from the process.
Maybe it is still flaky, because yesterday it re
PostgreSQL 8.3.5, the system is now stable (uptime > 10 days).
PostgreSQL stats collector uses 100% CPU forever:
On Thursday:
last pid: 29509; load averages: 2.36, 2.01,
2.03
up 5+17:28:56 04:02:53
196 proce
Alvaro Herrera wrote:
Laszlo Nagy wrote:
PostgreSQL 8.3.5, the system is now stable (uptime > 10 days).
PostgreSQL stats collector uses 100% CPU forever:
Could you grab a few stack traces from it and post them? Also possibly
useful, leave strace running on the pgstat process fo
It was 78816 and you traced 78815? Are you sure the process with 24h of
CPU was pgstat?
I'm sorry that was a typo. Of course I traced the good process (proof is
that at the end it renamed a file to "global/pgstat.stat".
And yes, "top" showed 24H in the TIME column and 99% in the WCPU colu
OK, here is the new test.
shopzeus# ps l -p 39766 -p 39767 -p 39769
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
70 39766 78806 0 96 0 451960 423896 select Ss??8:41.85
postgres: writer process(postgres)
70 39767 78806 0 96 0 451960 7184 sele
and see if its output changes when you start to trace it.
%cat test.c
#include
int main() {
while(1) {
sleep(5);
printf("ppid = %d\n", getppid());
}
}
%gcc -o test test.c
%./test
ppid = 47653
ppid = 47653
ppid = 47653 # Started "truss -p 48864" here!
ppid = 49073
ppid
Tom Lane wrote:
Alvaro Herrera writes:
Tom Lane wrote:
I wonder whether your tracing tool is affecting the result of
getppid(). Most people would consider that a bug in the tracing tool.
I wrote to an official the FreeBSD list about this getppid() problem but
got no answe
alive". Otherwise you'll have trouble with the collector not stopping
when you want it to. Look into src/backend/storage/ipc/pmsignal.c:
- return (getppid() == PostmasterPid);
+ return (getppid() != 1);
(Obviously this is a hack, but it should work on any Unixish
Laszlo Nagy írta:
alive". Otherwise you'll have trouble with the collector not stopping
when you want it to. Look into src/backend/storage/ipc/pmsignal.c:
-return (getppid() == PostmasterPid);
+return (getppid() != 1);
(Obviously this is a hack, but it should w
select abbrev,utc_offset,count(*) from pg_timezone_names
where abbrev='EST'
group by abbrev,utc_offset
There are 12 times zones with 'EST' code, offset = GMT+10. And there are
8 time zones with 'EST' code, offset= GMT+5 at the same time!
So how much it is supposed to be?
select now() at time
Then you can do:
select *
from retrieve_user('foo', 'bar');
Personally I'd prefer to create view that wraps that select statement
and then simply do a
select *
from user_view
where name = 'foo'
and password = 'bar'
It is also better because with a view, you can also d
Isn't:
select now() at time zone 'Australia/ATC'
supposed to be:
select now() at time zone 'Australia/ACT'
I see now. The abbreviation is usually a time zone name. But to be
correct, the time zone name should be used (and not the abbreviation).
And looking at the pg_timezone_names table f
On 2012-08-03 10:31, Laszlo Nagy wrote:
select abbrev,utc_offset,count(*) from pg_timezone_names
where abbrev='EST'
group by abbrev,utc_offset
There are 12 times zones with 'EST' code, offset = GMT+10. And there
are 8 time zones with 'EST' code, offset= GMT+5 at
Here is a better example that shows what I actually have in my database.
Suppose I have this table, with UTC timestamps in it:
template1=> create table test ( a timestamptz not null primary key );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"test_pkey" for table "test"
CREA
On 2012-08-03 16:19, Tom Lane wrote:
Laszlo Nagy writes:
So how do I create a query that results in something like:
a
--
Sun Oct 30 02:00:00 2011 +0500
Sun Oct 30 02:00:00 2011 +0600
(2 rows)
Set the "timezone" setting to the zone y
You could store the zone in a separate field and then create a VIEW on
the table that used a function to take both values and return the
timestamptz just as it was inserted.
Well no, it is not possible. A timestamptz value is interpreted as UTC,
regardless of your local timezone. A timestam
2012.08.03. 18:38 keltezéssel, Tom Lane írta:
Laszlo Nagy writes:
I have intentionally chosen an example where the local time is changed
from summer time to winter time (e.g. local time suddenly "goes back"
one hour). It demonstrates that you cannot use "at time zone
> [ shrug... ] If you really insist on re-inventing that wheel, go
ahead, but it sounds to me like you'll just be introducing additional
points of failure. regards, tom lane
I just checked some programming languages (Python, C#), and the same
problem exists there. All of them say that "when th
On 2012-08-12 23:13, Richard Harper wrote:
Thanks for the help (server not running). The server is running and
accepting connections, but when I attempt a tcp/ip connection I get
the message: FATAL: database "d3_jchem" does not exist
I can connect using psql. I seems not to be finding the dat
On 2012-08-13 16:18, Richard Harper wrote:
All of the databases appear to be where they should be. As an
experiment, I tried tcp/ip to the 'posgres' database. That worked.
Thanks to Ray, I worked that out. Per the suggestion I tried:
psql -h 127.0.0.1 -d d3_jchem. It connected after request
29 matches
Mail list logo
