Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 5:50 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: I don't touch pg_class at all... this is what I'm doing (over and over again). -- clone_table is almost always a no-op, but once a day it creates a new table SELECT c

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 4:33 PM, Alvaro Herrera wrote: Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: On Nov 21, 2005, at 3:56 PM, Tom Lane wrote: Well, I count at least a couple hundred deleted versions of that table row :-(. What the heck were you doing with it? T

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 3:56 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: Sure, here it is: http://undefined.org/mochi.pg_class-1.filedump.gz Well, I count at least a couple hundred deleted versions of that table row :-(. What the heck were you doing with it? As far as

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 3:12 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: Ok, here's the pg_filedump for the pg_class table in the mochi database that is having the issue: Thanks. I don't see any live tuples that look like they could have been the one we wan

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 2:42 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: Ok, so how do I figure out which file(s) are associated with pg_class so I can feed this thing? See contrib/oid2name and/or read http://www.postgresql.org/docs/8.1/static/storage.html Ok, here

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 1:59 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: The attributes look like the names of all the columns in the table, and reindexing didn't help. So at this point it seems that the pg_class row disappeared, but there probably wasn't

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 1:43 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: I don't know how to get the oid of a type.. but there are certainly entries in pg_depend with the other criteria: Hmph, looks like you still have a pretty full set of dependencies for the t

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 1:14 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: On Nov 21, 2005, at 12:44 PM, Tom Lane wrote: Try dropping the type. I did try that, I guess it didn't make it to the list yet: mochi=# drop type ping_1132387200; ERROR: cache lookup

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 11:31 AM, Bob Ippolito wrote: I've been running 8.1.0 on a test box since the FreeBSD port has been available, and it appears that the catalog has become corrupted. There's plenty of free space on all volumes, so it hasn't run out of space or anythin

Re: [HACKERS] PostgreSQL 8.1.0 catalog corruption

On Nov 21, 2005, at 12:44 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: mochi=# drop table ping_1132387200; ERROR: table "ping_1132387200" does not exist mochi=# create table ping_1132387200(); ERROR: type "ping_1132387200" already exists I'm

[HACKERS] PostgreSQL 8.1.0 catalog corruption

I've been running 8.1.0 on a test box since the FreeBSD port has been available, and it appears that the catalog has become corrupted. There's plenty of free space on all volumes, so it hasn't run out of space or anything. $ uname -a FreeBSD shi.mochibot.com 6.0-RELEASE FreeBSD 6.0-RELEASE

Re: [HACKERS] uuid type for postgres

One reason to use a UUID type over a naively stored hash for this purpose is that it takes up half the space as naively stored MD5 and 40% of the space as naively stored SHA1.  Granted, it's easy enough to pack them, but packed MD5 does have the same storage requirements as UUID and it won't be qui

Re: [HACKERS] uuid type for postgres

On Sep 7, 2005, at 10:04 AM, nathan wagner wrote: On Wed, Sep 07, 2005 at 09:45:17AM -0700, josh@agliodbs.com wrote: I think the issue is portability. Remember that this type needs to work on Windows as well as all POSIX platforms and AIX. I had forgotten about windows. I'll see to wha

Re: [HACKERS] uuid type for postgres

On Sep 6, 2005, at 6:02 PM, Josh Berkus wrote: Bob, People, Let me clarify my stance here, because it seems to be getting misrepresented. Mark (and Nathan) pushed at repaired UUID type for possible inclusion in the core PostgreSQL distribution. I'm not opposed to that, provided that the

Re: [HACKERS] uuid type for postgres

On Sep 6, 2005, at 3:06 PM, [EMAIL PROTECTED] wrote: On Tue, Sep 06, 2005 at 05:54:34PM -0400, Tom Lane wrote: I don't see any "big opposition". People are simply questioning the idea whether it belongs in core PG. The reason we don't want to accept everything-and-the-kitchen-sink in cor

Re: [HACKERS] uuid type for postgres

On Sep 6, 2005, at 2:16 PM, nathan wagner wrote: On Tue, Sep 06, 2005 at 03:57:55PM -0400, [EMAIL PROTECTED] wrote: I agree with Josh on the UUID type, it gets abused far too often Out of curiosity, how does it get abused? It doesn't seem to me that it would be any more prone to abuse t

Re: [HACKERS] uuid type for postgres

On Sep 6, 2005, at 12:57 PM, Jonah H. Harris wrote:On 9/6/05, Josh Berkus wrote: Mark,> I suggest that UUID be recommended in place of SERIAL for certain> classes of applications, and that it therefore belongs in the core.> UUID and SERIAL can be used together (although, once yo

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

On Nov 8, 2003, at 3:19 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: * I ditched the system.c hack, assuming Apple has fixed them by 10.3 -- because it breaks tcl and python if you do.. I did: After fixing the ps_status problems, I cannot observe any problem, with or w

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

On Nov 8, 2003, at 1:44 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: On Nov 8, 2003, at 1:13 PM, Tom Lane wrote: As for getting rid of system.c, I am not eager to do that since it would certainly break compatibility with OS X 10.1. We could conditionally compile it out p

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

On Nov 8, 2003, at 1:13 PM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: On Nov 8, 2003, at 12:31 AM, Tom Lane wrote: I have just in the past couple hours realized that ps_status.c is seriously broken on OS X 10.3. Er... I meant memcmp.. Have you tried removing the system.

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

On Nov 8, 2003, at 1:00 AM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: On Nov 8, 2003, at 12:31 AM, Tom Lane wrote: I have just in the past couple hours realized that ps_status.c is seriously broken on OS X 10.3. It appears that Apple has randomly decided to start #define&#x

Re: [HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

On Nov 8, 2003, at 12:31 AM, Tom Lane wrote: Bob Ippolito <[EMAIL PROTECTED]> writes: Here's my notes on how to build PostgreSQL 7.4 (CVS) on OS X 10.3 (7B85) with (seems to be working, but I haven't really ran any tests) python, tcl, perl, readline. I have just in the past coupl

[HACKERS] Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)

Here's my notes on how to build PostgreSQL 7.4 (CVS) on OS X 10.3 (7B85) with (seems to be working, but I haven't really ran any tests) python, tcl, perl, readline. I noticed today that you guys are just about to release, so I figure I should bring this up right now. Please feel free to e

[HACKERS] problem with creating/dropping tables and plpgsql ?

nction, and a few other things.. no luck. Does anyone have ANY idea how I can either redesign this query or make the create/drop thing work properly? Thanks, (::) Bob Ippolito ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please