[EMAIL PROTECTED] writes:
Francisco,
I just read your mail in the pgsql archives.
I have the same problem:
On my server, pg_dump crashes the backend with a SELECT statement.
I'm using pgsql 8.1 on FreeBSD 6
Did you figure out what could be the cause?
This could be a workaround:
I issued the co
Francisco Reyes <[EMAIL PROTECTED]> writes:
> Should I go with 8.1.4? Since I have to recompile I could install the
> latest. This particular installation has 8.1.3
Sure, use 8.1.4, just be careful not to change any configure options
from what you had.
regards, tom lane
Tom Lane writes:
Unfortunately you're not getting anything very sane, which is a common
result with non-debug-enabled builds. Can you rebuild postgres with
--enable-debug (all other options the same) and try again?
Will do.
Should I go with 8.1.4? Since I have to recompile I could install the
Francisco Reyes <[EMAIL PROTECTED]> writes:
> Trying with gdb.
> Is this what you need?
Unfortunately you're not getting anything very sane, which is a common
result with non-debug-enabled builds. Can you rebuild postgres with
--enable-debug (all other options the same) and try again?
Tom Lane writes:
So pg_dump seems off the hook. Can you run the query, attach to the
backend with gdb, and see what it's doing?
As stated on another message tried a ktrace and got nothing.
Trying with gdb.
Is this what you need?
(gdb) bt
#0 0x0811a0a9 in ExecMakeFunctionResult ()
#1 0x0811
Francisco Reyes <[EMAIL PROTECTED]> writes:
> Going to try the FreeBSD lists to see why and when a process would not
> show up in ktrace. Specially one using 90% cpu.
That's not hard: it's in a loop that doesn't include any kernel calls.
regards, tom lane
---
Tom Lane writes:
Nothing happens when I try to run the query.
So pg_dump seems off the hook. Can you run the query, attach to the
backend with gdb, and see what it's doing?
Tried to set level debug5 to see if any extra output appeared in log.
Nothing.
Going to read up on gdb.. tried ktra
Francisco Reyes <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> SELECT classid, objid, refclassid, refobjid, deptype FROM pg_depend WHERE
>> deptype != 'p' ORDER BY 1,2
>> so apparently something is fishy about the dependency data. Can you
>> execute this query by hand and get results?
> Nothi
Tom Lane writes:
Francisco Reyes <[EMAIL PROTECTED]> writes:
Tom Lane writes:
is the pg_dump or its backend consuming CPU, or just sitting?
At 90% of my CPU.
The pg_dump process, or the backend?
Backend.
pgsql 60769 47.8 1.3 17636 4888 ?? R 11:34AM 761:15.92 postmaster:
pgsql pabl
Francisco Reyes <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> is the pg_dump or its backend consuming CPU, or just sitting?
> At 90% of my CPU.
The pg_dump process, or the backend?
> I have loggin set log_min_messages = info and log_statement = 'all'.
> Right after I start the pg_dump there
Tom Lane writes:
Define "freezes". What happens exactly
doing pg_dump |tee
Shows nothing. This database is not very big so I would expect it to be done
quickly. I tried a couple of other databases and they did the pg_dump
without problems.
is the pg_dump or its backend consuming CPU,
Francisco Reyes <[EMAIL PROTECTED]> writes:
> Trying to pg_dump as superuser or as the database owner, freezes.
Define "freezes". What happens exactly --- is the pg_dump or its
backend consuming CPU, or just sitting? What do ps and pg_stat_activity
and pg_locks show that it's doing?
(I'm specu
This may sound a bit weird, but have you tried logging in as user1 and
then granting the permission's to the superuser?
Simon Kelly
Java Developer
Information Systems Development
Information Technology Shared Services
Ministry of Health
DDI:
Mobile:
http://www.moh.govt.nz
mailto:[EMAIL PROTEC
[EMAIL PROTECTED] writes:
This may sound a bit weird, but have you tried logging in as user1 and
then granting the permission's to the superuser?
Found that superuser could not see them because I had the tables in two
schemas which the superuser did not have path to.
Doing \dt .* I was able
Tom Lane writes:
Francisco Reyes <[EMAIL PROTECTED]> writes:
I have one database owned by "user1" which as of 4 days ago the superuser,
pgsql, can't see any tables.
After furhter researching found that I could not see the tables because I
have them in diferent schemas.. and the superuser di
Francisco Reyes <[EMAIL PROTECTED]> writes:
> I have one database owned by "user1" which as of 4 days ago the superuser,
> pgsql, can't see any tables.
Transaction ID wraparound ... I take it this is not PG 8.1?
As long as it's at least 7.4, vacuuming the system catalogs should help.
16 matches
Mail list logo
