unsubscribe pgsql-admin
Sorry, the exact error message is
could not identify operator 184.
I saw it in the syslog error log. At the moment I can't tell what was
going on when it happened.
-Original Message-
From: Michael Fuhr [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 14, 2005 3:27 PM
To: Chris
-Original Message-
From: Michael Fuhr [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 14, 2005 3:27 PM
To: Chris White (cjwhite)
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Error message: cannot identify operator 184
On Thu, Jul 14, 2005 at 01:48:38PM -0700, Chris White
Anybody have any
idea why the error message "cannot identify operator 184" should be output.
Also, what does it mean as to the state of the database, do we need to do
anything to correct a problem?
Chris
Thanks, for the input.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Friday, April 01, 2005 1:49 PM
To: [EMAIL PROTECTED]
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Help understanding VACUUM info on 7.4.5
"Chris
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Friday, April 01, 2005 1:07 PM
To: [EMAIL PROTECTED]
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Help understanding VACUUM info on 7.4.5
"Chris White (cjwhite)" <[EMAIL PROTECTED]> writes:
> Below I have in
Hi,
I am running
Postgres 7.4.5 and am storing binary objects in the largeobject table. We want
to keep the size of the database and especially the large object table to a
minimum, so we vacuum it (not full) on a regular basis. However, what we have
seen is that even after deleting entries
Just checked and found that the checkpoint interval is the same between
7.4.2 and 7.4.5. We also brought up a 7.4.2 version and didn't see these
files being written/updated every 5 minutes. In which module are these files
created?
Chris White
-Original Message-
From: [EMAIL PROT
Thanks for information. We will have to look at the changes we made in
postgresql.conf.
Chris White
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Tuesday, February 22, 2005 3:45 PM
To: [EMAIL PROTECTED]
Cc: pgsql-admin@postgresql.org
10
minutes idle time to spindown so it can recalibrate. This did not happen
when we were running 7.4.2, so does anybody have any idea what may have
changed between 7.4.2 and 7.4.5 to cause this to happen.
TIA
Chris White
---(end of broadcast)---
TIP 8
Thanks for the information.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, January 14, 2005 5:36 PM
To: [EMAIL PROTECTED]
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Limiting size and number of transaction logs
"Chris White (cjwhite)&quo
16MB
files or 3 16MB files.
Is there anyway of
reducing this number of files, as I am running on a system which is very tight
on disk space and doesn't have that much DB transaction throughput that
needs this number of transaction logs or is there a way of making the size
smaller?
This is 7.4.5. I'm not sure I can get it to happen on an empty database, the
database this is happening on has about 300 large objects, but I will try.
Also, I found by re-indexing the pg_largeobject table the problem seems to
have gone away.
Chris White
-Original Message-
From: Tom
does this mean
and how do I resolve the issue? Do I need to re-index the largeobject
table?
Chris
White
Is it possible in
jdbc to use a bytea column in a where clause and compare it to byte[]
object?
Chris
White
Will a DB created
under 7.4.2 work with 7.4.5, or do I need to back it up and restore it to a
newly created 7.5.4 DB?
Chris
White
I am running 7.4.2,
when I try to drop a table it comes back with the message:
relation
"vm-message" has reltriggers = 0
and doesn't drop the
table. What does this mean and how can I really drop the
table?
Chris
White
: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Need help
On Wed, 2004-10-20 at 12:57, Chris White (cjwhite) wrote:
> I am running 7.4.2 and I am seeing a strange error. I am using jdbc to
> update a table with the following statement:
>
> update vm_message set usec
changed
>
> Any body have any ideas?
7.4.2 is know to have index issues. Try reindexing the primary key and
executing the query again.
Sincerely,
Joshua D. Drake
>
> Chris White
--
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programm
tes unique constraint "vm_message_pkey"
I don't understand
why I am getting this message because the primary key for table vm_message is
messageid and this is not being changed
Any body have any
ideas?
Chris
White
Thanks
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 23, 2004 1:38 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Error when dropping table
Tom Lane <[EMAIL PROTECTED]> writes:
> "Chris White (cjwhite)"
PROTECTED]
Subject: Re: [ADMIN] Error when dropping table
"Chris White (cjwhite)" <[EMAIL PROTECTED]> writes:
> On 7.4.2, I am trying to drop a table using the command
> drop table vm_message cascade;
> and I get the error message
> relation "vm_message" h
Title: Message
On 7.4.2, I am
trying to drop a table using the command
drop table
vm_message cascade;
and I get the error
message
relation
"vm_message" has rel_triggers = 0
and the table is not
dropped. What does this message mean and how can I drop the
table?
I am trying to restore tables and associated large objects under 7.4.2.
I created a backup using
pg_dump -U admin -Ft -b aesop > db.tar
When I try to restore it using the following command:
pg_restore -c -d aesop -U admin < db.tar
I get the following message:
pg_restore: [archiver (db)] could
"Chris White (cjwhite)" <[EMAIL PROTECTED]> writes:
> I have done a backup of my 7.4.2 database using pg_dump. When I
> restore the database using the -c option I get the following error
> message and pg_restore fails
> pg_restore: [archiver (db)] could not e
I have just migrated from 7.2.1 to 7.4.2 and I have the following tables
defined in my database.
/* */
/* Table: vm_config */
/* */
create table vm_config
(
Parameter varchar(
nce.
If I do the restore
on a 7.2.1 database I have no problem.
How can I get around
this?
Chris
White
his is the offending data ?
Greg Williamson
DBA
GlobeXplorer LLC
-Original Message-----
From: Chris White (cjwhite) [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 08, 2004 3:44 PM
To: [EMAIL PROTECTED]
Subject: [ADMIN] Problem inserting data into 7.4.2 table
I have just upgraded to 7.4.2
lem? Is it complaining about the value for LastAccessed?
According to the 7.2 User Guide a bigint can have a value between
-92223372036854775808 and 92223372036854775807.
Chris White
---(end of broadcast)---
TIP 2: you can get off all lists at onc
Title: Message
Okay
have found info in documentation and have change locale support to
C.
-Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Chris White (cjwhite)Sent: Thursday, April 08,
2004 10:53 AMTo: [EMAIL PROTECTED]Subject:
[ADMIN
#
locale for number formattinglc_time =
'en_US'
# locale for time formatting
Why am I getting
this error message?
Chris
White
table
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Sorry I meant to say the server terminated the connection as indicated
> by the error message but the server is still running and there is no
> core (This time I enabled them).
Hard to believe there's
, January 29, 2004 7:10 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Error seen when vacuuming pg_largeobject table
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> It happened again. After doing the reindex, I did a vacuum full on the
> pg_largeo
Tom,
It happened again. After doing the reindex, I did a vacuum full on the
pg_largeobject table. This time I did not get the TUPLE INDEX error but
the server terminated at the end of the vacuum command. The backend is
still running even though I get the error message:
aesop=# vacuum full verbose
Sorry no core files. The system is running with cores turned off. Next
time I will turn on cores prior to trying to debug this.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Wednesday, January 28, 2004 11:52 AM
To: [EMAIL PROTECTED]
L PROTECTED]
Subject: Re: [ADMIN] Error seen when vacuuming pg_largeobject table
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Here is the info. I am running 7.2.1.
7.2.1 is a bit long in the tooth; you really ought to be running 7.2.4
if you are still in the 7.2 s
pg_largeobject table
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Here is the info. I am running 7.2.1.
7.2.1 is a bit long in the tooth; you really ought to be running 7.2.4
if you are still in the 7.2 series. However I don't think that has much
to do with your
p=# \q
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, January 26, 2004 5:24 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Error seen when vacuuming pg_largeobject table
"Chris White (cjwhite)" <[EMAIL PROTECTED]> wr
ique index pg_largeobject_loid_pn_index
When I run postgres
with the -P and -O options to reindex the index, everything seem to run okay, I
see no error messages. However, when I restart postmaster and try and do a
vacuum again, I get the same error messages.
What can I do to
correct the problem?
Thanks
Chris
White
erver processes
postmaster: ERROR sql sql sql FATAL
1: The database system is in recovery mode
and from then on any time we try to connect we get
a message saying database is in recovery mode and it never comes out. How can I
recover this database or do I have to restore a prior backup?
Chris
White
Browne
Sent: Wednesday, October 08, 2003 6:22 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
In the last exciting episode, [EMAIL PROTECTED] ("Chris White
(cjwhite)") wrote:
> BTW, the connection I shutdown, had not read, written or deleted any
> large obje
reading/writing or deleting a large object in order for
me to truly reclaim unused space when I issue my periodic vacuum
command.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris White
(cjwhite)
Sent: Tuesday, October 07, 2003 11:09 PM
To:
#x27;; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Okay now I understand what is going on. I have a second thread which
> is being used to read these objects out of the database to present to
> the us
Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> But as you could see from the prior query \lo_list showed no large
> objects, this was done just prior to the vacuum.
> aesop=# \lo_list
&g
To: [EMAIL PROTECTED]
Cc: 'Robert Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Why aren't there any unused tuples?
The "unused" number isn't especially interesting
ACUUM
Again table has grown by 3 pages.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris White
(cjwhite)
Sent: Thursday, October 02, 2003 4:40 PM
To: 'Tom Lane'
Cc: 'Robert Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Questi
occasion entry doesn't get deleted.
Chris
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 3:46 PM
To: [EMAIL PROTECTED]
Cc: 'Robert Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
"Chris White (c
the process, you may get some index
growth issues that will require periodic indexing. HTH,
Robert Treat
* I'm pretty sure those aren't the exact names, but their similar so you
should be able to find them.
On Thu, 2003-10-02 at 14:39, Chris White (cjwhite) wrote:
> Hi,
>
nt in time, if I carry on
repeating this test, I would have to do a vacuum full to retrieve disk
space, even though the actual contents of the database has not increased
from the initial starting point.
Chris White
---(end of broadcast)---
TIP 8: ex
Why not try doing the update and if that fails i.e. returns a value of 0
(no row updated), then do the insert. Thus if your high runner case is
that the entry exists, then you are going to bypass having to test if
the entry exists.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
ids (some using oids of previous
large objects), which made all the references to these oids in the tables
incorrect.
What did I do
wrong?
Chris
White
disk
prior to restoring the database, so I can create the contents list
without reading file twice over ftp link.
Does anybody have any suggestions apart from writing my own custom
backup/restore?
Chris White
---(end of broadcast)---
TIP 7: don&#
only returned a 2K chunk even
though the table entry tells me the entry should be 320K.
Anybody have any
ideas what is the problem? Are there any know issues with the recovery of large
objects?
Chris
White
Found the info in SQL documentation
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Chris White
Sent: Tuesday, April 01, 2003 12:16 PM
To: 'postgres-admin'
Subject: [ADMIN] Documentation for the \lo_export and \lo_import
commands
Where
Sorry, the owner of the database decided to reload the database and we have
lost the duplicate entries. If it happens again I will send you the info.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 01, 2003 12:42 PM
To: Chris White
Cc: [EMAIL
You are correct someone had rebuilt pg_dump, psql and postmaster without
encryption, but forgot to do pg_restore as they thought we would only be
using psql for restoring databases. Sorry about that.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 02, 20
esop_gui=arwdRxt}
(2 rows)
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 01, 2003 12:42 PM
To: Chris White
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Duplicate indexes found in the postgres Database
"Chris White" <[EMAIL PROTECTED
esop_gui=arwdRxt}
(2 rows)
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 01, 2003 12:42 PM
To: Chris White
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Duplicate indexes found in the postgres Database
"Chris White" <[EMAIL PROTECTED
I am trying to run
pg_restore and it tells me it needs libssl, libcrypto, libkrb5 etc. Why does
pg_restore need these libraries when neither pg_dump or postmaster require these
libraries to run. Why is pg_restore requesting encryption libraries and what are
they used for?
Thanks
Chris
ry 01, 2003 9:31 AM
To: Chris White
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Duplicate indexes found in the postgres Database
"Chris White" <[EMAIL PROTECTED]> writes:
> While interrogating the table information for our database, I notice that
> some tables (i.e. gui_con
While interrogating the table information for our database, I notice that
some tables (i.e. gui_config, vm_mailbox, vm_message) have duplicate
entries. Does anybody know why this would occur and is it a problem?
Attached are appropriate outputs. Queries on the tables which are duplicated
in the ent
Hello,
We’re trying to access a database using pgAdmin II. The
database is installed on a Linux server (Red Hat 7.3 PostgreSQL). PgAdmin II is
installed on Windows 2000 Professional.
PgAdmin II shows the database along with
Languages and Schemas. None of the
other database features
62 matches
Mail list logo
