[BUGS] BUG #1013: Authentication doesn't work
The following bug has been logged online: Bug reference: 1013 Logged by: Keith Hankin Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Fedora Linux Description:Authentication doesn't work Details: When I start up psql, if I am not not logged in as the owner of the database, I get the following error message, even if I type the correct password: psql: FATAL: IDENT authentication failed for user "keith" However, when I start up psql logged in as the owner of the database, I get a proper login regardless of whether I type the proper password or not. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] SELECT FOR UPDATE differs inside and outside a pl/pgsql
On Wed, 2003-12-17 at 19:57, Tom Lane wrote: > Mark Shewmaker <[EMAIL PROTECTED]> writes: > > If a "FOR UPDATE executes before LIMIT" rule stopped the function > > from ever locking a row, it's still curious why didn't it stop the > > direct command from ever locking a row as well. > > I think it would. Did you try the test the other way around (with the > direct command being blocked behind someone who deletes the first row)? Yes, or at least I've done the test that I think you're asking about. (See Session_A-with-early-delete occurring with Session B_1 below.) To be as clear as possible as to the actual tests run: +-+---+ |Run this in psql:| Along with one of these in a second psql session: | +-+-+-+---+ | Session A | Session B_1 | Session B_2 | Session B_3 | +-+-+-+---+ | | | | | | # begin | | | | | transaction | | | | | | | | | | | # begin | # begin | # begin | | | transaction; | transaction | transaction | | | | | | | # select * from | | | | | mytable limit | | | | | 1 for update; | | | | | (returns a=1) | | | | | | | | | |(NOTE: if the| | | | |following delete | | | | |statement is | | | | |moved here,before| | | | |session B_?'s| | | | |selects, it has | | | | |no effect on | | | | |session B_?'s| | | | |hangs & results) | | | | | | | | | | | # select * from | # select| # select | | | mytable limit | myfunction(); | myfunction2(); | | 1 for update; | (hangs) | (hangs) | | | (hangs) | (hangs) | (hangs) | | # delete from | (hangs) | (hangs) | (hangs) | | mytable where | (hangs) | (hangs) | (hangs) | | a=1; | (hangs) | (hangs) | (hangs) | | (succeeds with | (hangs) | (hangs) | (hangs) | | "DELETE 1") | (hangs) | (hangs) | (hangs) | | | (hangs) | (hangs) | (hangs) | | # commit; | (hangs) | (hangs) | (hangs) | | (succeeds with | (hangs) | (hangs) | (hangs) | | "COMMIT") | (hangs) | (hangs) | (hangs) | | | (returns with | (hangs) | (returns with | | | no rows)| (hangs) | a=2) | | | | (hangs) | | | | # select * from | (hangs) | # delete from | | | mytable limit | (hangs) | mytable | | | 1 for update; | (hangs) | where a=2; | | | (returns with | (hangs) | (succeeds with| | | a=2)| (hangs) | "DELETE 1") | | | | (hangs) | | | | # delete from | (hangs) | # commit; | | | mytable where | (hangs) | (succeeds with| | | a=2; | (hangs) | "COMMIT") | | | (succeeds with | (hangs) | | | | "DELETE 1") | (hangs) | | | | | (hangs) | | | | # commit; | (hangs) | | | | (succeeds with | (hangs) | | | | "COMMIT") | (hangs) | | | | | (hangs) | | +-+-+-+---+ | Before each test: # delete from my
[BUGS] Urgent: Key constraints behaving weirdly
Your name : Russ Garrett Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : P4 Xeon Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.22 ELF PostgreSQL version (example: PostgreSQL-7.4) : PostgreSQL-7.4 Compiler used (example: gcc 2.95.2) : gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Please enter a FULL description of your problem: Constraints are being weird. The reproduction instructions speak for themselves. We're using this on a production database and we're understandably getting a bit edgy. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- last=> \d profile ... Indexes: "profile_pkey" primary key, btree (id) last=> \di+ profile_pkey List of relations Schema | Name | Type | Owner | Description | Table +--+---++-+- public | profile_pkey | index | lastfm | | profile (1 row) last=> UPDATE profile SET lastsongtime=now(), r1=r1+0, r2=r2+0, r3=r3+0, r4=r4+0, r5=r5+0, scrobcount=scrobcount+1 WHERE id=1017057; ERROR: duplicate key violates unique constraint "profile_pkey" last=> SELECT * FROM profile WHERE id=1017057; id| user | name | description | songspaminterval | lastsongtime | entropy | newbie |creationdate| r1 | r2 | r3 | r4 | r5 | scrobcount | newbielistenas | e1 | e2 | e3 | e4 | e5 | numdisconnections | totalstreamtime -+-+-+-+--+- +-++++++ +++++++-++-- -+- 1017057 | 1017075 | Default | | 60 | 2003-12-18 04:32:34 | 1 | f | 2003-12-17 23:57:01.582757 | 0 | 0 | 0 | 0 | 0 | 23 || 2 | 0 | 0 | 219 | 0 | 0 | 0 (1 row) last=> If you know how this problem might be fixed, list the solution below: - No idea :). ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] plpgsql For SQLQuery Loop Flags Error
Hi All,
I am compiling a function that uses the For Query
loopEnd Loop.
I get error "missing ".." at end of SQL expression"
I have read following Note: The PL/pgSQL parser
presently distinguishes the two kinds of FOR loops
(integer or query result) by checking whether the
target variable mentioned just after FOR has been
declared as a record or row variable. If not, it's
presumed to be an integer FOR loop. This can cause
rather nonintuitive error messages when the true
problem is, say, that one has misspelled the variable
name after the FOR. Typically the complaint will be
something like missing ".." at end of SQL expression
at
http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-CONTROL-STRUCTURES-LOOPS
Re checked the RECORD variable in function
CREATE OR REPLACE FUNCTION slice(char(15),varchar,
integer) RETURNS integer AS '
DECLARE
curTrackList char(15) ALIAS for $1;
sliceFile varchar ALIAS for $2;
lmfpLimit integer ALIAS for $3
mTrackDet RECORD;
lpmfSum integer := 0;
Sliced CONSTANT integer := 2;
curId varchar;
counter integer :=1 ;
BEGIN
Build the curSliceId value
curId := curTrackList;
Insert into mysliceDetail
values(''abcdef'',''Ghijkl'',0);
FOR mTrackDet IN SELECT myrequest.trackId,
lmfpsize from myrequest,track where trkfound <> Sliced
and myRequest.trackid = track.trackId and lmfpsize > 0
order by volatility LOOP
-- Now "mTrackDet" has one record from slice
list
--LOOP
--WHILE lpmfSum < lpmfLimit LOOP
--Insert into mysliceDetail values(curId,
mTrackDet.trackId ,0);
--Insert into curSliceDetail values(curId,
mTrackDet.trackId ,0);
--lmfpSum := mTrackDet.lmfpsize + lmfpSum ;
--EXIT WHEN lpmfSum > lpmfLimit
--END LOOP;
insert into sliceToBuild values(curId, 0);
copy curSliceDetail to sliceFile;
counter := counter + 1;
Truncate Table curSliceDetail;
---Generate next curSliceId
curSliceId := curTrackList + counter;
END LOOP;
RETURN 1;
END;
' LANGUAGE plpgsql;
Can someone help please
Regards
Paul
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[BUGS] BUG #1014: postgres crash
The following bug has been logged online: Bug reference: 1014 Logged by: vidhya Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.3 Operating system: windows2000 Description:postgres crash Details: Hi, Due to overload postgres crashes often. I am getting the following error IpcMemoryCreate: shmget(key=5432001, size=1499136, 03600) failed: Not enough core I want to increase the SHMMAX parameter in kernel. I read the PG documents. They suggested to change the parameter in shm.h file. They told that SHMMAX parameter is defined in shm.h as “#define SHMMAX 0x200.” But i couldn't find such an entry in that file. Can u suggest me a solution for this? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] plpgsql Integer Concat To String
Hi, I want to concatenate a it counter to a string in a loop in plpgsql. DECLARE counter integer := 1; IdSet char : = 'UniqueId' IdForEachRun varchar; BEGIN IdForEachRun := IdSet || counter;(PROBLEM HERE) --Or IdForEachRun := IdSet + counter;(PROBLEM HERE) While condition LOOP Insert into Table values(IdForEachRun, ..) counter := counter + 1; IdForEachRun := IdSet || counter;(PROBLEM HERE) --Or IdForEachRun := IdSet + counter;(PROBLEM HERE) END LOOP END Language 'plpgsql' Thanks in advance. Paul __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] BUG #1013: Authentication doesn't work
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > When I start up psql, if I am not not logged in as the owner of the database, I get > the following error message, even if I type the correct password: > psql: FATAL: IDENT authentication failed for user "keith" This is not a bug: it's the way it's supposed to work. If you want to use passwords for authentication, you need to select a password-based method in pg_hba.conf. Not IDENT. Read the administrator's guide for more detail: http://www.postgresql.org/docs/7.4/static/client-authentication.html regards, tom lane ---(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: [BUGS] SELECT FOR UPDATE differs inside and outside a pl/pgsql
Mark Shewmaker <[EMAIL PROTECTED]> writes: > On Wed, 2003-12-17 at 19:57, Tom Lane wrote: >> Mark Shewmaker <[EMAIL PROTECTED]> writes: >>> If a "FOR UPDATE executes before LIMIT" rule stopped the function >>> from ever locking a row, it's still curious why didn't it stop the >>> direct command from ever locking a row as well. >> >> I think it would. Did you try the test the other way around (with the >> direct command being blocked behind someone who deletes the first row)? > Yes, or at least I've done the test that I think you're asking about. So you have. Your session B_1 (second column) shows exactly the behavior I expected: the first invocation of SELECT FOR UPDATE fails to lock any row. You manually did the equivalent of looping as in myfunction(). So it looks the same to me. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] plpgsql For SQLQuery Loop Flags Error
I should play with your code, but I'm lazy. 1) lmfpLimit integer ALIAS for $3 is missing the trailing ";" lmfpLimit integer ALIAS for $3; 2) VARCHAR variables need a length curId varchar; should be curId varchar(100); 3) I have not seen this style of declaration, where the argument type is repeated from the function's argument list. This may be OK, but if nothing else helps maybe removing the type will help. curTrackList char(15) ALIAS for $1; sliceFilevarchar ALIAS for $2; lmfpLimitinteger ALIAS for $3 curTrackList char(15) ALIAS for $1; sliceFile varchar ALIAS for $2; lmfpLimit integer ALIAS for $3 mTrackDet RECORD; lpmfSum integer := 0; Sliced CONSTANT integer := 2; curId varchar; counter integer :=1 ; ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Urgent: Key constraints behaving weirdly
"Russell Garrett" <[EMAIL PROTECTED]> writes: > Constraints are being weird. The reproduction instructions speak for > themselves. You haven't really provided enough info to let anyone do anything about this. Certainly no one else is going to be able to reproduce the problem based on what you've provided. I can think of a number of theories: 1. There's a rule or trigger ON UPDATE that is modifying the behavior of the update you showed, and is causing the duplicate-key error (ie, there's a bug in the rule or trigger logic and the error report is legitimate). 2. The index is corrupt, possibly due to a hardware glitch. (This seems unlikely because the SELECT result appears normal, but I can't rule it out entirely.) 3. You've stumbled across a corner-case bug that no one has seen before. If the problem is #2 then the likely recovery method would be a REINDEX, hopefully followed by some intensive hardware testing. If the problem is #3 then it's fairly likely that a REINDEX would make the failure go away, but we'd lose this opportunity to find the bug. If you want to pursue theory #3, I would recommend the following procedure: A. Shut down postmaster for long enough to make a tarball copy of the whole $PGDATA directory tree. You should then be able to investigate the problem at leisure by loading the tarball on a playpen machine. B. REINDEX to (hopefully) make the problem go away on the production machine, so it can get back to work. C. Build a debug-enabled Postgres installation on your playpen machine, and start tracing through the failure with gdb. I'd be willing to help out if you don't feel competent to carry through step C. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] plpgsql For SQLQuery Loop Flags Error
Puneet Paul <[EMAIL PROTECTED]> writes: > DECLARE > curTrackList char(15) ALIAS for $1; > sliceFile varchar ALIAS for $2; > lmfpLimit integer ALIAS for $3 > mTrackDet RECORD; If that's an accurate copy of your function, then the problem is likely the lack of a semicolon on the lmfpLimit line. I'm not sure why you don't get a syntax error, but evidently the "mTrackDet RECORD" is getting treated as a noise phrase in the lmfpLimit declaration. What Postgres version is this, anyway? The current sources do not look like they'd accept such a thing without raising an error, but possibly older releases would. regards, tom lane ---(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: [BUGS] libpq3 + ssl memory leak
Neil Conway <[EMAIL PROTECTED]> writes: > Okay, I've attached a patch that fixes the problem for me. The problem > turned out to be pretty simple: the PostgreSQL code (both backend and > frontend SSL support) was calling SSL_get_peer_certificate() without > properly free'ing its return value. Applied to 7.4 and HEAD. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] BUG #1015: Got a signal 11 while trying to create a temp table
The following bug has been logged online:
Bug reference: 1015
Logged by: Aarjan Langereis
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3.4
Operating system: RedHat Linux 9 kernel 2.4.20-20.9
Description:Got a signal 11 while trying to create a temp table
Details:
I tried to create a temp table and got my back-end restarting because of a signal 11.
The 3 tables involved:
CREATE TABLE hosts (
hostID serial primary key,
hostip cidr NOT NULL,
hostname varchar(50),
lastseen timestamp without time zone default ('1970-01-01 01:00'),
total integer default 0,
image varchar(20) default 'hosts/unknown.png'
);
CREATE TABLE cpus (
cpuID integer primary key,
cpuname varchar(20),
lastseen timestamp without time zone default ('1970-01-01 01:00'),
total integer default 0,
image varchar(20) default 'cpus/unknown.png'
);
CREATE TABLE blocks (
blockID varchar(30) primary key,
blockdate timestamp without time zone NOT NULL,
hostID integer REFERENCES hosts,
orgIP cidr NOT NULL,
email varchar(30) NOT NULL,
osID integer NOT NULL,
cpuID integer NOT NULL,
version integer NOT NULL,
core integer NOT NULL,
amount integer NOT NULL
);
Hosts has 205 rows
Cpus has 17 rows
And blocks has 3194409 rows
This is the problem query:
Create TEMP table tmphosts AS
select hosts.hostid, hosts.hostip, hosts.hostname, max(blockdate) as lastseen,
sum(amount) as total, hosts.image
from hosts left join blocks on hosts.hostid=blocks.hostid
group by hosts.hostid, hosts.hostip, hosts.hostname, hosts.image;
But even without the first line is does not work. However this query does work
properly:
Create TEMP table tmpcpus AS
select cpus.cpuid, cpuname, max(blockdate) as lastseen, sum(amount) as total,
image
from cpus left join blocks on cpus.cpuid=blocks.cpuid
group by cpus.cpuid, cpuname, image;
They look rather the same to me… But with the first one I got this error in psql:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#
In the log was this:
LOG: server process (pid 27196) was terminated by signal 11
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing shared memory and semaphores
FATAL: The database system is starting up
LOG: database system was interrupted at 2003-12-18 19:16:21 CET
LOG: checkpoint record is at 6/9312CD40
LOG: redo record is at 6/9312CD40; undo record is at 0/0; shutdown FALSE
LOG: next transaction id: 2909; next oid: 15667926
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 6/9312CD80
LOG: ReadRecord: unexpected pageaddr 6/8B162000 in log file 6, segment 147, offset
1449984
LOG: redo done at 6/9315EE4C
LOG: database system is ready
I don’t know what information can be useful to you. But if you need more, please ask!
It seems to me, and please correct me if I’m wrong, that there is a limit to the
size that a join can handle.
I hope that the information provided is of any use to you.
Yours,
Aarjan
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Urgent: Key constraints behaving weirdly
Tom Lane wrote: > "Russell Garrett" <[EMAIL PROTECTED]> writes: >> Constraints are being weird. The reproduction instructions speak for >> themselves. > > You haven't really provided enough info to let anyone do anything > about this. Certainly no one else is going to be able to reproduce > the problem based on what you've provided. I'm aware of that, but it's really quite difficult to rule out everything. Our database isn't that small, and we don't have the resources to immediately deduce a test case (i.e. it's just me ;). > I can think of a number of theories: > > 1. There's a rule or trigger ON UPDATE that is modifying the behavior > of the update you showed, and is causing the duplicate-key error (ie, > there's a bug in the rule or trigger logic and the error report is > legitimate). There's nothing triggered by that update. > 2. The index is corrupt, possibly due to a hardware glitch. (This > seems unlikely because the SELECT result appears normal, but I can't > rule it out entirely.) We had a table error a few weeks back, however we re-imported the table from scratch. So it may well be this. I doubt it's a actually a Postgres bug now, since we aren't doing anything particularly unusual, and it's been working fine for several weeks. Still, I'm not ruling it out. Russ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Urgent: Key constraints behaving weirdly
>> 2. The index is corrupt, possibly due to a hardware glitch. (This >> seems unlikely because the SELECT result appears normal, but I can't >> rule it out entirely.) > > We had a table error a few weeks back, however we re-imported the > table from scratch. So it may well be this. I doubt it's a actually a > Postgres bug now, since we aren't doing anything particularly > unusual, and it's been working fine for several weeks. Still, I'm not > ruling it out. OK, I'm not sure whether this is index corruption or a postgres bug or both: last=> select id, count(id) AS a FROM profile GROUP BY id ORDER BY a DESC; id| a -+--- 1017057 | 2 1018316 | 2 0 | 1 80 | 1 ... last=> SELECT id from profile WHERE id = 1017057; id - 1017057 (1 row) last=> SELECT id from profile WHERE id = 1018316; id - 1018316 (1 row) last=> reindex index profile_pkey; ERROR: could not create unique index DETAIL: Table contains duplicated values. Does REINDEX use the current index to check for duplicates? :) Many thanks for all the help, Russ ---(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: [BUGS] plpgsql For SQLQuery Loop Flags Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I get error "missing ".." at end of SQL expression" ... > Can someone help please The problems appear to be in your declare block: > curTrackList char(15) ALIAS for $1; > sliceFile varchar ALIAS for $2; > lmfpLimit integer ALIAS for $3 You need a semicolon after the #3, and if declaring a variable as an alias, you do /not/ put in the data type (because you already declared it). In other words: curTrackList ALIAS fOR $1; sliceFileALIAS FOR $2; lmfpLimitALIAS FOR $3; That may or may not be what is causing the error you saw: plpgsql's error reporting is not always as helpful as it should be. Just start at the top of the file and work your way down, looking for easy stuff. Then cut things out of the function until it works, and add things back in a line at a time until you figure out the problem(s). - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200312182010 -BEGIN PGP SIGNATURE- iD8DBQE/4lDovJuQZxSWSsgRAulsAJ0bvUiXWiKmUDLV6esHoZtuQ6D5eQCgi5AA xKH9t+TM59YbXa2dc7CyjRY= =yapu -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] libpq3 + ssl memory leak
Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > Okay, I've attached a patch that fixes the problem for me. The problem > > turned out to be pretty simple: the PostgreSQL code (both backend and > > frontend SSL support) was calling SSL_get_peer_certificate() without > > properly free'ing its return value. > > Applied to 7.4 and HEAD. Good. I have given up getting an update from the original bug reporter. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1015: Got a signal 11 while trying to create a temp table
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > I tried to create a temp table and got my back-end restarting because of a signal 11. Hmm. Can you get a debugger backtrace from the core dump? > It seems to me, and please correct me if I’m wrong, that there is a limit to the > size that a join can handle. No (and certainly not on a measly 3-million-row case). This could be a data corruption problem, or something more subtle, but it's not that. One way of testing the data-corruption theory is to see if you can select all the data from the tables involved, without any join. regards, tom lane ---(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: [BUGS] Urgent: Key constraints behaving weirdly
"Russell Garrett" <[EMAIL PROTECTED]> writes: > last=> reindex index profile_pkey; > ERROR: could not create unique index > DETAIL: Table contains duplicated values. Okay, it looks like the table actually contains duplicate rows but the index has managed to lose track of that fact. You can see the duplicates in the GROUP BY query (which isn't using the index) but not when you do "select * from profile where id = 1017057", because that query will use the index. If you did "set enable_indexscan = off" then the "select * from profile where id = 1017057" query would probably show you two rows. I'd be interested to see the results of select ctid, oid, xmin, xmax, cmin, cmax from profile where id = 1017057; with enable_indexscan off. > Does REINDEX use the current index to check for duplicates? :) No, it's building a new index from scratch, and so it notices the duplicates. What you've got here is definitely a case of index corruption that has led to logical corruption of the table (ie, duplicate rows). To get back to a valid state you will need to delete whichever of the duplicates seems to be out-of-date, and then do a REINDEX. But I think it is important first to try to determine what caused the corruption (software error or hardware?). Again, if you can take a physical dump of the data directory, that would provide an opportunity to study the problem later after you get the production machine back on its feet. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
