Tom Lane wrote:
> See REINDEX.
>
Thanks.
-Tony
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
I've been going talking with the SGI technical support about some of the
errors I got when compiling Postgres 7.1.1 on SGI IRIX 6.5.12 with the
MIPSPro 7.3 C compiler. I've already mentioned that somehow the compiler
can't see the correct definition for strdup (I believe she thought that
it was du
Tom Lane wrote:
> is included in every Postgres source file (via c.h).
>
Yep. That's what I expected.
SGI technical support seems to think that the problem is with the POSIX flag.
" Have you defined any POSIX variables, such as -D_POSIX_SOURCE
or included pthread.h? When you enable POSI
I've been talking with SGI tech support about my problem with installing
Postgres 7.1.1 on the SGI (IRIX 6.5.12 using the MIPSPro 7.3 compiler).
Fortunately, one of my SGI's (an octane) built PG without any problem so
this is just academic now (but probably useful for others wanting to
install PG
Tom Lane wrote:
>
> That absolutely should NOT be necessary; there should be a proper
> extern declaration of strdup visible. Perhaps it should be added
> to include/port/irix5.h (cf port/nextstep.h).
>
> regards, tom lane
Just to make sure, I tried compiling on another
Tom Lane wrote:
> > #if _XOPEN4UX || defined(_BSD_TYPES) || defined(_BSD_COMPAT)
>
> Next thought is that maybe none of these control symbols are defined
> by default --- could you look into that possibility? Perhaps some
> compiler switches or #defines are needed to get IRIX to allow
> "struct
Tom Lane wrote:
> Evidently IRIX also considers strdup() to be nonstandard :-(
>
> It's hard to believe that SGI is quite this braindead. I think there is
> something broken about configure on your setup. Can't tell what from
> here --- suggest you call in some IRIX gurus.
>
Yep. So goes SGI.
Tom Lane wrote:
> "G. Anthony Reina" <[EMAIL PROTECTED]> writes:
> >> In postgres_ext.h, I changed:
> >>
> >> #define NAMEDATALEN 32
> >> to
> >> #define NAMEDATALEN 51
> >>
> >> Everything compiled and installed.
Tom Lane wrote:
> > cc-1070 cc: ERROR File = xact.c, Line = 696
> > The indicated type is incomplete.
>
> > struct timeval delay;
> >^
>
> Hm. Which system header file defines struct timeval on IRIX?
> I'd expect or , but maybe t
Sorry, I forgot to include that I'm compiling this on RedHat 6.2,
Pentium III with Postgres 7.1.1.
-Tony
> I'm not sure if this is still needed in postgres to define the length of
> a variable/table name.
>
> In postgres_ext.h, I changed:
>
> #define NAMEDATALEN 32
> to
> #define NAMEDATALEN 5
In addition to my RedHat 6.2 server, I'm installing Postgres 7.1.1 on an
SGI O2 (IRIX 6.5.10). The configure works, but the 'gmake all' fails
when it tries to compile 'xact.c':
cc-1521 cc: WARNING File = /usr/include/setjmp.h, Line = 26
A nonstandard preprocessing directive is used.
#ident "
I'm not sure if this is still needed in postgres to define the length of
a variable/table name.
In postgres_ext.h, I changed:
#define NAMEDATALEN 32
to
#define NAMEDATALEN 51
Everything compiled and installed. However, the initdb started up but
then just said that it failed.
I did a gmake clea
I see by the messages that 7.1.1 is in the final packaging. Anyone know
when it will be released?
-Tony
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [
Tom Lane wrote:
> Most likely, you removed the user that owned ro_ellipse. Create a
> user with the same usesysid shown as ro_ellipse's relowner, or else
> change the relowner field to point at an extant user.
>
> I believe 7.1's pg_dump copes with this sort of thing more gracefully...
>
>
I'm trying to use pg_dump to backup my tables one at a time from
Postgres 7.0.3 (I'll upgrade to 7.1 in a few weeks). I'm getting a
strange error that I've never encountered before.
The backup call is:pg_dump db01 -t cell | gzip > cell.backup.gz
The error is : failed sanity check, table ro_
Nathan Meyers wrote:
> Does the replication have to be reliable? Are you equipped to
> reconcile databases that have got out of sync, if not? Will the
> different labs ever try to update the same existing record, or
> insert conflicting (unique-key) records?
>
(1) Yes, of course. (2) Willing-
We use Postgres 7.0.3 to store data for our scientific research. We have
two other labs in St. Louis, MO and Tempe, AZ. I'd like to see if
there's a way for them to mirror our database. They would be able to
update our database when they received new results and we would be able
to update theirs.
Ken Hirsch wrote:
> So rtrim("center_out_opto", "_opto") returns
> "center_ou"
> because "u" is not in the set {o, p, t, _} but all the characters after it
> are.
> rtrim("center_out_opto", "pot_") will produce the same thing.
>
That seems like an odd definition (although as Tom points out,
I'm running Postgres 7.0.3 on a RedHat Linux 6.1. For some reason, rtrim
is giving me an incorrect result:
db01=# SELECT tablename FROM pg_tables WHERE tablename LIKE '%_opto' AND
tablename NOT LIKE 'pg%' ORDER BY tablename ASC ;
tablename
-
center_out_opto
circles_opto
e
Tom Lane wrote:
> You can't roll back a DROP TABLE under pre-7.1 releases (and 7.0 has
> a big fat warning notice to tell you so!). The physical table file
> is deleted immediately by the DROP, so rolling back the system catalog
> changes doesn't get you back to a working table.
>
> The only way
I was trying to add a column to a table and fill it but ran into a big
error. Apparently now Postgres can't open this table to vacuum or to
select although it does show up when I ask psql to describe the table
(i.e. db01=# /d center_out_analog_proc).
I'm using Postgres 7.0.3 on a PII/400 MHz with
Alfred,
Is there a tarbar with the updated files for the vacuum patch? Or,
is there some way to use the 'v.diff' file without the need to modify
the files by hand? I started changing the files by hand, but realized
that there is so much information that I'm bound to make a mistake in
the manu
I backed up my database from Postgres 6.5.3 and migrated to 7.0.2
several a few months ago. For some reason, data was lost in the
transition. I've finally pinned it down to the attached file (abridged
to point out the problem).
It looks like two things happened in the backup. First, when I move f
I've subscribed and un-subscribed to the HACKERS-DIGEST list several
times now. Each time I seem to be getting EVERY message sent to the list
rather than a DIGEST.
Can someone tell me if it is still possible to get a DIGEST of the list?
Is the list administrator aware of the problem?
Thanks.
-To
Tom Lane wrote:
> Your procedure was fine, but ALTER TABLE RENAME was mighty flaky in
> pre-7.0 releases. Even in 7.0, doing it inside a transaction block is
> asking for trouble (that's finally fixed for 7.1, thank goodness).
> I suspect you got bit by an ALTER bug. I'm not sure about the exac
the "DIGEST" to work on HACKERS. Seems to
be some problems with the majordomo.
Here's my original message:
Original Message
Subject: Weird backup file
Date: Fri, 17 Nov 2000 11:27:32 -0800
From: "G. Anthony Reina" <[EMAIL PROTECTED]>
Organization
I remember a post about 2 weeks back concerning a new patch that was to
be introduced as 7.0.3. I haven't seen any reference to this since then.
Is this still happening, or will the patch be part of 7.1?
-Tony Reina
27 matches
Mail list logo
