me as a secondary priority.
Any information is appreciated.
Darren
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message ca
Ive been
searching and reading for the last day or so, and cannot find an easy
way to do this without exporting it to an ascii file, then doing a find
and replace in there, and then re-importing it. Can anyone suggest some
way that I could modify it using sql? Thanks much,
Darren
the base/data/db
directory?
Again, any help is appreciated.
Darren
directory exactly what version I was running?
- Original Message -
From: Jay W. Summet <[EMAIL PROTECTED]>
To: Darren Greer <[EMAIL PROTECTED]>
Sent: Tuesday, August 10, 1999 8:48 AM
Subject: Re: [ADMIN] Urgent - Help Needed (Restoriing Data)
> -BEGIN PGP SIGNED MESSAGE-
read by
version 6.3 of PostgreSQL.
Run postgresql-dump to dump the old database and to reload
it in the new format.
The version 6.3 postmaster cannot be started until
this is done.
If PG_VERSION is correct, why does the information above say that it is older?
Darren
e database: template1
Segmentation fault
$
Any thoughts?
Darren
if
something is wrong? Thanks!
Darren
NoI haven't vacuumed in a whilebut this change in speed happened
almost overnight. Is that possible?
Darren
- Original Message -
From: Lamar Owen <[EMAIL PROTECTED]>
To: Darren Greer <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 10, 19
Hello,
I have 2 servers running PostgreSQL 6.5.1 with different databases. Is
it possible to transfer one of the databases from one machine to
another?
I tried pg_dump streamdb > streamdb.pgdump to backup
and cat streamdb.pgdump | psql streamdb to restore
but got the message "Connection to databas
cause it to shift like that. Normall we select this by
no order. Is it safe to select it by the oidas in the oid will NOT
change, even though the order in the database is shifting?
Thanks for any insight.
Darren
, I am wondering if there is a way in which I can specify in the select
statement to retrieve the date as "SQL" (WHich I believe includes the time).
Thanks for any and all help,
Darren
Hello, I recently tried to backup my database(voddb) using the command :
pg_dump voddb > voddb.pgdump
This works all the time previously, but just now, the voddb.pgdump file
created is 0 bytes and cannot be restored. Anyone knows what could be
the problem? Thanks!
the table name and/or attrelid with the one used
to store the attributes. I thought that the relfilenode value might be the
one, but it appears not.
Any help would be greatly appreciated.
Thanks,
Darren
holidayinfo=# SELECT DISTINCT relname FROM pg_stat_user_tables ORDER BY
relname ASC
My end goal is to have maybe 50 million records. Will postgresql handle
this
(with only 1.5GB of RAM) or do I need to look elsewhere for a db of this
size?
Thoughts?
Cheers,
Darren
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Sat, 06 Oct 2007 23:05:23 -0700, "Joshua D. Drake"
<[EMAIL PROTECTED]> said:
> Darren Reed wrote:
> > I'm starting to wonder if my database has finally grown too big for my
> > computer.
> >
> > But, rather than peform badly, I see a number of
Scott Marlowe wrote:
On 10/7/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> Scott Marlowe wrote:
> > ...
> >
> > Any reasonably modern version of pgsql should simply stop accepting
> > requests rather than suffering loss due to txid wraparound.So,I can
> &g
to not forget about them?
The only solution I currently have to (2) is to wipe out the
database (rm -rf) and restore from an earlier dump. I am
slowly getting tired of doing this.
Will upgrading help?
Thanks,
Darren
---(end of broadcast)---
TIP
ase system is ready
LOG: transaction ID wrap limit is 2147484146, limited by database
"postgres"
I'm modifying the work to use BEGIN/COMMIT, but the ifl table worries me...
I can't seem to do anything with it that doesn't cause postgres to crap
out ;(
Darren
Scott Marlowe wrote:
On 10/7/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> Scott Marlowe wrote:
> > On 10/7/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> > > Scott Marlowe wrote:
> A few days ago I did:
> pg_dumpall > foo
> What I was doing yesterday was
Darren Reed wrote:
Scott Marlowe wrote:
On 10/7/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> Scott Marlowe wrote:
> > On 10/7/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> > > Scott Marlowe wrote:
> A few days ago I did:
> pg_dumpall > foo
> What I
emplate1
psql: FATAL: out of memory
DETAIL: Failed on request of size 20.
What puzzles me is why the transaction log hasn't
resulted in postgresql being able to restore itself
to a known clean state.
Darren
---(end of broadcast)---
TIP 3: Have
Darren Reed wrote:
Scott Marlowe wrote:
On 10/7/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> Scott Marlowe wrote:
> > On 10/7/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> > > Scott Marlowe wrote:
> A few days ago I did:
> pg_dumpall > foo
> What I
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
> # /usr/pkg/bin/psql -U postgres template1
> psql: FATAL: out of memory
> DETAIL: Failed on request of size 20.
I'm starting to think there is something very broken about your
machine :-(.
Have you run any hardwa
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
> # /usr/pkg/bin/psql -U postgres template1
> psql: FATAL: out of memory
> DETAIL: Failed on request of size 20.
I'm starting to think there is something very broken about your machine :-(.
Have you run any hardwa
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Anyway, the above error should have also produced a map of per-context
>> memory usage in the postmaster log (ie, postmaster stderr). If you
>> could show us that, it might be revealing.
to a panic due to just random corruption of some kernel data
structure. As it is, everything else seems to be functioning ok.
Darren
---(end of broadcast)---
TIP 6: explain analyze is your friend
Scott Marlowe wrote:
On 10/15/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> Scott Marlowe wrote:
> > ...
> >
> > Again, I'm kinda shooting in the dark here as you reveal more and more
> > what you are doing a little at a time. A test case that can invoke
For better or worse, it seems to be behaving itself again for a while...
There was, however, one change to my procedure and that was to
drop the triggers/functions when restoring the data (using copy into).
Cheers,
Darren
---(end of broadcast
Darren Reed wrote:
For better or worse, it seems to be behaving itself again for a while...
There was, however, one change to my procedure and that was to
drop the triggers/functions when restoring the data (using copy into).
Perhaps I spoke too soon...
# /usr/pkg/bin/pg_dumpall -O -U
ss t ON
(t.oid = i.indexrelid) LEFT JOIN pg_catalog.pg_depend d ON (d.classid =
t.tableoid AND d.objid = t.oid AND d.deptype = 'i') LEFT JOIN
pg_catalog.pg_constraint c ON (d.refclassid = c.tableoid AND d.refobjid
= c.oid) WHERE i.indrelid = '16456'::pg_cata
0004
The error seems to suggest that it is at EOF...
Darren
LOG: startup process (PID 765) was terminated by signal 6
LOG: aborting startup due to startup process failure
LOG: database system was interrupted while in recovery at 2008-02-20
00:44:08 PST
HINT: This probably means that some data
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
> Starting up postgres, I get the log contents below.
> Is it really as bad as it suggests, namely that I
> need to recover from backup?
Probably :-(
I've started a new db in parallel with the old data and I'm
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
> # su postgres -c "/usr/pkg/bin/pg_resetxlog -f /data/db"
> Transaction log reset
> PANIC: could not access status of transaction 4570963
> DETAIL: could not read from file "pg_clog/0004" at offset
16401 of pg_rewrite entry
OID 16403 not found
Is this recoverable without using a backup?
Darren
ERROR: could not open relation with OID 16399
STATEMENT: INSERT INTO table (cola,colb,colc,cold,cole) VALUES
(1,'fred',2,'john',true);
LOG: unexpected EOF on client conn
Tom Lane wrote:
...
There's no info here to suggest exactly what went wrong; Darren, do you
want to fess up to any hardware problems, tripped-over power cords, or
such? What PG version is this anyway?
This is 8.2.6... and I'm starting to believe the hardware is just borked,
with
tract data directly from
the database data files without using postgres?
Are there any caveats in doing so?
Darren
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joinin
Shoaib Mir wrote:
On Tue, Feb 26, 2008 at 5:13 PM, Darren Reed
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
Inserts into my table started generating an error message (see below),
and there was a log message that suggested I reindex.
postgres seems to start
tract data directly from
the database data files without using postgres?
Are there any caveats in doing so?
Darren
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
> Hmmm, from the logfile, signal 11, so it core dumped...
> Of course the default built binary is -O2...
> (gdb) where
> #0 0x082114b8 in RelationCacheInitializePhase2 ()
> #1 0x0821fa67 in InitPostgres ()
> #2 0x
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, if you are really lucky, this is because of a corrupt
>> pg_internal.init file.
> How do I know which files those are?
find $PGDATA -name pg_internal.init
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
>>> How do I know which files those are?
>>
>> find $PGDATA -name pg_internal.init
> Doesn't exist.
Sucks to be you, then :-(
I'm curious though exactly where the failure is, because there
Some minutes after doing a live reindex of all my tables,
I started to get these messages:
ERROR: could not open relation with OID 16461
...for every table(!)
So I shutdown...
LOG: received smart shutdown request
LOG: shutting down
LOG: database system is shut down
And reboot
LOG: dat
Tom Lane wrote:
Darren Reed <[EMAIL PROTECTED]> writes:
> Program terminated with signal 11, Segmentation fault.
> #0 0x0829845c in RelationCacheInitializePhase2 () at relcache.c:2400
> 2400LOAD_CRIT_INDEX(TriggerRelidNameIndexId);
> (gdb) where
&
If there's further interest, I can add more types but the
warning above holds. pg_filedump shouldn't be used for what
the above makes easy but I can't see why that shouldn't be
a decision we (and not the db) gets to make...
Cheers,
Darren
http://coombs.anu.edu.au/~avalo
On Mon, 21 Apr 2008 23:19:48 +0300, "Devrim GÜNDÜZ"
<[EMAIL PROTECTED]> said:
> Hi,
>
> On Mon, 2008-04-21 at 13:51 +0200, Darren Reed wrote:
> > I did a bit of hacking on pg_filedump to make it slightly more
> > useful...but it wasn't clear where
On Wed, 23 Apr 2008 09:20:49 -0400, "Alvaro Herrera"
<[EMAIL PROTECTED]> said:
> Darren Reed wrote:
>
> > I saw this, but when I went in search of activity, there was nothing.
> >
> > Look in:
> > http://sources.redhat.com/ml/rhdb/
> >
Alvaro Herrera wrote:
Darren Reed wrote:
I saw this, but when I went in search of activity, there was nothing.
Look in:
http://sources.redhat.com/ml/rhdb/
http://sources.redhat.com/ml/rhdb-announce/
http://sources.redhat.com/ml/rhdb-cvs/
All of the archives for 2008 are empty...
It
" sets the core dump size to be unlimited, not the
connection count.
That would be related to "ulimit -n" (descriptor count.)
Darren
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
TCP rather than unix streams?
Or is this a bug of the variety that when postgres is deep inside
an UPDATE, doing lots of disk I/O, it never checks to see if it
should abort because the client has gone?
Actually, I can see aborting being a bug too...is there a way to
control the behaviour here?
has been answered several times, but have been
unable to find any post that actually shows how. I would greatly
appreciate it if someone could tell me the steps to solve my dilema.
Thanks in advance,
Darren Greer
QTI - Information Systems
(414)566-7543
[EMAIL PROTECTED]
I would like to thank all those that replied with my problem importing and
exporting into a text field. I will be trying it tonight, and feel quite
confident that all will go well. I will let everyone know how it goes.
Once again Thanks,
Darren Greer
QTI - Information Systems
(414)566-7543
/report to the group
for further information.
Darren Greer
QTI - Information Systems
(414)566-7543
[EMAIL PROTECTED]
52 matches
Mail list logo