Re: [HACKERS] Is there a way to drop and restore an index?
Tom Lane wrote: See REINDEX. Thanks. -Tony ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] IRIX 6.5.12: POSIX BSD
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 due to the POSIX declaration). There's also a problem with it not
seeing the structure timeval defined. timeval is in
/usr/include/sys/time.h and is declared in the following way:
#if _XOPEN4UX || defined(_BSD_TYPES) || defined(_BSD_COMPAT)
/*
* Structure returned by gettimeofday(2) system call,
* and used in other calls.
* Note this is also defined in sys/resource.h
*/
#ifndef _TIMEVAL_T
#define _TIMEVAL_T
struct timeval {
#if _MIPS_SZLONG == 64
__int32_t :32;
#endif
time_t tv_sec; /* seconds */
long tv_usec; /* and microseconds */
};
So SGI is assuming that you're declaring BSD types or compatibility.
However, the tech support person said that with the compiler's POSIX
declaration, this is conflicting. Basically, she says that POSIX implies
generalized portability across many platforms, but BSD implies a
specific type of platform. So that's where she thinks SGI is having the
trouble-- two conflicting type declarations.
Is this correct?
-Tony
---(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 to the mailing list cleanly
[HACKERS] Followup to IRIX6.5 installation of PG 7.1.1
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 on the SGI). The other SGI (an o2) seems to lose definitions of strdup and timeval and some other structures. On the specific question of strdup, the SGI person told me this: Hi Tony, From my research I came across this: strdup is not part of ISO C, either C 89, C90, C95, or the latest, C99. As a a result, there is no strdup() prototype visible, so the compiler assumes strdup returns an int. An int cannot be transformed to a char * without a cast, so the compiler gives a diagnostic. I noticed in your code string.h is not included. The man page for strdup specifies the inclusion of this header. Please advise. Any comments? -Tony ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Followup to IRIX6.5 installation of PG 7.1.1
Tom Lane wrote: string.h 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 POSIX you will incur a lot of undefined smbols that are not POSIX compliant. You can check the symbols in the POSIX standards. I can't say that I understand this at all, but I believe she is saying that the -D_POSIX_SOURCE flag has caused some function declarations to be hidden from the compiler (?). In any case, since I have a working copy of 7.1.1 for IRIX, I'll leave all of it alone for now as it has gone past my comprehension. SGI has a freeware site with PostgreSQL 7.0.3. I'm sure that they'll figure this out when they try to build 7.1.1 for the site. -Tony ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Installation on SGI IRIX 6.5.10
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 SGI. Everything went fine without any kludgy workarounds. It looks like somehow my compiler/OS has some problems. I'm upgrading to the latest OS version and compiler version. Thanks for the help. -Tony ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Installation on SGI IRIX 6.5.10
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 time.h or sys/time.h, but maybe they keep it
someplace unusual.
In /usr/include/sys/time.h:
#if _XOPEN4UX || defined(_BSD_TYPES) || defined(_BSD_COMPAT)
/*
* Structure returned by gettimeofday(2) system call,
* and used in other calls.
* Note this is also defined in sys/resource.h
*/
#ifndef _TIMEVAL_T
#define _TIMEVAL_T
struct timeval {
#if _MIPS_SZLONG == 64
__int32_t :32;
#endif
time_t tv_sec; /* seconds */
long tv_usec; /* and microseconds */
};
-Tony
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Addition to: Trouble with initdb when the #define NAMEDATALEN = 51
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. However, the initdb started up but then just said that it failed. I have not tried that in awhile, but the last time I did, it worked fine. Are you sure you did a *complete* rebuild? I'd suggest make distclean at the top level, configure, make all, install, initdb. I did a 'gmake clean'. I'll try again today. Perhaps I'll find something that I was overlooking on Friday. -Tony ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Installation on SGI IRIX 6.5.10
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. I can't figure out why this error is showing up. When I looked at the man page for strdup: char *strdup (const char *s1); which is how it looks to be used in async.c. I simply added a specific type-cast: notifyName = (char *) strdup(relname); and it compiled async.c fine (of course, now I'll have to go through some of the other files that also have strdup and change them). I'm going to see if the SGI technical support considers this a bug or not. -Tony ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Installation on SGI IRIX 6.5.10
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 timeval? regards, tom lane In xact.c, I added: #define _BSD_COMPAT 1 before #include sys/time.h It seems to get through that part of the compilation okay now. I'm not sure if that will break anything else but it seems minor. There's a new problem with async.c: cc-1515 cc: ERROR File = async.c, Line = 172 A value of type int cannot be assigned to an entity of type char *. notifyName = strdup(relname); ^ 1 error detected in the compilation of async.c. gmake[3]: *** [async.o] Error 2 gmake[3]: Leaving directory `/usr/src/postgresql-7.1.1/src/backend/commands' gmake[2]: *** [commands-recursive] Error 2 gmake[2]: Leaving directory `/usr/src/postgresql-7.1.1/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/src/postgresql-7.1.1/src' gmake: *** [all] Error 2 It looks like I just need to change the code to explicitly cast the variable. -Tony ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Trouble with initdb when the #define NAMEDATALEN = 51
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 clean and changed the 51 back to 32 and everything went through correctly (make, install, and initdb). Can anyone else verify if this is correct or even makes sense? Thanks. -Tony ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Installation on SGI IRIX 6.5.10
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 $Revision: 1.36 $ ^ cc-1070 cc: ERROR File = xact.c, Line = 696 The indicated type is incomplete. struct timeval delay; ^ 1 error detected in the compilation of xact.c. gmake[4]: *** [xact.o] Error 2 gmake[4]: Leaving directory `/usr/src/postgresql-7.1.1/src/backend/access/transam' gmake[3]: *** [transam-recursive] Error 2 gmake[3]: Leaving directory `/usr/src/postgresql-7.1.1/src/backend/access' gmake[2]: *** [access-recursive] Error 2 gmake[2]: Leaving directory `/usr/src/postgresql-7.1.1/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/src/postgresql-7.1.1/src' gmake: *** [all] Error 2 o21.nsi.edu:postgres::/usr/src/postgresql-7.1.1 I'm using the SGI MIPSPro 7.1 C compiler. I haven't had any problems like this when compiling previous versions of Postgres. If necessary, I could try to get gcc instead of the MIPSPro compiler, but I wonder if the xact.c definition for timeval could be modified to pass on my machine. Thanks. -Tony ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Addition to: Trouble with initdb when the #define NAMEDATALEN = 51
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 51 Everything compiled and installed. However, the initdb started up but then just said that it failed. I did a gmake clean and changed the 51 back to 32 and everything went through correctly (make, install, and initdb). Can anyone else verify if this is correct or even makes sense? Thanks. -Tony ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] 7.1.1
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 [EMAIL PROTECTED])
Re: [HACKERS] pg_dump Backup on 7.0.3 - Sanity error?
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... regards, tom lane Yes. I did delete that user. Thanks Tom. That makes sense. -Tony ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] pg_dump Backup on 7.0.3 - Sanity error?
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_ellipse was not found However, I wasn't even accessing table ro_ellipse. Plus, I've verified that the table does exist and appears fine (I can select data from it). I vacuumed the db and even restarted the postmaster, but I still get this weird warning. Anyone seen this before or know if this is a problem? Thanks. -Tony Postgres 7.0.3 running on RH Linux 6.2 (Zoot), Pentium III/400 MHz, 512 Meg RAM ---(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 to the mailing list cleanly
[HACKERS] Is it possible to mirror the db in Postgres?
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. So, in effect, we'd have 3 copies of the same db. Each copy would be able to update the other. Any thoughts on if this is possible? Thanks. -Tony Reina ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Is it possible to mirror the db in Postgres?
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--yes; equipped--dunno. (3) Yes, probably. Reliable WAN replication is harder. Most of the proprietary database companies will tell you they can do it, but their customers will tell you they can't. Joel Burton suggested the rserv utility. I don't know how well it would work over a wide network. -Tony ---(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 to the mailing list cleanly
Re: [HACKERS] rtrim giving weird result
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, it is
consistent with Oracle).
Is there a way to just remove the "_opto" from the end of the string?
-Tony
---(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 to the mailing list cleanly
[HACKERS] rtrim giving weird result
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 ellipse_opto ex_ellipse_opto figure8_opto ro_ellipse_opto (6 rows) Now I want to return the same thing only with the trailing '_opto' removed: db01=# SELECT rtrim(tablename, '_opto') FROM pg_tables WHERE tablename LIKE '%_opto' AND tablename NOT LIKE 'pg%' ORDER BY tablename ASC ; rtrim center_ou === NOTE: the trailing 't' is missing circles ellipse ex_ellipse figure8 ro_ellipse (6 rows) However, as you can see, the 'center_out' table is missing the last 't'. If I exclude the '_': db01=# SELECT rtrim(tablename, 'opto') FROM pg_tables WHERE tablename LIKE '%_opto' AND tablename NOT LIKE 'pg%' ORDER BY tablename ASC ; rtrim - center_out_ === 't' shows up again circles_ ellipse_ ex_ellipse_ figure8_ ro_ellipse_ (6 rows) The 't' is back. Is there something that I'm doing wrong with my query here? Thanks. -Tony ---(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 to the mailing list cleanly
[HACKERS] ERROR: cannot open relation center_out_analog_proc
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 RedHat Linux (kernel 2.2.14-5). The command that started the problem was from the script: -- Re-arranges the columns in a table -- -- Tony Reina -- Created: 6 March 2001 -- The BEGIN and COMMIT statements ensure that either all statements are done or none are done BEGIN WORK; -- ADD THE NEW COLUMN TO THE TABLE ALTER TABLE center_out_analog_proc ADD COLUMN name text; -- SELECT the columns from the table in whatever new format you wish. Place into a temporary table. SELECT subject, arm, target, rep, channel, name, cut_off_freq, quality, analog_data INTO temp_table FROM center_out_analog_proc; -- DROP THE OLD TABLE DROP TABLE center_out_analog_proc; -- MAKE THE NEW TABLE INTO THE OLD TABLE ALTER TABLE temp_table RENAME TO center_out_analog_proc; -- FILL THE NEW COLUMN WITH THE CORRECT DATA UPDATE center_out_analog_proc SET name = (SELECT name FROM center_out_analog AS a WHERE a.subject = center_out_analog_proc.subject AND a.arm = center_out_analog_proc.arm AND a.target = center_out_analog_proc.target AND a.rep = center_out_analog_proc.rep AND a.channel = center_out_analog_proc.channel); -- VACUUM THE TABLE VACUUM VERBOSE ANALYZE center_out_analog_proc; COMMIT WORK; --- When I ran this, I had an error in the UPDATE command (so the entire transaction aborted). I assumed that becuase the transaction aborted that nothing would have changed in the db. However, after this happened, I corrected the UPDATE command but ran into this error when I re-ran the script: db01=# \i alter_table_format.sql BEGIN psql:alter_table_format.sql:14: NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory psql:alter_table_format.sql:14: NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory psql:alter_table_format.sql:14: NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory psql:alter_table_format.sql:14: NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory psql:alter_table_format.sql:14: ERROR: cannot open relation center_out_analog_proc psql:alter_table_format.sql:17: NOTICE: current transaction is aborted, queries ignored until end of transaction block *ABORT STATE* psql:alter_table_format.sql:20: NOTICE: current transaction is aborted, queries ignored until end of transaction block *ABORT STATE* psql:alter_table_format.sql:26: NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory psql:alter_table_format.sql:26: NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory psql:alter_table_format.sql:26: NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory psql:alter_table_format.sql:26: NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory psql:alter_table_format.sql:26: NOTICE: current transaction is aborted, queries ignored until end of transaction block *ABORT STATE* psql:alter_table_format.sql:29: NOTICE: current transaction is aborted, queries ignored until end of transaction block *ABORT STATE* COMMIT When I try to vacuum the table or the database I get: NOTICE: Pages 190: Changed 0, reaped 0, Empty 0, New 0; Tup 9280: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 652, MaxLen 652; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.07s/0.14u sec. NOTICE: --Relation circles_analog_proc -- NOTICE: Pages 187: Changed 0, reaped 0, Empty 0, New 0; Tup 9140: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 652, MaxLen 652; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.08s/0.13u sec. NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory NOTICE: RelationIdBuildRelation: smgropen(center_out_analog_proc): No such file or directory NOTICE: --Relation center_out_analog_proc -- NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory ERROR: cannot open relation center_out_analog_proc db01=# select distinct monkey from center_out_analog_proc; NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory ERROR: cannot open relation center_out_analog_proc Likewise, a select gives me: db01=# select distinct arm from center_out_analog_proc; NOTICE: mdopen: couldn't open center_out_analog_proc: No such file or directory NOTICE: mdopen: couldn't open center_out_analog_proc:
Re: [HACKERS] ERROR: cannot open relation center_out_analog_proc
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 to clean up at this point is to drop the table for real. Okay, so then you are saying that even though the DROP TABLE and ALTER TABLE RENAME went through correctly, the line after that bombed out, tried to rollback the transaction, and gave me the error? I definitely missed that warning. Are there any big warnings for things that don't work so well within a transaction (BEGIN WORK; COMMIT WORK)? Thanks. Off to rebuild a table. -Tony ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Patches with vacuum fixes available for 7.0.x
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 manual update. Thanks. -Tony Reina There's three patchsets and they are available at: http://people.freebsd.org/~alfred/vacfix/ complete diff: http://people.freebsd.org/~alfred/vacfix/v.diff only lazy vacuum option to speed up index vacuums: http://people.freebsd.org/~alfred/vacfix/vlazy.tgz only lazy vacuum option to only scan from start of modified data: http://people.freebsd.org/~alfred/vacfix/mnmb.tgz
[HACKERS] Weird backup file
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 from
'G' to 'F' in the names column, I seem to lose the column called
'dsp_chan'. Second, the double quotes around the float_4 array called
'spike_hist' aren't included.
I'm not sure if the double quotes are necessary, but the missing column
is probably a problem. I added this column after the database was
created by using 'alter table ellipse_cell_proc add column dsp_chan' and
then put it in the correct position by using:
SELECT name, arm, rep, cycle, hemisphere, area, cell, dsp_chan,
spike_hist INTO xxx FROM ellipse_cell_proc;
DROP TABLE ellipse_cell_proc;
ALTER TABLE xxx RENAME TO ellipse_cell_proc;
Can anyone explain what went wrong with the backup or where I erred
adding the column?
Thanks.
-Tony
\connect - postgres
CREATE TABLE "ellipse_cell_proc" (
"name" text,
"arm" character,
"rep" int4,
"cycle" int4,
"hemisphere" character,
"area" text,
"cell" int4,
"dsp_chan" text,
"spike_hist" "_float4"
);
COPY "ellipse_cell_proc" FROM stdin;
I L 888 2 R 4 173 1
{"0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0"}
I L 888 3 R 4 173 1
{"0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0"}
I L 888 4 R 4 173 1
{"0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0"}
I L 888 5 R 4 173 1
{"0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0"}
G R 5 2 L 4 1 1
{"1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.1","1.6","43.9","29.4","36.3","30.4","14","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","2.2","7","30.3","47.5","48.5","48.2","33.9","35.6","37.8","29.6","23.3","43.7","21.3","26.6","44","39.6","35.5","35.6","46.6","41.6","43","42.1","25.7","22.7","22.7","22.1","21.3","21.9","22.2","36","26.8","29.2","30.6","21.3","22.8","24.4","9","7.6","7.6","7.6","7.6","2","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","1.4","13.3","20.4","8.1","3.9","3.9","3.9","3.9","3.9","3.9","3.9","3.9","3.9","39","10","10","10","15.9","30.5"}
G R 5 3 L 4 1 1
[HACKERS] Still having problems with DIGEST
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. -Tony
[HACKERS] [Fwd: Weird backup file]
I sent this e-mail last week but hadn't received any response. Given
Thomas' last message about seeing responses to threads he never recalled
seeing in the first place, I'm wondering whether the original message
made it to the server.
-Tony
p.s. I still can't seem to get 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: The Neurosciences Institute
To: "[EMAIL PROTECTED]"
[EMAIL PROTECTED],[EMAIL PROTECTED]
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 from
'G' to 'F' in the names column, I seem to lose the column called
'dsp_chan'. Second, the double quotes around the float_4 array called
'spike_hist' aren't included.
I'm not sure if the double quotes are necessary, but the missing column
is probably a problem. I added this column after the database was
created by using 'alter table ellipse_cell_proc add column dsp_chan' and
then put it in the correct position by using:
SELECT name, arm, rep, cycle, hemisphere, area, cell, dsp_chan,
spike_hist INTO xxx FROM ellipse_cell_proc;
DROP TABLE ellipse_cell_proc;
ALTER TABLE xxx RENAME TO ellipse_cell_proc;
Can anyone explain what went wrong with the backup or where I erred
adding the column?
Thanks.
-Tony
\connect - postgres
CREATE TABLE "ellipse_cell_proc" (
"name" text,
"arm" character,
"rep" int4,
"cycle" int4,
"hemisphere" character,
"area" text,
"cell" int4,
"dsp_chan" text,
"spike_hist" "_float4"
);
COPY "ellipse_cell_proc" FROM stdin;
I L 888 2 R 4 173 1
{"0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0.4","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0"}
I L 888 3 R 4 173 1
{"0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0","0",&q
Re: [HACKERS] [Fwd: Weird backup file]
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 exact mechanism, but I have a suspicion: it looks a lot like some blocks of the original ellipse_cell_proc table got written into the new table. I know 6.5 failed to clear old shared disk buffers during a table rename. I can't recall if it was sloppy about that during a table drop as well, but it would've taken both bugs to cause this result if I'm guessing right that that was the failure path. There are good reasons why we've been urging people to update to 7.0.* ASAP ... I'm afraid you got bit by one :-(. Sorry about that. Okay. At least the problem has been solved. It seems though that the last 2 times I've done a backup (in order to upgrade to the latest Postgres version) I've had data lost because of some error. I'm getting a little concerned about the quality of the Postgres backups. -Tony
[HACKERS] PostgreSQL 7.0.3?
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
