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 couple hours realized
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'ing BSD
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.c hack
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 perhaps. Do
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 without
the create/drop thing work properly?
Thanks,
(::) Bob Ippolito
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through
On Sep 6, 2005, at 12:57 PM, Jonah H. Harris wrote:On 9/6/05, Josh Berkus josh@agliodbs.com 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 you
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
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 core
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
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
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
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
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 not sure what to do about
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 anything.
$ uname
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 failed
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 table. What about
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 any actual DROP
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's
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 want, but there's
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 I can
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?
The ETL process
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 clone_table('ping
23 matches
Mail list logo
