Em 17-11-2011 09:21, Yan Chunlu escreveu:
I am using pgpool's replication feature, it does copy pg_xlog from one server to another, was that possible cause of the problem?
I did not mean that this IS your problem, I just gave you a tip regarding a problem I had in the past, that eventually has same simptom.
This scenario only happens when your script is copy data over own data... like in "rsync -ar
root@127.0.0.1:/var/lib/pgsql/9.0/data/* /var/lib/pgsql/9.0/data/"
the command above is highly dangerous because it copies data over the network link over its own data... if you have transactions runing during the command above, you will get a crash (and, in my case, I had duplicate primary keys).
Would be better to check if this could be happening to you... some script overwriting data using rsync, cp, etc... I had no other situation where Postgresql allowed duplicate keys.
Hope this helps,
Edson.
thanks for the help!
On Thu, Nov 17, 2011 at 5:38 PM, Edson Richter
<richter@simkorp.com.br> wrote:
Em 17-11-2011 03:19, Yan Chunlu escreveu: recently I have found several tables has exactly the same pkey, here is the definition:
"diggcontent_data_account_pkey" PRIMARY KEY, btree (thing_id, key)
the data is like this:
159292 | funnypics_link_point | 41 | num
159292 | funnypics_link_point | 40 | num
I could not even update this record.
really confused about how could this happen... thanks!
I did this stupidity once, and learned for a life time. Lost two hours of work to recover everything (from backup, at least I had one).
Be careful with rsync and cp, since Linux does not block files from being overwriten even when they are in use.
Regards,
Edson.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general