Обсуждение: HELP all women were raped during the May riots in Jakarta

Поиск
Список
Период
Сортировка

HELP all women were raped during the May riots in Jakarta

От
adm@pu.go.id
Дата:
We Promise that we will throw a nuclear bomb to Indonesia to
destroy this besterd Islam country, if they still persecute our chinese.

B J Habibie, we will kill you if you don't settle this case.

see what they do!    http://lateline.muzi.net/topics/Indonesian_atrocity/
http://muzi.net

¦L¥§¬F©²email:dkiweb@indo.net.id
¦L¥§¥~¥æ³¡Home Page: http://www.deplu.go.id
¥»¦¸¨Æ¥óªººô­¶: http://members.spree.com/expose/
http://dailynews.sinanet.com/focus/1998071402/index.html

FORWARDED FROM MISSIONNET'S URGENT PRAYER NETWORK
    ___________________________________________________________
Source: Christian Leaders Association
¨Ó·½:¤Ñ¥D±Ð»â³S¨ó·|

21 June, 1998. Jakarta, Indonesia
1998¦~6¤ë21¤é,¦L¥§¶®¥[¹F

Dear friends,

(¿Ë·RªºªB¤Í)
Here I submit a victim's account of being raped during the
May riots here in Jakarta. Reference to Huaran Bulletin
Board June 12, 1998.
(³o¸Ì§Ú·Q§i¶D¤j®a¦³Ãö¤­¤ë¼É°Ê®É¦b¶®¥[¹Fµo¥Íªº
±j¼É¨Æ¥ó,³o¬O§Ú±q¤µ¦~6¤ë12¤éªºHuaran§G§iª©¤¤±oª¾ªº)

The purpose is to request your prayers for hundreds of
similar victims.
(§Æ±æ¤j®a¯à¬°³o¨ÇÄ묹ªÌ¬èë)

"My name is Vivian, and I am 18 years old. I have a little
sister and brother. As a family we live in what is supposed
to be a "secure" apartment.
("§Ú¥sVivian,¤µ¦~18·³.§Ú¦³¤@­Ó©f©f©M§Ì§Ì,¦í¦b¤@´É³Q»{
¬°¬O¦w¥þªº¤½´J)

At 9.15 am, May 14th, 1998 a huge crowd had gathered around
our apartment. They screamed, "Let's butcher the Chinese!",
"Let's eat pigs!", "Let's have a party!" We live of the 7th
floor and we  got a call from a family on the 3rd floor
saying that the crowd had reached the 2nd floor. They even
chased some occupants upstairs. We were all very frightened.
In our fright we prayed and left everything in God's hands.
(1998¦~5¤ë14¤é¤W¤È9ÂI15¤À,¤@¸s¤HÂô¶i§Ú­Ìªº¤½´J
¥L­Ì³ÛµÛ"§Ú­Ì­n±þ¤FµØ¤H!","§Ú­Ì§â½Þ¦Y¤F!",§Ú­Ì¦í¦b
¤C¼Ó,¤T¼Óªº®a¤H§i¶D§Ú­Ì¨º¸s¤H¤w¸g¨ì¤F¤G¼Ó,¥L­Ì¬Æ
¦Ü°lµÛ¦í¤á¤W¨Ó,§Ú­Ì³£³QÀ~Ãa¤F,¥u¯à¦b®£Äߤ¤¬èë,±N
¤@¤Á¥æµ¹¤W«Ò)

Afterward we left our room and went upstairs to the top
floor, as it was impossible to go downstairs and escape. We
got to the 15th floor and stayed with some friends. Not long
afterwards we were surprised because some of the crowd
coming out of the elevators right before we entered the
room. We hurried into the room and locked the door tightly.
At that time we heard them knock at the other rooms loudly
and there were some screams from women and girls. Our room
was filled with fear.
(¤§«á§Ú­ÌÂ÷¶}©Ð¶¡°k¨ì³»¼Ó,§¹¥þµLªk¤U¼Ó°k¨«,§Ú­Ì©M
¤@¨ÇªB¤Í°k¨ì15¼Ó,¨S¦³¦h¤[,¦b§Ú­Ì¸ú¶i©Ð¸Ì¤§«e,¨º¸s
¤H´N½Ä¥X¹q±è,§Ú­Ì»°§Ö¶i¤J©Ð¸ÌÂêºò©Ðªù,¥uÅ¥¨ìªù¥~
¶Ç¨Ó½ðªùªºÁn­µ,¥H¤Î¤@¨Ç°ü¤k©M¤k«Äªº¦y¥sÁn,¾ã­Ó
©Ð¶¡¥Rº¡µÛ®£Äß)

We realized that they would come to us. So we spread
throughout the room hiding in the corners.We could hear
girls of 10 to 12 years old screaming, "Mommy,
..mommy...mom...mom...it hurts" That time I didn't know
that these little girls were being raped. After about half
an hour the noise diminished and we had some guts to go out
and check. It was indescribable. A lot, some of them youg
girls, were lying on the floor. "Oh my God, what has
happened?" Seeing all of this we screemed and my little
sister Fenny, screamed histerically and hugged her father.
(§Ú­Ì¤F¸Ñ¨ì¥L­Ì¿ð¦­·|¶i¨Ó,©Ò¥H§Ú­Ì·æÁYªº¸ú¦bÀð¨¤
§Ú­ÌÅ¥¨ì¤j¬ù10¨ì12·³ªº¤k«Äªº¦y¥s"¶ý...¶ý...¶ý....¦nµh
§â¦o¥á¨ì¨Fµo¤W,§Ú°¨¤W¤ÏÀ³¨ì¦oªº¦MÀI,©ó¬O¤j¥s,
¦ý¬O¤@­Ó¼É¥Á¥´¤F§Ú¤@­Ó¦Õ¥ú,§Úª¨ª¨¤]³Q¥L­Ì¥Î¤ì
´Ò¥´©ü,§Ú¶ý¶ý¦bFenny³Q¥á¨ì¨Fµo¤W®É´N©ü­Ë¤F,§Ú¥u
¯à¬èë,¥u¯à¬èë¨aÃø¤£­n­°Á{)

Uncle Dodi kept trying to stop them by offering money. His
efforts were fruitless. And in the end 5 people raped Fenny.
Before beginning with the raping they always said "Allahu
Akbar" (an islamic phrase in arabic meaning "God is great".
They were ferocius and brutal.
(Dodi¨û¨û¸ÕµÛ¥Î¿úÅý¥L­Ì¤£­n¬I¼É,¦ý¬O¨S¦³¥Î,µM«á
¦³¤­­Ó¤H±j¼É¤FFenny,¨C­Ó¦b±j¼É«e³£©ÀµÛ"Allahu Akbar"
¬O¥ì´µÄõ±Ðªºµu¥yªü©Ô§B¸Üªº·N«ä¬O"°¶¤jªº¯«",¥L­Ì Åã±o´Ý¼É¦Ó¥B¹³³¥Ã~¤@¯ë)

Not long afterward, around 9 men came to the room and
dragged me. I also saw them forcing and dragging my Aunt
Vera. But at that time I passed out and everything went
blank. I became conscious at around 5 or 6 pm. My head
hurted and I realized I had no clothing on my body. I cried
and realized my family was still there. My father was
hugging my mother and little bother Doni. I also saw uncle
Dodi lying on the floor and Aunt Vera was crying over his
body. I felt so weak and fainted again.
(¨S¦³¦h¤[,¤j·§¦³¤E­Ó¤H§â§Ú©ì¥X¥h,§Ú¬Ý¨ì¥L­Ì¤]§â
VeraÂTÂT©ì¥X¨Ó,¦ý¬O§Ú©ü¤F¹L¥h,¤@¤Á³£Åܦ¨ªÅ¥Õ
¤j¬ù¤U¤È5ÂI¨ì6ÂIªº®É­Ô,§Ú³vº¥ªº«ì´_·NÃÑ,§ÚªºÀY
³¡¨ü¤F¶Ë,¨­¤W¤]¤@µ·¤£±¾,§Ú­ú¤F¥X¨Ó,¨Ã¥Bµo²{§Ú
ªº®a¤HÁÙ¦b,§Úª¨ª¨©êµÛ§Ú¶ý¶ý©M§Ì§Ì,Dodi¨û¨û­Ë¦b
¦a¤W¦ÓVeraÂTÂT©êµÛ¥Lµh­ú,§Ú·P¨ìµê®z¦Ó¤S·w¯t¹L¥h)

The next day I was in the Pluit hospital. My father and
mother were beside me. With all the pains on my body I
asked, "Mom, why Fenny. Mom?" I felt a stinging pain as I
said these words. My cheeks were swollen. My mother cried
again and couldn't speak any words, while my father, holding
back his tears, managed to smile at me. After 4 days in
treatment, my condition has improved. With a sad look, my
father told me then what had happened. After I fainted 7
people raped me. At that time my father still couldn't see
well after beling hit with a piece of wood. They raped me
repeatedly. Then my father said "Vivian, Fenny is gone..."
(²Ä¤G¤Ñ§Ú³Q°e¨ìPluitÂå°|,§Úªºª¨¶ý¦b§Ú¨­®Ç,§Ú§ÔµÛµh
°Ý¥L­Ì"¶ý,Fenny©O?¶ý"»¡¸ÜÅý§Ú·P¨ì°w¨ë¯ëªºµh­W,§Ú
¶ý¶ý­ú¤F°_¨Ó,¤@¥y¸Ü³£»¡¤£¥X¨Ó,§Úª¨ª¨§Ô¦í²\¤ô,¹ï§Ú
­W¯º¤@¤U,¥|¤Ñ¤§«á,§Úªº±¡ªp¦n¤FÂI,§Úªº¤÷¿Ë¤@Áy¶Ë´d
ªº§i¶D§Ú,·í®É§Ú©ü°g¤F¥H«á,¦³7­Ó¤H±j¼É¤F§Ú,§Ú¤÷¿Ë«h
³Q¶Ã´Ò¼Þ¥´,¨º¨Ç¼É¥Á­«½Æªº±j¼ÉµÛ§Ú.¶ý¶ý¦b¤@®Ç¶Ë¤ßªº
»¡"Vivian,Fenny¦º¤F...")

I was confused and cried out, "Why Dad?" My father couldn't
answer. He told me to rest and went out of the room. I cried
over and over again, feeling that my life had no meaning any
more. A week ago, after I was released from the hospital I
was told everything that had happend.
(§Ú¸£¤¤¤@¤ù²V¶Ã,­ú¤F°_¨Ó,"ª¨ª¨.¬°¤°»ò?"§Ú¤÷¿ËµLªk
¦^µª§Ú,¥L§i¶D§Ú¦n¦n¥ð®§,¨«¤F¥X¥h,§Ú¤£°±ªº­ú,§Úªº¤H
¥Í¤w¸g§¹¥þ¨S¦³¥ô¦ó·N¸q¤F,¤@­Ó¬P´Á¹L¥h¤F,¦b§Ú¥X
°|¤§«á,¤~ª¾¹D¨Æ±¡ªº¾ã­Ó¸g¹L)

When Fenny was raped she kept on fighting and so she was
repeatedly slapped by her rapists. The last time she fought
Fenny spitted on one of them. Offended, the man grabbed a
knife and stabbed Fenny's stomach over and over again.
Finally she died with blood over her whole body.
(Fenny¦b³Q±j¼Éªº®É­Ô¤£°±ªº¤Ï§Ü,©ó¬O¨º¨Ç¼É¥Á¤£Â_
ªº¥´¦o,³Ì«áFennyªº¤Ï§Ü·S¤õ¤F¨ä¤¤¤@­Ó¼É¥Á,¥L§ì°_
¤@§â¤M¤l¨ë¶iFennyªº¨{¤l,¤@¦¸¤S¤@¦¸ªº¨ë¶i¨ë¥X,³Ì
«áFenny¥þ¨­¬O¦åªº¦º¤F)

My father told me that uncle Dodi had the same fate watched
by aunt Vera who was also raped. "God...why should all of
this happen? Where are you God? Are you still alive?" My
aunt Vera now stays with her parents. She is in shock. Her
face is blank and refuses to eat. Almost every hour my
mother and I cry over all these happenings. I can never
forget. These mobs of people are uncivilized monsters."
(¤÷¿Ë§i¶D§Ú,Dodi¨û¨û¤]¬ÝµÛ¦Û¤vªº¤Ó¤Ó³Q±j¼É,"¤Ñ§r!
¬°¤°»ò·|µo¥Í³oºØ¨Æ?¯«¦b­þ¸Ì?Í¢ÁÙ¬¡µÛ¶Ü?"§ÚÂTÂT Vera²{¦b©M¥Lªº¤÷¥À¦í¦b¤@°_,¦o¨ü¨ìÄY­«ªºÅåÀ~,
¦oªºÁy¤W¨S¦³¦å¦â¦Ó¥B©Úµ´¶i­¹,§Ú©M¶ý¶ýµL®ÉµL¨è
¦]¬°³o³õ´c¹Ú¦Ó­úª_,§Ú¥Ã»·§Ñ¤£¤F,¨º¨Ç¼É¥Á´N¹³¬O
¨S¦³¶i¤Æªº©ÇÃ~)

Additional comments from Bill Hekman:
(¥H¤U¬OBill Hekmanªºªþµù)

This is one of many victims. Hundreds of women and children
were raped, mutilated and killed by muslim mobs. Some had
their vaginas ripped apart, their bodies cut into pieces.
(³o¥u¬O«Ü¦hªºÄ묹ªÌ¤¤ªº¤@­Ó,¦³¼Æ¦Ê¦ì°ü¤k»P¤p«Ä
³Q¦^±Ð¼É®{±j¼É,±ÙÂ_¤â¸},±þ®`,¦o­Ìªºªº³±¹D³Q¼¹µõ
,¨­Åé³Q¬å¦¨¦n´X¬q)

Over 5000 of the Chinese Indonesian's shops were looted and
burned down. A few days ago anther 63 shops were burned in
Tegal, Central Java. The city of Solo is burned down. There
is no protection and no justice in this country any more.
(¶W¹L5000®a¥H¤Wªº¦L¥§µØ¤Hªº°Ó©±³Q±°¹Ü©MµI¿N,
´X¤Ñ«e¦b¤ö«zªºTegal,¥t¥~63®a°Ó©±³Q©ñ¤õ¿N±¼,¦L¥§
²{¦b§¹¥þ¨S¦³«O»Ù,¥¿¸q¿ºµMµL¦s)

Yesterday I was in the Kelapa Gading area and that area was
spared from destruction. The police and military had guarded
all the entry roads. The people there had collected large
sums of money from door to door and paid for their protection.
(¬Q¤Ñ§Ú¦bKelapa Gading°Ï,¨º¸Ì¥Ø«eÁÙ¨S¦³³Q¯}Ãa,ĵ¹î
©M­x¶¤¦b©Ò¦³¸ô¤fĵ§Ù,¨º¸Ìªº¤H­Ì¶°¦X¤F¤@¤jµ§¿ú¨Ó
¤ä¥I³o¨Ç«OÅ@)

A similar situation took place in the Pondok Indah area.For the people
who cannot pay millions to the armed forces there is no protection. Right
now
the hunderds of thousands of thugs,robbers, rapist, and killers live
all around us. They are our neighbors. There is no punishment for the
criminals and no justice for the victims. Yet, all Indonesians call themselves
believers in God almighty. What a hipocracy. Shouting "God is great" when
raping women andchildren is a blasphemy against a Holy God.
(¦bPondok Indah°Ï¤]¬O¦P¼Ëªº±¡ªp,®³¤£¥X¿úªº¤H´N§¹¥þ
¨S¦³¥ô¦ó«O»Ù,²{¦b¦³¦¨¤d¤W¸Uªº¦^±Ð¨ë«È,±jµs,±j¼ÉªÌ©M
±þ¤HÅ]¦í¦b§Ú­Ìªº¥|©P,¥L­Ì¬O§Ú­Ìªº¾F©~,¹ï©ó¸o¥Ç¨S¦³
³B»@,¹ï©ó¨ü®`ªÌ¤]¨S¦³¤½²z,¦ý¬O,©Ò¦³ªº¦L¥§¤H©I³êµÛ
¥L­Ì©Ò«H¥õªº"¥þ¯àªº¯«:"¤Ó¿Ø¨ë¤F.¦b±j¼É°ü¤k©M¤p«Ä®É
©I³Û°¶¤jªº¯«,³o¬O¹ï¯«¸t¤W«Òªº«_Âp)

Pray that God will annoint His preachers and missionaries
throughout this nation with the power of the Holy Spirit to
preach the message of repentance. God's word in 2 Chronicles
7:14 needs to be proclaimed boldly. There is no room for
preachers filled with fear who think of evacuation and other
selfish plans. Pray for Revival in all our churches.
(¬èë¤W«Ò¦b³o­Ó°ê®a¤¤¬°Í¢ªº¤l¥Á¶î¤Wªo»I,¥Î¯«¸tªº
¤O¶q¶Ç»¼®¬§ïªº°T®§,¬ù¸t¸g¾ú¥N§Ó²Ä7³¹²Ä14¸`À³¸Ó
³QÅã©úªº«Å§i,

There is no room for preachers filled with fear who thinkof
evacuation and other selfish plans.(³o¤@¥y¦b¤U½¤£¥X¨Ó¾A¤Áªº¦r¥y,±æ¦³
¯àªÌ¸É¤W) Ä@§Ú­Ìªº¸t·µ¬Ò¯à´_¿³

Some Christians are putting signs on their shops "Owned by
Muslim". May God forgive them. Healing of this nation filled
with crime and unjustice is bringing God's judgement and
punishment. Healing and Salvation can only come with a
nasional repentance at all levels in the government, armed
forces and society. Then we need to share the Gospel of the
Lord Jesus Christ. Christ is the One and Only Savior. No one
will ever receive forgiveness and see heaven except through
God's appointed Savior, the Lord Jesus Christ. Thank you for
standing with us now. God bless you.
(¦³ªº¤Ñ¥D±Ð®{ªº°Ó©±³Q¶K¤W"¦^±Ð®{©Ò¦³"ªº¼Ð»y,Ä@
¤W«Ò¼e®¤¥L­Ì,¥Î¤W«Òªº¼f§P»PÃg»@¨ÓÂåªv³o­Ó¥Rº¡
¸o´c»P¤£¸qªº°ê«×,°ß¦³¾ã­Ó°ê®a-¦U¯Å¬F©²,­x¶¤©MªÀ·|
-ªº®¬§ï¤~¯à°±¤î¶Ëµh,§Ú­Ì­n¶Ç¼½°ò·þªººÖ­µ,°ò·þ¬O°ß

chaos in Indonesia last May 13-15. Many Chinese Indonesian
citizens were abused, tortured and killed. Their houses and stores
were
looted and burnt. Hundreds of Chinese Indonesian
girls/women (aged 10-55) were sexually harassed and gang raped
brutally.
Some victims were even raped in front of their family members or in
front
of inhuman cheering crowd.
(½Ð±N³o«Ê"¶Àµ·±a"ªº«H¥ó±Hµ¹±zªºªB¤Í,¨Óªí¥Ü§Ú­Ì¹ï©ó
¦b¤­¤ë13-15¤é©ó¦L¥§¼É°Ê¤¤¨ü®`ªºÄ묹ªÌ¤@Åé·P»P¦P±¡
³\¦hµØ¸Çªº¦L¥§¤½¥Á³Q±j¼É,­â­h,±þ®`.¥L­Ìªº©Ð¤l©M°Ó©±
³Q·m§T©MµI¿N,¦³ªº¨ü®`ªÌ´N¦b®a¤H»P¤@¸s¨S¦³¤H©Ê
ÁÙÅw©Iªº¸s²³­±«e³Q½ü¼É)

Some of them  were even thrown into the fire and burnt to death after
being
raped. Yet, not many actions seem to have been taken to investigate
all
this or to help the victims. And not very many people seem to know or
care
about what happened. Please help to spread the news and let the world
know.
(¨ä¤¤¦³¨Ç¤H¦b³Q±j¼É¤§«á,ÁÙ³Q¥á¤J¤õ¤¤µI¿N¦Ü¦º,¦ý¬O,¨Ã
¨S¦³³\¦h½Õ¬d©Î¨ó§Uªº¦æ°Ê¦b¶i¦æ,¦Ó¥B¤]ÁÙ¨S¦³«Ü¦h¤HÃö
¤ß©Î¬Oª¾¹D³o¨Ç¨Æ±¡,½Ð¨ó§U´²§G³o¨Ç®ø®§,Åý°ê»Ú¶¡ª¾¹D
³o¨Ç¨Æ)

We need help to get more international attention to help Chinese
Indonesians, who are now living in fear in Indonesia. Please pass this
ribbon around as the symbol of campaign against human rights
violations, injustice, and racism towards Chinese Indonesians.
(§Ú­Ì»Ý­n¤Þ°_°ê»Ú¶¡ªº­«µø,¥H«KÀ°§U¥Ø«e¥Í¬¡¦b®£Äߤ¤
ªº¦L¥§µØ¤H,½Ð±Nµ·±a§@¬°¤Ï¹ï¥[½Ñ©ó¦L¥§µØ¤Hªº¼É¤O,
¤£¥¿¸q¥H¤ÎºØ±Ú¥D¸qªº¼Ð»x)

Show that we care and may God help us!
(§i¶D¥@¤H§Ú­ÌÃö¤ß,Ä@¤W«Ò½ç»P§Ú­Ì¤O¶q)

Toronto PostgreSQL Gathering - June 1st

От
Christopher Browne
Дата:
I had intended to try to "organize" some form of Toronto PostgreSQL
'user group'; some challenges have gotten in the way of having that be
at all "large scale," but it certainly makes sense to try to get local
people interested in PostgreSQL together every so often.

A number of groups gather at different times at Toronto's Linux Caffe;
the first Thursday of the month seems an opportune time for this, and
the next incidence of that is next Thursday, June 1st.

Linux Caffe is located at Grace and Harbord, just South of Christie
station.  It has free wifi, so feel free to bring a laptop.  David
Patrick, the proprietor, has found himself reasonably keen about
PostgreSQL; he's using it, along with SQL Ledger, for some his
accounting efforts.  He does some quite excellent sandwiches and
panini, too, and it has been too long since I have had one...
--
output = ("cbbrowne" "@" "acm.org")
http://linuxdatabases.info/info/lisp.html
Rules of the Evil Overlord #49. "If I learn the whereabouts of the one
artifact  which can destroy me, I  will not send all  my troops out to
seize it.  Instead I  will send them  out to seize something  else and
quietly     put     a     Want-Ad    in     the      local     paper."
<http://www.eviloverlord.com/>

Re: Toronto PostgreSQL Gathering - June 1st

От
Christopher Browne
Дата:
Martha Stewart called it a Good Thing when Christopher Browne <cbbrowne@acm.org> wrote:
> A number of groups gather at different times at Toronto's Linux Caffe;
> the first Thursday of the month seems an opportune time for this, and
> the next incidence of that is next Thursday, June 1st.

And oops, 7pm is the appointed time...
--
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/spreadsheets.html
"A cynic is a man who knows the price  of everything, and the value of
nothing."  -- Oscar Wilde

Non-Fun with SSHA Password scheme

От
Chris Browne
Дата:
I have been trying to set up pl/pgsql code to generate and evaluate
{SSHA} passwords, with somewhat limited success.

{SSHA} is a password scheme that uses SHA-1 along with salting to ward
off dictionary attacks.  Apparently it's used quite a bit with LDAP.

There does not seem to be a "claimed authoritative" source on it; the
nearest is an OpenLDAP FAQ entry that points to a now-dead Netscape
source; apparently the idea was created by someone in Netscape's LDAP
group.

  http://www.openldap.org/faq/data/cache/347.html

  http://developer.netscape.com/docs/technote/ldap/pass_sha.html  (dead)

 (So instead, see the WayBack Machine...)
  http://web.archive.org/web/20040810221808/http://developer.netscape.com/docs/technote/ldap/pass_sha.html

The OpenLDAP FAQ shows examples in Python, Perl, PHP, and Ruby;
they're not very self-explanatory :-).

A Sun Blog has a very nice algorithmic description:
   http://blogs.sun.com/DirectoryManager/entry/the_ssha_password_storage_scheme

I've been trying to create a pair of functions to encode & decode
them.  I get something *internally* consistent, but that doesn't
consistently evaluate other tools' SSHA passwords rightly.

The "consistent" part is the odd part.

If I take the Python/Ruby implementations in the OpenLDAP FAQ, and
choose a human-readable-text salt value, those values seem to (near as
I can tell with a limited selection set :-)) evaluate successfully in
the function ssha_verify(), below.

If, instead, I allow them to use arbitrary binary salts (e.g. - a
series of randomly chosen bytes), then ssha_verify() is quite sure
they don't match.

I suspect I'm doing something dumb surrounding the string smashing,
but just what is not occurring to me.

--------- Set phasers to Cut Here ----------------------
create or replace function ssha_encode (i_secret text) returns text as $$
declare
    c_salt bytea;
    c_shaed_pw bytea;
begin
    -- 1.  Generate 8 bytes of random data to use as salt
    c_salt := public.digest(now()::text || i_secret || random()::text, 'sha1');
    -- 2+3 Append salt, generate SHA1 digest
    c_shaed_pw := public.digest((i_secret||c_salt), 'sha1');
    -- 4-5 - append salt, and encode in base64
    return '{SSHA}' || pg_catalog.encode(c_shaed_pw || c_salt, 'base64');
end $$ language plpgsql;

create or replace function ssha_verify (i_secret text, i_hash text) returns boolean as $$
declare
    c_decoded bytea;
    c_body text;
    c_chash bytea;
    c_salt bytea;
    c_hash bytea;
begin
    if not (i_hash like '{SSHA}%') then
        raise exception 'ssha_verify(%,%) - hash not of SSHA form!', i_secret, i_hash;
    end if;
    c_body := substr(i_hash, 7);
    c_chash := substr(pg_catalog.decode(c_body, 'base64')::bytea, 1, 20);
    c_salt := substr(pg_catalog.decode(c_body, 'base64')::bytea, 21);
    c_hash := public.digest((i_secret || c_salt), 'sha1');
    if c_hash = c_chash then
        return 't';
    else
        return 'f';
    end if;
end
$$ language plpgsql;
--------- Set phasers to Cut Here ----------------------
--
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/sap.html
Rules of the  Evil Overlord #22. "No matter how tempted  I am with the
prospect  of unlimited  power, I  will  not consume  any energy  field
bigger than my head. <http://www.eviloverlord.com/>

Re: Performance slowing down when doing same UPDATE many times

От
Jan Strube
Дата:

Hi,

 

does no one have an idea?

It may be a rare case doing the same UPDATE a thousand times. But I´m really interested why this is not happening when doing DIFFERENT updates. And, of course,  if something could be done on the database side to prevent this behavior in case some application developer does the same “mistake” again.

 

Thanks

Jan

 

 

From: Jan Strube
Sent: Tuesday, February 10, 2015 12:03 PM
To: 'pgsql-general@postgresql.org'
Subject: Performance slowing down when doing same UPDATE many times

 

Hi,

 

we recently found a bug in one of our applications which was doing exactly the same UPDATE operation a few thousand times inside a transaction. This caused the UPDATEs to become slower and slower from some milliseconds to some seconds. We already fixed the application but I am wondering if this might be a PostgreSQL bug, too.

 

Here is a simple test case that performs and benchmarks 100,000 UPDATEs (benchmarking only every 10,000th to reduce output):

 

BEGIN;

CREATE TEMP TABLE test (id integer PRIMARY KEY, flag boolean DEFAULT false);

INSERT INTO test (id) SELECT generate_series(1, 100000);

 

DO $$

DECLARE

  s timestamp;

  e timestamp;

BEGIN

  FOR i IN 1..100000 LOOP

    SELECT clock_timestamp() INTO s;

    UPDATE test SET flag = true WHERE id = 12345;

    SELECT clock_timestamp() INTO e;

 

    IF i%10000 = 0 THEN

      RAISE NOTICE '%', e-s;

    END IF;

  END LOOP;

END $$;

ROLLBACK;

 

The output looks like this:

 

NOTICE:  00:00:00.000525

NOTICE:  00:00:00.000992

NOTICE:  00:00:00.001404

NOTICE:  00:00:00.001936

NOTICE:  00:00:00.002374

NOTICE:  00:00:00.002925

NOTICE:  00:00:00.003525

NOTICE:  00:00:00.004015

NOTICE:  00:00:00.00453

NOTICE:  00:00:00.004976

 

The problem only occurs inside a transaction and if the same dataset is updated. I´m using PostgreSQL 9.1.15.

 

Jan

 

Re: Performance slowing down when doing same UPDATE many times

От
Pavel Stehule
Дата:
Hi

it is side effect of MVCC implementation of Postgres. There is not possible vacuum inside open transaction.

If you need it, then you should to use a different database - Postgres doesn't work well when one record is highly often used in transaction. Usual solution for Postgres is some proxy, that work like write cache.

Regards

Pavel

2015-03-09 8:47 GMT+01:00 Jan Strube <js@deriva.de>:

Hi,

 

does no one have an idea?

It may be a rare case doing the same UPDATE a thousand times. But I´m really interested why this is not happening when doing DIFFERENT updates. And, of course,  if something could be done on the database side to prevent this behavior in case some application developer does the same “mistake” again.

 

Thanks

Jan

 

 

From: Jan Strube
Sent: Tuesday, February 10, 2015 12:03 PM
To: 'pgsql-general@postgresql.org'
Subject: Performance slowing down when doing same UPDATE many times

 

Hi,

 

we recently found a bug in one of our applications which was doing exactly the same UPDATE operation a few thousand times inside a transaction. This caused the UPDATEs to become slower and slower from some milliseconds to some seconds. We already fixed the application but I am wondering if this might be a PostgreSQL bug, too.

 

Here is a simple test case that performs and benchmarks 100,000 UPDATEs (benchmarking only every 10,000th to reduce output):

 

BEGIN;

CREATE TEMP TABLE test (id integer PRIMARY KEY, flag boolean DEFAULT false);

INSERT INTO test (id) SELECT generate_series(1, 100000);

 

DO $$

DECLARE

  s timestamp;

  e timestamp;

BEGIN

  FOR i IN 1..100000 LOOP

    SELECT clock_timestamp() INTO s;

    UPDATE test SET flag = true WHERE id = 12345;

    SELECT clock_timestamp() INTO e;

 

    IF i%10000 = 0 THEN

      RAISE NOTICE '%', e-s;

    END IF;

  END LOOP;

END $$;

ROLLBACK;

 

The output looks like this:

 

NOTICE:  00:00:00.000525

NOTICE:  00:00:00.000992

NOTICE:  00:00:00.001404

NOTICE:  00:00:00.001936

NOTICE:  00:00:00.002374

NOTICE:  00:00:00.002925

NOTICE:  00:00:00.003525

NOTICE:  00:00:00.004015

NOTICE:  00:00:00.00453

NOTICE:  00:00:00.004976

 

The problem only occurs inside a transaction and if the same dataset is updated. I´m using PostgreSQL 9.1.15.

 

Jan

 


Re: Performance slowing down when doing same UPDATE many times

От
Chris Mair
Дата:
> Hi,
>
>
> does no one have an idea?
>
> It may be a rare case doing the same UPDATE a thousand times. But I´m really interested why this is not happening
whendoing DIFFERENT updates. And, of course,  if something could be done on the database side to prevent this behavior
incase some application developer does the same “mistake” again. 
>
>
> Thanks
>
> Jan


Hi,

in an UPDATE operation PostgreSQL has to create a new tuple and marking the old as unread.

A long time ago, what you see here was very common: for a heavy update load frequent vaccum
was recommended. Then, in 8.3, a feature called HOT (heap-only tuples) was introduced that
made away with this problem.

I'm not 100% sure what happens in your case, but I think the problem is the updates
are all in the *same* transaction. That is indeed a rare situation.

Bye,
Chris.


>
>
>
> From: Jan Strube
> Sent: Tuesday, February 10, 2015 12:03 PM
> To: 'pgsql-general@postgresql.org'
> Subject: Performance slowing down when doing same UPDATE many times
>
>
> Hi,
>
>
> we recently found a bug in one of our applications which was doing exactly the same UPDATE operation a few thousand
timesinside a transaction. This caused the UPDATEs to become slower and slower from some milliseconds to some seconds.
Wealready fixed the application but I am wondering if this might be a PostgreSQL bug, too. 
>
>
> Here is a simple test case that performs and benchmarks 100,000 UPDATEs (benchmarking only every 10,000th to reduce
output):
>
>
> BEGIN;
>
> CREATE TEMP TABLE test (id integer PRIMARY KEY, flag boolean DEFAULT false);
>
> INSERT INTO test (id) SELECT generate_series(1, 100000);
>
>
> DO $$
>
> DECLARE
>
>   s timestamp;
>
>   e timestamp;
>
> BEGIN
>
>   FOR i IN 1..100000 LOOP
>
>     SELECT clock_timestamp() INTO s;
>
>     UPDATE test SET flag = true WHERE id = 12345;
>
>     SELECT clock_timestamp() INTO e;
>
>
>     IF i%10000 = 0 THEN
>
>       RAISE NOTICE '%', e-s;
>
>     END IF;
>
>   END LOOP;
>
> END $$;
>
> ROLLBACK;
>
>
> The output looks like this:
>
>
> NOTICE:  00:00:00.000525
>
> NOTICE:  00:00:00.000992
>
> NOTICE:  00:00:00.001404
>
> NOTICE:  00:00:00.001936
>
> NOTICE:  00:00:00.002374
>
> NOTICE:  00:00:00.002925
>
> NOTICE:  00:00:00.003525
>
> NOTICE:  00:00:00.004015
>
> NOTICE:  00:00:00.00453
>
> NOTICE:  00:00:00.004976
>
>
> The problem only occurs inside a transaction and if the same dataset is updated. I´m using PostgreSQL 9.1.15.
>
>
> Jan
>
>
>