pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed

foreign key locks
74+ messages / 13 participants
[nested] [flat]

* foreign key locks
@ 2012-06-14 16:41  Alvaro Herrera <alvherre@alvh.no-ip.org>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-06-14 16:41 UTC (permalink / raw)
  To: pgsql-hackers

Hi,

This is v12 of the foreign key locks patch.

I gave a talk about this patch at PGCon:
http://www.pgcon.org/2012/schedule/events/483.en.html
There is an article there that explains this patch.

I described the original goal of this in the thread starting here:
http://archives.postgresql.org/message-id/1290721684-sup-3951@alvh.no-ip.org

The patch itself was first submitted here:
http://archives.postgresql.org/message-id/1320343602-sup-2290@alvh.no-ip.org

There were many problems that we had to shake off during the 9.2
development cycle; this new version covers most of them.  There is a
github clone here: http://github.com/alvherre/postgres branch fklocks
If you see the "compare" view, changes in this submission that weren't
present in v11 start with commit 19dc85f1, here:
https://github.com/alvherre/postgres/compare/master...fklocks

I know of one significant issue left, possible cause of nasty bugs,
which is the way this patch interacts with EvalPlanQual.  I mentioned
erroneously in my PGcon talk that the way we handle this is by shutting
off EPQ recursion -- this was wrong.  What I did was shut off
heap_lock_tuple from following the update chain, letting it walk only in
the cases where it comes from high-level callers.  Others such as EPQ,
which do their own update-chain walking, do not request locks to follow
update.  I believe this is correct.  This was changed in this commit:
https://github.com/alvherre/postgres/commit/e00e6827c55128ed737172a6dd35c581d437f969

There is also a matter of a performance regression we measured in stock
pgbench.  I have profiled this to come from GetMultiXactMembers and
AFAICS the way to fix it is to improve multixact.c's cache of old
multis.  Right now we ditch the cache at end of transaction, which was
already considered wrong in comments in the code but never fixed.  I am
going to make the cache entries live until the oldest Xid in each multi
is below its visibility horizon (so RecentXmin for multis that only
contain locks, and something like FreezeLimit for multis that contain
updates).

I apologize for the size of this patch.  I am not really sure that there
are pieces to split out for separate review.

-- 
Álvaro Herrera <alvherre@alvh.no-ip.org>

Attachments:

  fklocks-12.patch.gz (application/x-gzip, 88.4K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-20 14:28  Jaime Casanova <jaime@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
  0 siblings, 1 reply; 74+ messages in thread

From: Jaime Casanova @ 2012-06-20 14:28 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: pgsql-hackers

On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera
<alvherre@alvh.no-ip.org> wrote:
> Hi,
>
> This is v12 of the foreign key locks patch.
>

Hi Álvaro,

Just noticed that this patch needs a rebase because of the refactoring
Tom did in ri_triggers.c

-- 
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-20 16:54  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Jaime Casanova <jaime@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Tom Lane @ 2012-06-20 16:54 UTC (permalink / raw)
  To: Jaime Casanova <jaime@2ndquadrant.com>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-hackers

Jaime Casanova <jaime@2ndquadrant.com> writes:
> On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera
> <alvherre@alvh.no-ip.org> wrote:
>> This is v12 of the foreign key locks patch.

> Just noticed that this patch needs a rebase because of the refactoring
> Tom did in ri_triggers.c

Hold on a bit before you work on that code --- I've got one more bit of
hacking I want to try before walking away from it.  I did some oprofile
work on Dean's example from
<CAEZATCWm8M00RA814o4DC2cD_aj44gQLb0tDdxMHA312qg7HCQ@mail.gmail.com>
and noticed that it looks like ri_FetchConstraintInfo is eating a
noticeable fraction of the runtime, which is happening because it is
called to deconstruct the relevant pg_constraint row for each tuple
we consider firing the trigger for (and then again, if we do fire the
trigger).  I'm thinking it'd be worth maintaining a backend-local cache
for the deconstructed data, and am going to go try that.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-21 19:47  Alvaro Herrera <alvherre@commandprompt.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-06-21 19:47 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jaime Casanova <jaime@2ndquadrant.com>; pgsql-hackers

Excerpts from Tom Lane's message of mié jun 20 12:54:24 -0400 2012:
> Jaime Casanova <jaime@2ndquadrant.com> writes:
> > On Thu, Jun 14, 2012 at 11:41 AM, Alvaro Herrera
> > <alvherre@alvh.no-ip.org> wrote:
> >> This is v12 of the foreign key locks patch.
> 
> > Just noticed that this patch needs a rebase because of the refactoring
> > Tom did in ri_triggers.c
> 
> Hold on a bit before you work on that code --- I've got one more bit of
> hacking I want to try before walking away from it.  I did some oprofile
> work on Dean's example from
> <CAEZATCWm8M00RA814o4DC2cD_aj44gQLb0tDdxMHA312qg7HCQ@mail.gmail.com>
> and noticed that it looks like ri_FetchConstraintInfo is eating a
> noticeable fraction of the runtime, which is happening because it is
> called to deconstruct the relevant pg_constraint row for each tuple
> we consider firing the trigger for (and then again, if we do fire the
> trigger).  I'm thinking it'd be worth maintaining a backend-local cache
> for the deconstructed data, and am going to go try that.

I had merged already when I got your email, but merging that additional
change did not cause any conflicts.  So here's the rebased version.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachments:

  fklocks-13.patch.gz (application/x-gzip, 88.4K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-23 22:38  Kevin Grittner <Kevin.Grittner@wicourts.gov>
  0 siblings, 1 reply; 74+ messages in thread

From: Kevin Grittner @ 2012-06-23 22:38 UTC (permalink / raw)
  To: alvherre@commandprompt.com; +Cc: pgsql-hackers

Alvaro Herrera  wrote:
 
> So here's the rebased version.
 
I found a couple problems on `make check-world`.  Attached is a patch
to fix one of them.  The other is on pg_upgrade, pasted below.
 
+ pg_upgrade -d
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/data.old -D
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/data -b
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/install//home/
kevin/pg/master/Debug/bin -B
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/install//home/
kevin/pg/master/Debug/bin
Performing Consistency Checks
-----------------------------
Checking current, bin, and data directories                 ok
Checking cluster versions                                   ok
Checking database user is a superuser                       ok
Checking for prepared transactions                          ok
Checking for reg* system OID user data types                ok
Checking for contrib/isn with bigint-passing mismatch       ok
Creating catalog dump                                       ok
Checking for presence of required libraries                 ok
Checking database user is a superuser                       ok
Checking for prepared transactions                          ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows on the new cluster                        ok
Deleting files from new pg_clog                             ok
Copying old pg_clog to new server                           ok
Setting next transaction ID for new cluster                 ok
Deleting files from new pg_multixact/offsets                ok
Copying old pg_multixact/offsets to new server              ok
Deleting files from new pg_multixact/members                ok
Copying old pg_multixact/members to new server              ok
Setting next multixact ID and offset for new cluster        sh:
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/install//home/
kevin/pg/master/Debug/bin: Permission denied
*failure*

Consult the last few lines of ""%s/pg_resetxlog" -O %u -m %u,%u "%s"
> /dev/null" for the probable cause of the failure.
Failure, exiting
make[2]: *** [check] Error 1
make[2]: Leaving directory `/home/kevin/pg/master/contrib/pg_upgrade'
make[1]: *** [check-pg_upgrade-recurse] Error 2
make[1]: Leaving directory `/home/kevin/pg/master/contrib'
make: *** [check-world-contrib-recurse] Error 2
 
I'm marking it as "Waiting for Author" since this seems like a "must
fix", but I'll keep looking at it,
 
-Kevin

Attachments:

fklocks-13a.diff (application/octet-stream, 719B) download
diff --git a/contrib/file_fdw/output/file_fdw.source b/contrib/file_fdw/output/file_fdw.source
index 6f906e1..c01f8d8 100644
--- a/contrib/file_fdw/output/file_fdw.source
+++ b/contrib/file_fdw/output/file_fdw.source
@@ -191,7 +191,7 @@ ERROR:  cannot change foreign table "agg_csv"
 DELETE FROM agg_csv WHERE a = 100;
 ERROR:  cannot change foreign table "agg_csv"
 SELECT * FROM agg_csv FOR UPDATE OF agg_csv;
-ERROR:  SELECT FOR UPDATE/SHARE cannot be used with foreign table "agg_csv"
+ERROR:  SELECT FOR UPDATE/SHARE/KEY UPDATE/KEY SHARE cannot be used with foreign table "agg_csv"
 LINE 1: SELECT * FROM agg_csv FOR UPDATE OF agg_csv;
                                             ^
 -- but this should be ignored


^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-25 03:24  Alvaro Herrera <alvherre@commandprompt.com>
  parent: Kevin Grittner <Kevin.Grittner@wicourts.gov>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-06-25 03:24 UTC (permalink / raw)
  To: Kevin Grittner <kevin.grittner@wicourts.gov>; +Cc: pgsql-hackers


Excerpts from Kevin Grittner's message of sáb jun 23 18:38:10 -0400 2012:
> Alvaro Herrera  wrote:
>  
> > So here's the rebased version.
>  
> I found a couple problems on `make check-world`.  Attached is a patch
> to fix one of them.  The other is on pg_upgrade, pasted below.

Ah, I mismerged pg_upgrade.  The fix is trivial, AFAICS -- a function
call is missing a log file name to be specified.  Strange that the
compiler didn't warn me of a broken printf format specifier.  However,
pg_upgrade itself has been broken by an unrelated commit and that fix is
not so trivial, so I'm stuck waiting for that to be fixed.  (We really
need automated pg_upgrade testing.)

Thanks for the patch for the other problem, I'll push it out.

> I'm marking it as "Waiting for Author" since this seems like a "must
> fix", but I'll keep looking at it,

Great, thanks.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-25 03:47  Alvaro Herrera <alvherre@commandprompt.com>
  parent: Alvaro Herrera <alvherre@commandprompt.com>
  0 siblings, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-06-25 03:47 UTC (permalink / raw)
  To: Kevin Grittner <kevin.grittner@wicourts.gov>; +Cc: pgsql-hackers

Excerpts from Alvaro Herrera's message of dom jun 24 23:24:47 -0400 2012:
> Excerpts from Kevin Grittner's message of sáb jun 23 18:38:10 -0400 2012:
> > Alvaro Herrera  wrote:
> >  
> > > So here's the rebased version.
> >  
> > I found a couple problems on `make check-world`.  Attached is a patch
> > to fix one of them.  The other is on pg_upgrade, pasted below.
> 
> Ah, I mismerged pg_upgrade.  The fix is trivial, AFAICS -- a function
> call is missing a log file name to be specified.  Strange that the
> compiler didn't warn me of a broken printf format specifier.  However,
> pg_upgrade itself has been broken by an unrelated commit and that fix is
> not so trivial, so I'm stuck waiting for that to be fixed.  (We really
> need automated pg_upgrade testing.)

Well, I ended up pushing the pg_upgrade fix anyway even though I
couldn't test it, because I had already committed it to my tree before
your patch.  If it still doesn't work after the other guys fix the
outstanding problem I'll just push a new patch.

In the meantime, here's fklocks v14, which also merges to new master as
there were several other conflicts.  It passes make installcheck-world
now.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachments:

fklocks-14.patch (application/octet-stream, 89.1K) download
‹ÓÞçOì<kwÚH²ŸáWt˜;1„7Ư<¼KlœpÇ6^ÀÏIru„ÔM„ÄHMüß·ªº%$!pöܳçÜë“ð议ꮮgw	Ý4V­NLŸ©uͱ}××
Ó⊡ß՝…?_øá÷šç,\³ñ¦yÓÖù=Û7Žû¼Y«i¦q¨²f£±ßnç«ÕêæTóåryÊÿ;«6š•VoÐÐúƒ×Œiªm;>Ó¦ª=áÌp\nNlæ«c‹³‚:™(šw[ȳÓîywÔegƒþ“­ì÷ÝA—©ì®áM~[”C@y2b¯âHÏúv}uÚ
bý³ õM¾ —£–`õáÇLCs¶ð¸ÎîLšIº¼Yý·îA~ܞ;ï]vYóõv‹dÛüýOd•>ó§¦Ç¼©³°tœÌf¥çõ4qž«nÚޜk~}ÊÕ¹±°5¯¦E„)BŠok¿¡i†Q«éG­ƒ#}œ.¾Y8âb›Eâºß"q¥7hÀ~(¦Ïg^ñêƒrv}y2êõ/•Îàð”g¹\Î_̧ºYüð£ÅÜâðAçn‰]ÁØÜïÁè"â©0S/
ËiÜ­j-¸÷¹ý†^÷l· §ª¿˜%AûÍÌ´‹‚R	0T—ã÷6¯ÞGƗ·?Pï("KØßʼn3›©¶ÞӗxXýˆ‘êÂ}«jìU=ŠþÑ_9¦íÿ¥ÀP=öÍ\]Ž8L™ÐÞ´
g¦zßZ0(]^'Êb>qaޢɱtÕWã›
ܱað½v­f¨»Ö!ϐØ,$	‘ÍC™Ý=ªì³2¼¢ÄN8°CÀ(T<±°­Kf¯4ñ¥ÂƎc1˼åŠ6åÚ7”c0œn4üÕ9‰¹ÜÄñ•{S^ªåñx‡í(G:fË73ºî`w*:˙(Y¤°Ïã“ôNߊCŽ´ZmdI«µ_iý$Sr9Ù[=Žq~úmnûŠ}ï&x¾ÛZ€xçR—üñÝÍ7÷ˆ:Ça’Ì4X±8Ãà_q¼0L»Â
çªÏ=ô`@|ŽÒ¾ã±K~ï_ ?oTÍï鯥{ñŽ]^ŸŸ—áwÒd‰L›ºÅy…í¼ÞA
§¤½bûñÁ,nÃDÙ[ð „ÆOÅdÞ:£Î9ÌåWý5‹¬˜¹$‘ƒv±¹ë€×™}±¦(èq%$7/—ß BÐi—Ïœ[ӞàtÐ+»¨Ôåõ
¤'ÆÓr..Z‚«åŸæjß0<îÿ_àªT¼t®ÊÎWÙ®^¨÷æl1c´Õï?ãv‚‘É2)LWÝm»y(ÜíóõXm¸œ-M™qÏOëI7<»å®i<@À¢úìŽ3X1Ì؂3R}Ç}`€A’k¶ViŸ_F¶ùE ×?~›žèŸ…´†ßˆË0XR|±œ?{ùRXZ†0€yØ?øŠm7›hùÚ»{•fë'-_¸:X‘0…Kyt¯úƒˆ
cVR½˜
ÊÅú½SeڃrqD¨Ç6Ø"P`-DZ"g«°
æ`íÙ;”Í
Ã-aÐÎ0b½S¦ÀaPې[r,?fEQˆ D>0ŒCC«ÕöŽZûíÖڀ#†#3ވA‘Î6[•V|ßGÓ\üUl~§8ã?!¬öŠ·BfQóåú«|r‘SnqŸ“ÚM€µ6ócÝtaêÒâ1ÃufY(¡ §2G-æ„
ù
ƒ3Ø`‡™~
á Žô|Õ75†sÊW‡¢á>ÞӋ©Ëɖ©GLI!äEa^E¬æ;
’r@Là˜«þôóEçæêÃUgôñë›™‘QŽàÈìÄá+°ƒ5#.Ðr!–6IØ<Fv‘å‚Ù
ë5wù\ÁÕ/¼b¸ŽƒØ*†â=úØ“qدx'É1Ϟ»Àn£c	™ÿäN¢µ„ÐC‰Â&À$ziÏjó	Ν›gŒ‰!ÎXë
NÑ»‚“ڝùè#hÑé•J˜P­úk²[Ì¿u!¼Kyýt¿È_Çg„ÜŒ±e…#‘‰GWùár9ΏV$‘­2 †,ɈÊ?ǹ|L%Àh*η¢”’˜p€ü¢lEDX‹Ê°Ç]pØ)Røk<ºH˜
¿çš1Õ¤ˆK«ˆì Â®G½óÞèå¼ëëw+yö‹i€ý4Øï½ËÝvƆG݋\÷G]d¬\gðv||j¿l¢Ða"w +ﶛ•&Å5™Fg=¹/ë
…{2uÎêðú«G`mÜ_CgŒ%44¡IÎÈèP[ŽÈNl{ù}tÔô–³Mïwòç[Ø6°“+Öºeà>Wzðö¾«Ú8{Ó±ÄhŽ‘t2âÐ!&rCîK›™@ŽÝpÜèèBÓî5(ßß­´÷7Øü4}MáoR©]ðŽ°g@øæOi.è%‘}ªËeàkÆPÜu“ÎGƒ+Ou<.°	‹ï;N!æÀµ
-c¦ÇÆOE0-q!Հ—PàhšD{m½uÇÞñMÕ~ð§È[<K¼ÃÁ\Ç­¦H){ŽÀFãd÷£êû|6÷ÅxUg´\gN,Pm¨-|ˆ6:'ªÑçº4‹Q3K¢T_AbÇïØÅõù¨wÓ9)gýÁEgtò±sù¡«œtFʧîÂDTšèŽ>bÊ@Ӆ<Ü˺Cq«ôàk¡g|6æn-çKYÁð%ŠÈ¤	|9'Ä9
{8Ç̓¡ôJH’ˆÛDh6ÚA°Œ_’ðrAbƒ'}›r—ƒöaa$u´áä‹f¸å. Ò¦51ŒÒà¤Ý¯«fŸòó„åý"#	’@ÔU0¸Õ>ûuÁª3x­À‡À@¨ÚýDÉÌK´Q	CxnºaW¦Å3õmàq»*¬‘J=P>¢æ™NÂÿß'²©båˆ
Œ	Ñ'„é÷ÀV„b"ÄɴŽƒ¦¢;GÓaâyŽ9›;®¯Ú~h%$g):x[ÁÉD -)!™
q³2~XZ»˜Ó¬"LOh{@r]î/\ÔÅÈz Ææ¯wM®¯—ÆõB÷¿*nÏácmçNÚläޝjóѦßÉÍZçb8–¤ä÷Îy8–œøÆÚ¼EB=]›æNeB}8n5ö[ÍZíPßS
}o›„zºQB=wN]ð­ÙÀ€
,!G!£ìSÜ­
{þ“@bá/±š6gŸzÃÞ{Á‹Î•r2è?;gKÔj4›ƒÆn3’‡ÇÂ
àYèÉõˆ~ù ÷„:¯E]H®q@ÙÖ@‚Â|YWÕ¦ # r{yð™ÔŒ<©žƒZx'ƒ‡„
T<3±æ@°æà@\nøsŽ±º
Á“ÌÝÊ&‰³o™oV[AÈ!èJïp°£œÒAÊèBEGǟц±åhß¼F›,՝plʐU×¹£Aõõ§³£ñS½RF½ýÝãq­fðÃF»µ›%£«ã“ò¹
Aç‰t<+g/ú§×ç]elNrïØr@žõßÿ÷0k«9¸ûݛQ÷rØë_²|õËXSµÚ¬5jÞ_V¬maÏUíXn=ìϗSÇ6WÆ|zGR˜ªi X]»ÊՇ›ažAú{Ò¿<ë} ZŠædíÖeÎ •ÑYÐy´—$
3Gï
Å~7Äރjúaƒ6º®óÛº½°¬ìMͤ…›Ü¨4@ÇDªŠF‚m³44
ù2ÌŠ¹¥‚ý€xÂÓ\¢qô¸T
BveàæBÄä·¦ÊN]¬Ge%_þµ©Ã®!2)$;#[Y@Gn9ª.ìò«Æ¾üµ0}œOç|¶(m;ô¯Xp‰é(ú`wѵ­³Jé]¢)³Õ$H
>k&ú×#†ý\W’z§•\X&¿$€\vàwôŒ7Q q©€'öH|¿-aÀÞyøòùkƋà
éòhš+PL8gž#ÆÞå¨û¡;øüµN»~‹Ö¸²üAwt=¸²awÔ?n@¬­!ۑO3/;ݝ
ÛY²n'_>GrÝùÐe'l8ôNFëeš
ÙD
HöÅq–ž¥kêQãh|ЮդÒeÕ4䨊KÅ$gViî±2*¨Yu#54¬J´ÿ]Výi
ƒùl£ÕM” ¤ §g#˜ÖRÈû'peèJu]©n +Õm¥¿š*ýÕ
¤¿úÓÒ¿±«ÙÜË´ŽGFûy^fÕÁìmì`þ“}Ëÿ›ÿÿ@óŸ¸(M….JcÎõV­ÆÛꁱŸQ
›…cá—¥{T—¯ÍÝÔÜÈ·mͱ3ۃ\á‘]<œBºMÇ»2ÝÊå:¾½˜)¾©çr•æû™zŸË5WÚM63×Z
™Ëí®´“8är핎9
ØÃtŸÊèòQO©‡ü.œ]ó rpZßjƒÞ7‘
O£ãzMԆ¹"ÜMÑL±~Þ߉¢Ì	÷ñÈ°ˆc*ìÌqïTW—Sº‚ÁñJ:œú8^+î
orSß[йÆhy¬ßÓr”š1qkîçrA­ ¬€iÒñ唎ÙÙxa ²Â?96[‡°Ï0¹w=×UŸË¢Æs€}OÃhòÕc×S4ÀSaï¯Ïκå¼ò›BÅ¿òúŒN§³°
¶`U#ÝÐeøc¸²p]ȳ—e—tVŠÅfQª¦Ö{öGÐÑéz¹ÆÞe.19™rH%÷Ôd"`ñÉÐNà–Di¦•¤.‰Š1Á®aQS´7Zý)«HÂ3GU€¢kæÝ
ŠŒ<öóX”¢$
 À8É~‰çB}xÏ%”¬”æ'Š˜oUËÔi(¢ yW}¶ð¢Ç†¸Ý‚Ñ[!ʏr¹U¨mq‘c/Š!;^²ÝΕrsѹQz—Ÿ:ç½ÓÒZ¸¡B‡>KÀ¢Ø’w	‹iQÏèØÅü‰°ª¨¤¦¯^‰]QÃ,¬ /‰ÆRjqüõªÄæ SŽVœ=ˆý&0ZނÈR ,9¬lÄ*¤Írùëg‰	q¶°i¾'@ Yë,üJj™±[F¢t:4Λ¢ŠºÐ¾õôäª@(2E9¶_d:NɌ”„žÇÙ0¤/æŐª®²š/žïÞã)®y˃
A‰]º<
âÃøÞåêaC…‰TY¨¤(yŠ†K|›s$”àÕ½CIÞ`þå”ùG$—rÎrͤPð¿ÖǝÑ+ôÖb±A¸°Òògì›é}BsC¥Ç7ä¯TûAš¬SäxŸÃïMÏ÷þ&sË'öO܃íÄi}¤ ïB\+>ñÈAdë*ì%"	0ÒݓÀú‚Y7"¨Ù+ys)p"Þ(ÊÁEù]XÈ*ºbÛ%#£ÔEJøsæJqwa!LVÏ“Ã…Ä¢pƒ
5s&Ez„%èn¸ë:Á͘D]ŒÊRq)Lݛ“sÒxö#bbXDÜ~ëþ1ü(‚‹R)p OX}ŠBú—ç”J¥66wÓBŽ¦§70,Š,I\°E˜›Ð>Øz܊Â÷ÆcáMÅ¥„ê/Lð5L^ È<%cä<Ž›6áQ’©+‹]‘¼
t‰ÅÕ!Í4ØQ	Y™5×c
ôü!´`6
ߝ„0x‚u+¥ð¥
ٹݰùzb’qx!Zü“Œû“½뇏å²ôEˆBGò>l_Âq>DgF˜XÝz¸yœ8©W<Šñzö•ëL\Èm‹8ƒÏ~
uae9K%i×*œ@hšC}JãAÐG…zdÏlKt´(Տ	R%¤Õþ@–*K¶$aâ|^rz-ä<ŠR.ä1˜hèR)ÿIøPÉñpU«‹)¸ޫÏÛÈ{°¸W¦¾ÜÎ,ì’ea²Ž‚Ü~ÀY»§‡ÑÊÙ,‘\Žãë©MY1‚GX·PX¾‡lÆ⇥‘ØoüA„ý¯—ö?c¾Êltïrc—«ßÞ<IdS
ÏÃIü«höü•Àèm=›…ØëiØóøµ!dÕ:*O	m ñ›jĒȪö%”åim™Gµ……5è6CA>&(ÖUoléiÖó1æ†SLçBä¨oÉ2¡q”i@×ÀÍWÐѳYò•™HúÅ7Âl™¶­ËÛ¾ÿª?n‘¹m’‡3N‹á³BŸ”œ-+i\M®!HÛRh¦NѨMˆ71–OÓƒøKÃþeŒ	UTŽMŸ
Þ^³ PלÙشÃդ
§Š§äPD™ß|þ#>‘TDŒÃªÂµëÛj@94bS[2h[ZK³Ÿ a´ÍMºqúÆè	vf;˜[ËcäžbmÜÏð;;ïYš„¬´æ©#’VÀ)ñ›¸3Ê û©ÿ[÷ôY;ó$·6E”Dò¸IFö|«µâš63c©v,+IÚÜ,ÍSÍR˜©¯F±h¯dXý(OP7»^¸¾$¥ÏË7XzXnÉÄ5w5âDý&擧æøНŠOi,fÁÏ7¸tÕ=»þƒÅC‡èN,®Ú áâÑ5™`‰£\fB‚•<ÿ…Ö0§œÓ³¿¡„Hˆ¶J¾‹³~<¤·ð‰‚cw²Ä—6Ï߈Òb0–*þ̉ëWñP#}Ç}ðPmû½‡lwjÐZ—{1œ)âBT¹ìތŠøS#š_a‚1%ù»Û\sʇ"Ö^A
¸ ”e¬6÷Ûµšn¨{‡úVWžÓFŸV”»ìá¥?Ýù³_¢XXßjciižžBAÃöŽí‹ïðJ¼jñ[n…wßh¬°BÀwòU*0N‘µ©8®YkìäË©͝<^s/,NÏ-ѽ<tü—eâ3õèí3^9â¶ÓêˆóÃø¶èŽV÷\ø?™YÑ%ãwàËSÝrv†ÚÚ­ÕöŽۚ߄'Þ?	B՚m|ê»ÜÆ_¿ˆ+1•®…çŠà#¸›—¿ëó¶Á}8&%Åòüâo†L^…
ª·u
#‡¼­C[ø…>Wc¸ÞŠ«nÃä–~Võ¼­G›Cœ‰¡yŒ³~[§Yp–ésWµŽÅUÆÛú1Uä˟“Ašæ¸Á `©Á ðB#·tÝ84AS®·Y/{z½ÜÍX,KY,„¤Éµ&¶&þøY°5.®0þhx}úy`-ĉr²¿T&´Ÿ-'±ÉxËÙx¬8“χÙ`;yÚdJë%©ü|I*§0W”¹$ù‡DÇ)Š¡Ö/¦]M%@•­0TÙª°¸œÆ›–&¶§áZöÆñ‡íµÄ’$CËÁ×uŠqÇ¢Š–î®24|%˂"òAÏû‰(f;AɶÅ.7ê·¸æ§ÚâD·´Åüè𨱽§ëÆþÞ¶8‰ Å'AÈïQéüž¨—¿Çö™uðçbØio8ê]RCÿ’aƒøÜR5NÞG³TÏ{W˜«.ø+|4ê˜ßã㩱€œþÌÎ{½û¾
=PŒ% c˜Îå‘}
põÏΆÝÑ:Tz¸ITŸÙ ÿ; „×!ûºÄx֝|„ٝõÃôc??gº_
O„Ê#äHU%©þäÛý?÷H«ZG|¾‚ÁArYö/öþ¼»äH‡ÿ¦>Eµæt7(
î¢%ÿ(ŠêækmCR–f<><E HÖ4€‚Q€(zÜ÷³¿ùĒK-HªmϽö™iI¨¬¬\"#c}¢Ýn›ù˜nÞ½ÿt`VÚü•ⓥßuÀ}æۅAü-rX~¿å€ŒÄù»ñõ$Γ7ț\ô€:ª]á#ˆÁºHèDf—Ï~÷Tú4ýsFÎ.
ä™?(#çìàå›#"cìÆýgf$iš‚ð½|Š‘Ù+
]Ø«ÿøÒãÑðwOõ7\‡AZ{÷\9l±·‰þ\ñæR_(Ä‚×TX&ÂYÇI/5Ü·OéҖ—ö8Z곐ß=Õ“ !é™Åj¨b̅X\˵‹ø*NG€¿ÉF=Ö1jnŽ¼ES£ûüî«aaÑ 1?œÿeÐ2âP‹[µHšz,pžë@6œçÞo³ý²×÷d3‰µ‹Dæ®PY»ßF“þ’̍]-A®«ˆ”ÖIT“B‡+­ä‹H~1ËpvMY ¸§æn<u·€ÀŒÄô—Y:‘ðÙû;$Hêl>Q–›G¶EºÑ‡2Hñ”¹Us£7Q"´Q¢"o6
„÷:2“£­a
+Ï,©®¶i۟ò¾ƒÈv»À2\ÛÝè0‘ËÓ^š¸2IYƒ„éßÌ©I‡	Tk¤?ZxÑçÏí!*PäÇwí.Ý×I|~·fTOóÛQ6ÎÓüÅØÊñFpÏ2<ÁÙv
·§ïO^0[}ù!Ó#Áb>¨ÚÕ\²3³3Þf¾¸ä§îĎ¹çych.Eû:PZÚF¸P<p
Ý,]oÍx:5DÎf¥˜{ÉgN~“xQÃí“Qoå’½ƒ)_'9qäO¼Sü¶÷ˆ®…<‘1š3—š3g¾9
צŽÇƒ[ÍoÓ[vÉGj{×öîöîCŽ”wNùªö/f‰ÜÖìUaå¼-zá0ŽyëºZ†$j®fúz•xDàƒwN/äHÌüÄß<–÷t­¥…9‘éh<Ãâ+”Þi«I[´Û!®·»ùãzHð89­ÔTþÅùþ¯ä|!Ë«<Ý Î½ÎøÇ^gû_üãüãB{Üæ3%÷ê˜d¯.¿¶·ÑýÇq’£Ï‡GþÅFþÅFB6²EbÈÞöú¿ØÈ·c#|ÖîÊCì[eÒélrՎÎæv³KÉ{ßؔÇ*ß$¹ÌÍíÊ>þNÿ¥ýçOÿýMË,M‹W´E«ó˜7ùwÓt
s©¢E¿˜KñO瞷C¢æß=¥žØžsŸ.E)•#)üÐ.w£ãññþUÓÖ}ɕ»+8ÒG
¾3­†/ÔÖßÓ¡¾Ø‡Vrŗ—f‡#øzK銭Y0`Á²Ào™Þ³‹iœŽ× ¿dJ`ž¨Ô[^
Wj—£À_£kú R¾³ÉðÙ£µßÙ»æÑZøî·7䚯=õ>WÇä¢ÊI-9!>Ü[»ªT%NM¶;þfUÏ¢iKNÓa:ˆ'à«ÓªÝ)Ü)KíÊ·þR›PZT:tå
a¥Ts¶ ÿ[Ü9éc	AÄ(ø‰ºåii²ÙÕâ>˜+‘]1En¾ù`µÍ7†|v.I
O'ß*æ¦P$”‹[MÞÞ!é®o4»ëÿ©g`fô0çQî¨(ùÚKÆúÖFØRl™}²¯O'Ùè*™<cb¢ÈE¶¡¸öž•I’÷#çy°£ò%ù,÷žq6{Ž¸lz“ŒÁý~Jns¼d¾n{¼-5›P^;ÿö–ö‚?
?6wÖAž¹¥¸¸
e^®±…7)ÔÉ”S›é-j,ãÑܧh„˜¶%×ôÔK&`Øb†aËÉSÜ!;,ÈL¢9½½l”§ýÄCì¡üY
†ÉwœåEË=’£Qd£ô/3„¤Á×Ë»0ÄZ¶ÓÍÄòÛRZ¿˜k¦a&lˆpšÆY;t  ¦ÎˆÜŠùœzã^mºâXÃøV€õ´;šÑåŒîîÀNŠòɂCŠõPö<§6
‰ñ!RÂhë<±œ‰û0ô`öîÀ©aR5»Ì}9½@ŏ“	Xµá2ÂNv·™t·ûÍNìy¾7Iáèˆ
©cŽHS{¢‰"¸ÐJÕ«þñ>-²PÙwÑòk^>ÙúoîM4ƒÒ¹²Wí̇gƒ6·™…tEƒ)ŸPf N¶W®¢7©Z…fåcÝ4ҙk;ñ·wÑ;ËtPýj‘ÃãiIo┋ ˜«XvÀ}0ˆ¶Ü»yÊ3,Dcã±íW4`AÈ^ñrðHÝóáDàßHׄG!ü¾ræööš›º­õæÆÞß÷Б&~|©ªkEua—¦G⽋ý¬‹­r,úP…êˆìa’g£Á-df/i³Y» {ÅõÅyŸ‘‚tÁ-ô6	®«’‡~›†0ÊcÁ›å³x@çþ„5¸ÎdÎ<P‘¤­
KÜ°´•,ç’Hå	YªlÛm}Ð8axÓm+îŒ3ʍǃTÜhї4¹A¯ù좐eãÓyöÛ[~Sæðsv„F±¹&žƒí(pÍñú±{땳½}:>û\
£¡
\ÉaÔsÔãI:Œ'·‘Œ9’åºÍfæÜfä0]9ÓsÖëÍ&´¹lPõ!³h|Hn+̍wÞCùô–°·à“m_övÙ½]ûâ|ÖB‰Tž?‹:K_¸‡¶³Š“«Àx3I¬ïùoG	b±Ifde#D)&
ɱ}‘‘ŠUεaªuuHOàƒ	áÑ41—†!Š†šˆÁ<Ò^
Üq¦~#n‚d(ßkáR,mfÎ¥^OTÀÝÇ°æ~©è÷±›íGd©š¹„1¡EÆ­zCÕàdon✹º³›Ê©cSÚ%[DåX™åU—zz)¶ºE×
îÞрð4)§aºˆÀF×ECöÙuq%ó¢‘Y9¾¤³A—b9\âɼRĽA‚E‹ŒÎc¨”fŽCÍ}
þKÚ7‘¬(^ޗûxˆ£FV½ªÊÆñÕÕ$¹"!lÑ}|ƒ+“ú)ò({
™yæ‘hÓlqv
<ûUA]Âi­•‡TSîjâl6æ¯	bõ·žK?Ûõ’¥þöå*Æs¨Xýwf~/~Ñû†×·¤íÌP~-c
±‹l‘
ˆ{¿¥°"X&嫺i×<7++§$3÷`”ŒÈ¤E"þ"1{d—pçx‘)J5D3I¼E§ò_R³ý(ð‘YWç½£€gˆÌ@WÉTVo5`bÂ{¿IÔiZ–yäÌäžMÂÜæy`MÙ\'¤¢1Ç
u'’)ÅA¸™&4¿qœË´…x¸'Äsû':U4Wˆfåƒ4‡ U9r´@ª›!í	¯—e÷VèSè0½ºž":|‘n.“g”£jn®PX¸íÅš¸‘n¨Z>»ÂEҔ£´mNt-ÔDÜó›R½þsxËlÑ-îj”çR×¾—
:ÑóhKʲ›ƒ+æ”ëހ;3	xR”'߆»Û‚ŽÏЁ¸Î¼­>@*»CdùÓRN#¶êÝòmåDKTM1gŽ$—Ñ´ÎkØÙ]ûâÛ§ã«Óó»§þ¯bWÁTȔÁF¥ÙEž˜‘·Åv0@~ˆ,3Í­ÆZ¾ó©yùµ»NP¢Â·÷|0:}šÍ Y#ãt ɞ¶D‘X€¯ÓÞ5?έ–‚4QêÌN6üfSêdd}óyóqàÅCŠ\]™¥yôÓñ;³‰Õ[Ï{
»Êó¨ã¾ÔÎV³Þ¼Ñí2lrtzðÇ£ïßE€Š'”v‡¼
ÃrÃnM³“÷oÞ¼<8üCtöž^3„Q'‚­fO¢¾éŸE
[d!Æ܁·Ñl¤ö-6LpgtŽüã	³ê-G5¤R‱'BíÞÌ¿­cBt5:º×ñ_ãIŸœ¹¨ê@NSÕàö Ð[.þ¾µ(ˆ³ƒâØxâY6}B0c·&ÒgÄ­¸hp.Jnb–•É3¥0°<;vW]eÐœˆ_Nš#|¬AÌdK/ÉôW±¸Iz•Âøly*Yîȝ(1á¹í£‹€™/³’À‘D5‘•U¦"êƒ%‚Ú¡Œ°eàÀ½Ôh«·rtôz‰ûý	‹âlW'#·ž@YüK:(ýYo
±áÅs’¸G¬Âÿw^¹xØSËÄp$™9àL'ºäL,øDlA<¶Vzے[Î"Çeú•'$óˆöÚ]Ò‚Ô±Xï6%ö}ÌZJ–ç)ِÖ&D“Ùh$°ÁlNŽ^q‡ïß)êìè•w!‡T•	v2KªèÕP0ÌÂ5QKõj¯ßÓ¢vAEö¨]œ˜¬UöWÒý«_fÑoÒO&ŽÍ0ÿ¯Æ[KŒDvÐvžq]̧̜.š×,ÐwÁ·ÊäVí(b cVq”3¡&¬˜ŠP€¡£.dÕ`ŸÜŽÎFl°G±!Óélïì"åv­³ÓÙiv¶=A¡oø1ÉçÙ$o?>ü¨É럌Ø
¨ë÷çÇÐø‘2Ց0s"¡*_îØRSRMUún9äá` ~8¡;bx
Xè¨o–Ê˧ҟåÁ_:eá:&3;›é‰M9Êá(D‡ONߟØh©åø˜÷±”>w'¦$ÒÄ4jÉ8÷ü‹);NÁ^˜IõÂG_âI¦M[°³ÖUÑ\"xæ!!n2’¼éŒŒ‡–É™Tq‡95íiAö
G?ŒÄ]ÉB~÷`é!+}6z
hyB&¡zKµÓš›ýËd«ÝÞI:[Û»…J\ËõÄ©Å˵¥
›]„éñæÆÏoz<8,@´ ø€"F³a3¢Ÿ_%yÑ[ð·&•ˆž¤9ª|¬†.
0¦q©ËIGÀvñ¿Ð‘ÍEŠd
z<˜ŠyâÝÈpÏ¿åg¤ž"Ü؝;ò€åM$Y8ûÒ$¼ÙÖ7ZD™ØÔ§¸ÿßµ±Wä^²áRE^v/zq«²È˒Ÿñ‹¼lp±7êžÀÂæ¨ââÿ¾Ø—‰SïXo1´Ž({jŒ5ìø2Æ@@JÌþÌ{(_F|´fv$ÏF¦ù-{G¦KF%÷¢ÑŒA•quÓXš\ˆ˜8ÉzˆP±j¾8‚&ÅWQ•ŒÒ
åÐir¶(±vŠ™&“!$ýQ>5td8›WO`O$ZËùDZö²Fuù1§R,¸¦fý€fƌ[ßÓ@"
Gè3}3#î³~7Kók¾*f9J jèä£5’fF@ÖX‹"œ¦_
³ÐNm±æÕQâ»ÁQÖ[ӊ²u2q˜Ô-d¥Z¸öÍø¡×˜‹±
*øäŒùKþm‘—‹/Š‹ˆä|½Í)O{À
Ä·bÂÿ’Š:ïƒÏ@RŸÐ±éשæŸD‰”ZÅ$ÒÚ%Àf˜
h?Ä>%P²Ò|Èjj	P1
CwáúPä)™ÖY‰âdÔç^âYzbÚBÑ®¨Ø&sÞ8YÙq†Q¦d2ßì‹‹£­‡eO¾Ä*Ð@Õ!qÙ£5VKRsç’ÂØU\ºW.ÎÈÌ,ېJ-›QOÌüèR‹ˆÎoáVIâᣵ :žN̶˜!²¤]Š9â`v¬g[‚1hӄ<Q”³…s§iψ;Pn®3^‘
Ú e€Ž¸ð–šs-qtæ‹Ó¬g®=šðQÑ5×fªfÉ-²
QÚ5Vå—­Ù'à
Â>0/Mô‘ì)¶;9L-0Úó'ûhÎ×äp)ºÉX—”ˆç*q±KTÔûÑZáLx#÷©šâù${»´ ñGk†d¯“
™žcIÁG
ëB†#érÊ×ûæJΓÔ0(°ÌKsö‰\œa"¹£èšï
!K<FHRì#‘@ÆifÎ{æf¢òs“]sX6’oq¶.iÏÐl:£|¦ìÉEÃ#2LÁR«À_*ÿ#$•šÅd£3OôI©é–"G ÌÖLbZs¯ö™#&ºQæmӌ6ÀÝ_žÓÄð”«éõ³¨2È5Ÿ™­i…‡ï6Èـ‹‚˜½ÜŒt½ÐÑ»JFÃ9p
hÂzrÏ2ì|ŠÃSâ8™9 p6¶!dÒF‘ÿÖJ‘_´]VžÏ[Tö
zBmìGŨ0CÞj¦Ê}{^¾Osº„ÝÌL¦*LL>J…è>	¥Øjóv?ÉIéFƒ¶,‘h‹œ›„_z´ÆTãÆ	$’yÎù—ÿ⻪ÕÆ®í¢“cC^(ōpâ¶95æîb’–e—m	ç*Ã)½å«f®Ð#½ßÔp s¤•.nÀqè®(¼qç*`1M¸ýt}‘Õ‘ý9¶hšÍ2²†*Ù=³lÔûŸGÀò¿ð_¼g^cÙÿÒ{ös•ÿ®þ—î“7žåº1Äìkދ<Ô ¹{ð|&L³”{[’uÊqÜ°B/6áN8DBs*FÞ™
I—æHþ%¹r¨yWO3Òöˆ¬ÔiX‰ˆ¡¬)‘/þû>oâ[–ç‚+Åú€­áçg˜^/q}æcˆB8!ðéB¶s²º2ED;BǟÀî£5°Ø"?Л‡œÇ WÑ3ÈVÒO¸h	¯¦'¡ŽäØC 4¨–ρ˜úËÜ¥Š«àn†ˆÕsHª	ñUVäá;
ÿíÏ–euù냲H5¼4h͊šä¸0·Å—Tû‡çÉ1¹£tîzTíe¦̜׌¼©m4ìŠRÚ¹&ÕXûÊ£/°WÉ&É®ð¢Ð’‡Ú)2uóhÍza–f¢gŽÜ'™aR´>|o
ñ–Šiæ‡!DkVéHB¨Qªpd@ñ]ùp”‹ˆ¸$r%EF
G¥DP¤=Á|‰ŠÚ;â±+£$ææ
ó
Àd©Œ©‘‚è¢5ô1‰éNüŒòGcs¡0ã½ÄW9.Š˜Ág8^	äÈO!9Kïò2ÐchÑwxߐ¹ãëJèÒ3’>|í1ŽÆ³‰“Öq‹`ð‡ðh·pÂTtq2HM;gµ>ØPŒæRB©†ÚËUç¼xìz‘ëœ.GˆËUZ¨ç5e¤Ž‹fŽƒkdÄ9+ÃhydêéMfƒØ¬É’dŒÏ)´ï]¬,VgƒëQ¸T()È-ê^´FËb¿÷>Z¶Þ"³¥Ä¿¨“›4wW¨zM9†ÂŸ¥·¤`³Jè"=\Eº”´M´¡þÏX-T6¸"Ÿ]”
›Z‚`¶5Ž¯0›©‰QÕï\G
sp®¹Ü5*¡(®z:ˆ29û™þ¾^„áKÍÐíI8Ž˜3 %Xcf3ÄÆcËÈÀ”ã¶:žò˜3#âÙ0»8k9µLìN¤1«‰Ý‘ð¿xÛò‘ld0_ ðV^!¶hȋMÉ9±ûó‹¹A­PUÐáeΎ¬mä†GÿnjD*€X37€“
ޛ˜.£Þ$ίE#0»ÐGè=·.]¾DOì6§å¾L¯ÐˆUõDr'ML9x‰&œàÀº;V’!øN_;Œ[ý\‰1
(]±®	vk$Ýi:0þN)™hœ'†‘¸ûNÎãP2¹”u +TeLr^ê?~üø«Ék2,4î0£ªž¹xÁt˜8½
(ã5õ¸Üd“DÓu²½Aføwr%º
­¹ùXÒæ–ÉìÆØ/F¼£·éÈ=‚²a×Nâ
a|NsK¢ô–¥ }ŸÏ‹9ÃِbÍå›Ã$ZeUêk1†Å¿€ÃGd6VÖ—Ÿa*yЧPúõ^¶ÉF$xò¼óìʘ•×”¯ã6ßG"¼L§E´žŸË.º²\‹—è¥
02ï—K§B}9€±Ãª@"UKÕ«?
YsÝš·pdY,}AªCâgÚ'qNeòÎ2)¥eã ð^qÐãq–+Ù¢æ®fƒxúAVK߶EKª>~#


›?+Â
·}1ßäMÇ6ã/۝kÚt0¹-÷p<ÌDw”"AĔtßFoáç¹4<„5ú¶Hv…šj*ÍÓ+E>°UCx
ÚATÈæžê½¾pe-Y*pÏ.gƒÊ±“Ù¨ Wë²ñšñ]ÀêJ.–ïËl6¢DéŽWŠ%8î¡LGú9,#˜zÍnó&KcÀrÈSô÷Ä|žº°Kj­vÖ%‘ä‹
Z¤!€k§wџ¯Þ•_÷}¶©+ܚH\NýZTWà}ûôPnÐ>*?0¯vÕSx¥iµ”.ܵÊ[¬¡g´OØ>6Sšåçج¾µ)ÇË8]²ä‚Aö B~Ò[›¬¾îŠu‡",$K‹èәÁZS.vcG6ÞÈü
â"Eœi§½œGÿ‰‡unö ‰8,/»»ëÝí‹v»¿{ÑYßØZèa;™ïдÍŠÃyÍ{]øÕ‹—ö¨ˆ	U˜‡Ûœ|íÉU:B••s’Fñ q¢¥ëµ†}ó‘ÿþ™jÓãóñtž˜Ws# T¼…þ{)fV(WŸIÒ:—£þI¹de¡ºœòõÏo²«“¤÷a
Iò꜆Àô|Ú|–«ÇàfEÙ®°r<M†R©úä+(‚¶¥QŽ©ÀŒ¯ù…†LïRX¹âÏ¿¤¤ØœSöåEã‰i{^ñT+åÔ~̏¾A­JŸŽj¿êêÏù´®5£×B÷?¿?ûX^6Ù1#iã1|ºÎ¦çP¥rݸ(*¾´d˜µ|š¢³Ej:ÇHQíDzŸF¨$ñÌlPgÛv®zPÕÓn³À(â~ÿ|šÑ§¼7­‹å-”p1zceÒ\hÈk\(aÍÁçÁõÇúA[t½…ùùìôãù	ÇtSEáµçÄ/ƒ½)¤¬GՑp¿¸8]Ú¶¼Ž
‹9ÿlº…àÙð…2¹Òu’ØÕâDQåãnñkÿuÕg
õ"¥lXÓVÑÆ*C¦<rù¨~Ïûíô¡º§ãÁâ/»í¬CTø¼÷Fý@ðd×	4€TÖ(¼PšJié.SwŽÎßïk7Òºª ÔÒ³.—DIŒ~rq9
Ž´ñÁÕwLfy”gƒØõöý«£•kª½nWX«²‚Ð_«ž‚·­ø
¯¢'l¬tf(6¦!Ê96ËiD€|Œí5‚7ìÊ·7	ÅȲҊ„ÀNo2ê-|¥0.#5È{#
Å×°‹WboâÛĸ	uç|ICè"T+O¶¸*UKÈÝ?ýémü5<£\‘›WûPbÌ>Ö²©R–ï€
úMhëk­ÒãVÚ~¬BCŸ<#ýğùµY‡?ˆ“ìfÑŠŸзù“ÛJHs¾þÑ1úʲÀ՟±}ƒµ^æ{öͪçö!¾jè_ˆ½@šŽÖ­)Ý3!0C*Q8Sák%è«ÈÌ|
+W“ÊÚy„Ã+n~sE[U5‘ùk!Ë쯲¥ßl~W+BÜ^«_}vb.ƒ/ÉY 0§Â†ÓV=y <Q6/>.HñäjM­I½¥1çÙ/awÆE< Lòb)»lºŒ­|6%®5ê	fIÄ ÿ¢¡÷õ3XlT@]äÑùËÐÀãÕ&UÎ\mV±¼ôç63îU÷/€gއü8Ÿû~Ê»Ž—š\Uû»~<¢ö“Ý`ÿ¤éöˆ¾~eŽö¨t÷["/ðý;üʧ±!5ÏiÌ++*6_q4õµ?ûƒÌ`[üߣ(z"÷=$M„‰”'šd3Ãc“\ò:º{\§³îbC
ȍ>Ñ»>¿àzœ¾¸IÒf•Áê¿!ªCÝß¾j6à%æÈ
č)ÐFÃìòr4FÏ­ß_^Dšÿp­²°_¯t›]©ìœŒþ®”6UԜ$_H’÷Kz†á×¥îE›ÿ*3šÏi¿òýHÊ]Ûjׄ½Â¼Ag€Ã Ab\¦h‹Bã;»alü9xJ>=7®ÔÕ©¨§†½"N†HúóÛãw†ÕM{×mnCNQ^7ÐŽ¹*yc<I³	փJ8·°…ß
þ23ËêÚU×ÏF,ý¸m‹ÎÒB~‹~"TÆB2+:aߛTeÒÃÝyMwÖyM·¤0Ëòkjî
^Ùc	š#§”‘&ê£êCM±ÇžßŒ¨°3{púä—uoIõl;#¿¦qôCÔ(™é£¿±Íêø”ŒG¯VW£¿ý
«9·£R?úÖJaó÷£Áí²;{ÖQ¨eÊvý@ÓŒ~>OqÙ
’]áŠ\»Ûëw¥t)LËÿ<*ƒÎ¼¥¬ú#ïfLG}þî¤û¯EIñWfÃށdŽ~•…Ø“,üݝ-©l¹ìR¼†ØGnŽK灇iÁ}ÉMìBFcŽ!€È}›~‰¾À]¥å\_çóŒóÛQïz’²Y>4ÁÏ$EõŒðŽ×üš<sfn¿P_œ6|2$é†ä±¼kàƒ¨
žÉòÿ
¡€|µ>"+#_
ËçiƏD.ÄîYûEaÕ©^TeÉ!âÿ1t“u³ŠiÍ+µm䑯|±­Ý­/u§²—ï\)ïê£.&mºS
݁CT¿Ó¨2’ÿ­‚kÐyþ®´½±ÙåRۛÝP+¬Ëä¸`ƒì’¶àU¢
ûÓ©a$¼q}¯¡ýÅЂýñ%bÍä	uÒ ×ì2¤fIß̛¢&ž‹@eºž<j‡Œiœàæ÷ÒàE,²d}/¥°yJõ#A€Èøtv8+DQ8d›gŽ…ps²¢#9'mº	O®&î6͝OA*©ä˜Øð$uÐì£è¥y¦O¼†3Ýž·ßý@ÊؤbŽDcŒgvú´hƒÎõð"쁽¹_’Izyë¼M¥wYVIrDf¡“‡uÁŒÂ³»>bÖÊËPE®EQW¨ßÜQÛ þÍmÆI¹k/ъ'úrV	.æEFZ¡?ý_¾ù7Å#’7^J›µ‚'E-ìx–½••
ûl`“Å—`]YƒŸMÏdvb³6Hss\dî‡
¿ƒ{‹Vk³C5d»[ë›|³:”S¨£Óa0£ÂÍHÕ{ÙøVà#(æ"AŽ uP
^^¥¾ò)_òn¯omùnx«[~Y/
c‡ìÜùæ~ùøúõ;çÏ?¾Ã«º. ’›…é®7»]oe<±ü»ÂŽˆLÕò-ù
Gi?4¬Hf.À<%
L•š]ùrٜ"²t™FPf~ߓĬ˜|:@ô!1U¾A
ʃ”›]ÒCèq‹úI]h‚Ùñë8s°Š¥ÒqA‚g¥Û¾…0?°Æ×ÂO”ºÑh	|O7K·kþ]Ì{·Æ^äóÂmƒTÄ¡ïsÖ=¦î•¢¯ÂwV¬FDβ¿K´,yTB%ýï\Ó÷_D+)'Oÿx$bÑSûÖsÍ`#á…ÒBI]§”Ôù~miD'BŘŚŽ.9”òÞV꛹…,Ȓ/—™‡:MÉüÁÛÄé+Wò{n$ë³³Çë³³^Z§¿Óýw·åú¿sµö¨Ê`wkWÊ,çDVÔ,	ÐNI+’­Ÿk*rG´‹^ˆsî‡äÈb–Êµb`ý]z^mžpQ·ÿ†Š½¼S­àû½ÞÑ4P@W°/½o_ªà¾˜¼Êmm3ÚØ­Ž(ÛFZè¬!ÒÂPϟWkÌ£œ†´ôºñ‹OæZž°¼ÀnX4¾t_;QFI6hYSË݃j«ÿDŒÉJªßDU¦•pBژ_W@%Úd¥‡Í=ÂênoiÉ?êô¿ Hk¸pÖ¬‰ŽM
¤™QNŒ†
·ì
Û¢,>™/¥ÔE…¼Ò¤Ø²á-r…[š+ü~Ð7Á[
_|+’gÖæž>%ŠÀìGq—ì+”}Ï!lFø@M¬Q‘ÈBOËKÁÂÞŞkäpx¿Æ'—1¦	r¨@Ê°L-¡Ä%κc\-äèf7£‚„š’ßæ2*¹?‡a#×y2Î(ä
öÁÈ9Y˜œ6&ýÔ4Aö9Íhf@‚"o…]yÞÔN“©¿¼
NX©(Zî¢Q9'ª–ç›Õ?wý)f­ÂIâ°ßðd“ÿê>òC)4Ɛ±%ÊÇCó2ь¢M²!)œšsÇ×ÝB5|ïyôªm=öŠ¢2o¬}¬1“åçö«xööýÍÝŽ³Ô(_Ÿª1jÁ«]z·&
¶þƒ{ù›0§ûBKҚÄvøçL¸zÈÓ[ÅƧÅ+ƒ­|Áâ–JR«£0ÍÍ9 ’uwzÅÙ[䵆€z6d†Ó(~(x38^˜îF+K×£^™¸”mï°|FPqkKø&_NÐɟºUáë`’ôÚÕö„Š_Y‘§w4Îé¼ùy9²ªúˆÛ:‡tùfâÏL‘/3m +>·æÖ‹Iÿ¿•[–ÖƎXä
g¬ÁõG˱þç6™;žG
$èDOV£蝰ÍÀ°óçÑiú×äý%¶ÿŸÂ6u&#Ú¡í.[ev6¶|}Ãpd¹¢Y^ùyM¾Bø%‚/“D0rOYäÁ¢ˆÒø
¶£s*ÜyîÛç´§U«Llïí±Ì¹»¾WaÌ^Ú®ÇælÍXƒy6•ÄÜÝgïNÏlY"ISBZ®Ø„©¢-Ê5I.¥*ݦO8Âöÿ];vö/Cv!»"¾‚Ty
ËQîtv €upº¾ûña]›;ʋvV	?*g
ne$6)±<m+v‘é^h:˜†ÿà—äVDä¶>ÆÁUI7‡¯¿¯:!~ü_%++ÈÊܯ6Ù¯©§Ì­*Â\£!D¶st-ÚúÅò!Ù
ü:›¿n—Gïî·óÍöé¾~€YžP¨°?ûš<Ǟ˜o›EXÒw0§¤þò
Æ<Œ#÷€8g‹f^v™þ€«xêEÕGü3²ègߟbƒ®íSŒ.bCí“ÒwÜ+ö	_`bÆðvM£r2•BØä›|w{׋gy(8·<Ûä
ųSÒ¢¢sa·ÔM6
ô+d˜oõâ1Ìòkîìh§
=Lûœ!<AÒ¼
­{œÍÖê°
/8FÖà&ù„û÷÷Ú]ßiŠ¯Z&±ì«PëD¸¸CQΖi$š=Ã'F6³‡ë“:R‡“àVÜÝÛDÍ»oµ“ÌäDd2y’‘I+"-ÀÚJ8B	;ionˆ+Í2=–´l‹Õs5‰/1ø	ýÈ[e
dð¥"N[ï
®áõ†Áà)Ü\†aÆ£„âI¸
õæ6e¼(þ?õÖ.‰<)}œ@õúÉ4‹sˆM7׀M¾&½™U—%ÝG@ˆÅ(ÂÍðHÁ6âáÙÄC-”€ø6Ón;¤`Ôàԇ®(ÖÉzc/+ÝșÙd
ô‚¯z÷xš\OÀg+V ”œLv
ãQ:žQX1­Õ5ß+&K#,ÔOÇ›¥µ'8ÍDÌ ©Ê¥n¶­
2}MƘ£@{ˆŒ\®¹`’
k9»äR4”Wá&Yß¿M“ʐ|jè.ëq„!ˆiø[ü¾¡Åïšü¾•ÍïÛý¾‰Õ¯Âì'4·Èð‡	ö%ÔӖU— ¯°m@aV¸ø•ÈŒ\ÚÂpž™ºÍHסª)T
œ~>
t
ÁcÙã’Áw
­!ZuD
à¨"*ÂKçª"ñTNì[)ªÂg¬g‹;¸†@‰´ºŒj5?^M’Xñ+/	„g–Ó	 ‘+h‡„ʽm)¦õ„	ò‘ºÏ`º
å4­CI͗Ë~#˗„)Ùkγx9çm¡ÃìU4/³lGŒÒû˜90Ñ¡È^òÑïjÜMÑßþ©ç]Œ *#»³ôÊás‹\;¼
»Û¬„ím­7»Ta
kG.¢ÿ¨æcÁð~ø‡Gßm•R®ñŒè>ø}E~¯ÐY[QY;ô"Í|Y
ÊÛ[Ŭ?þ쪜y1R€¼jg@År“J'iŽwbíë`4tÃôÀ!©Ñ,×+ñŏlêHÂUIÁ•R.&Ö·	1gJ5åç˜
4_—®ÔÕì
ÂVX°d

ãP.t#7¨±±æb÷«“Ë¢Z¸–\ƒ›E­C²H\|
a41U©µè@’­d.”þ@ò€4*w™ôsf‹ÁÓ´ÄF”[À˜I¿…²ó·<WYëÁ ÷yˆtÕO'	
¶•÷ÿv¡_
_X6ü«øR<}hØîú6‡íín©‡³ûà0°@è¿O(X±¹iïÖú_ö¥Ñ	g`cWÞ‘|e(Aùºo#ýHªzN“ŝ:ÝG¿\¥èè7FW¢Š˜LËDDÈÀ‰']áT7ä	ٍ€n¨G.kE0‚ÇÈ,»ºï£Cjù(eS‹Îm¨Ïœ ¬ðGéîËá×y1¤ÌÊûLφ"ÑÀ¸~—ääå29ñ´ÈãU&ì…^qUÄÄT„Ä_áý{s29ñ@Ä3skGCqì@¨tæ0fÈș.²ãË´>À‰Òx»Fí…¥†vIËõý#Ãú|aלa	á³~®oÊ·ÛÝmnîEkëíæîŽÇ±îÌWËL¿aˆZÈÎï¦Vìc~¨Z×[´/Ìd3[µnU‚¼²áŽ .\Gbh“‚‚ÚMž=ã5ˆÄ·­Iɹ"XcF7Z=J‚ˆzG_@‘K¬Q@ρŊ]{…˽
’«˜
Ìr?]úpþԒtªðÂÍèšÝ]š’1ÊªÆÇ/£Àž–}<®aêya@JÕM¥ ¡_ÚpšÙ^”™¯¶W>éq!HÇ
ߍAd£VZ&GÙq°†+¦(a÷™:ˆ—9dp0Í®ŸŠØehz
7Rsª.8ß^F¾c™ÑmšöRÚ»ýâ¦Õì–v ›Æç0?ÉZÀ‹P}ÝzðrÚKàè!ØÝK¡†®‚«ÊÊÝhÄö„àÝ«°‚˜þ @
*!ao€¾¢*sV¡-­
¡²«rEï¬ÒV±Ñž
*¨`ráˆÓÕrP»¥Ç#_C(ÝzŠPŒzàŸ¶Š)•_•ºòø2ñçÑà
ׄ‹«aڏCt…Äà¨ë*!sÅ`JKRŸ&X-qñV@[Øya‡¬R…Z³r'WÒí31<Þ¨Uh0ëûÀú¬Épì€Þ%C=3¬º:ˆð¬]ÔàÁ0f©Gn!Þ¬»]ðØ»ž-`ùrkßᲃ’Ä\øˆÝ† °³¤€Ð«OŸÈ~Ã+mÔT-Q Í}Ò³³2;ueζ7$ÍJ.¯Òþ
ºšÊ„
Š½§º—3ü7˜GÖËÉí¬œøҏ¢v0‹aJq¨\tFE Ut–”WZ…«—¾”#2D÷¿”_ËB‚e)Ö{ªU$Â{“6›YŒ…ü± ˆBÒâ0›fž°­ÝÜ)œßç)F.§‘Æ°»·èR´">3õáøןvx
¬†¥‡Ün㔘]Ù§uº±ï—؁¯c¸³×êü‡v^8½
e­@(Ó³S-ó{Hª@<ˆœE˜«
w“œå¼·lž/“b⁻Gt+r˜6Ný¸¯(ˆ‰vl’ð·œÞ¼Ïd5L¨ŠÅ€Fã<E w™ì;]Èð ý8¥lnÂXsTÚÖFOś}ύg偹ÏgwŸsÛ?Ë­T19÷ìWú¯x,-,Ïá¨y=‹»+e­•¶û¡\Nûy(›Ó~îÌçþ×ÑѝÏ5½uσ5YrI$­EF]Kí¿ª½®åÙëž?ÕºkþT+ȟš7Ç9TITA֚¥–ë궶ٚ÷4XÓßWw=«è$)fJ¨ñL6.[ætóks‡›û§ÂÃã`Uì1»;pÖ­mt:²gí1w͙º…yS¥wï˜;Ua©¿CþT…Éþ›çP-cU_¼<×®þÀª‹a~Žò
Åc²¿ÛpÊ„+&M"©½uÚè$˜%(ÄÈ°3ÓJ	$˜cŸßÚr=8íÊÁPfFµ”芉Dk˓¿Ì`–¸IGýìF›X?7Ǘ‹Ã‡ËgýhR[‹~çθ²G‹þ; hÔk³ÌáPמ5Œ¢ã§ïə³¿Eú(}Ó\XÓو¢ƒŒ «®0k+Â@à°s*x`ࠛŠžîÜQfàñ k†ðÔlbÍ'\o&5Õ¯³1-æK)ÂòPҋÀãxƒìršŒ4ôŽw|c«ÙébË·»Í-Ÿ‰XÞàÂê˜Ãϧï•-TdãÙK€ôwhÑf•CÃJ¯T>ŒŒLRôŒL{V!$̞~`@r©vENØŕsR/Æé>YduÒBTï\ªQ9·LXCEBYšjØJmD*·¯ˆK	ÒH0j8ëʫÆá%ä˜
ªåØP±;Þ"¬5ŠÑæÒû.”ÁYø
ctçtT>/½°¼³wM¦Tm_	;vanå_|´8ñ}¿i7h»^àt¡Ïú«ÖT9©Aò.Ä;{ÔSNfòñéÇMœfB:‘.¹B[Ì]OÅP¦¬im?è¥b‰è£6*‹8‚ù Ê’
ã›dãIÊÆߎ¯à+p¹D¦Pž¦Ô¡²åòB¡°N®if}ÈÃ_e*ÑÊ<6é²ÏÎßœþxeý+]÷N7x©5ï;{>>-¯j2	e1ìZó«
+š÷¨ymÂc±ùúê>ø
üG@’
âóüIúó1Ó+“ÞþÜ.(§³2¿6³´2!77“â|ߓlìE˜›¿6¤¡EÖ·º·ÃùîÝÍÝ@–#ÀÕxNQÍ=ãïä~A¥Ã âÙ 3³ ”eyF
Irãk\$±Ýn‹Ú5‡Ã,Î^˜7¼8sx~îpUöðòC®N!®AqäacÓ}%š…k³
X`¶vPÈÄq2z"tîÌ+¼+5$X°hÎp%¾`pi¹»Ÿ_X²ÿðÕ‹ï¨0wfނ§Ð{+ªãaÅKéÍä^IàCbw:ÕðNل	yKEgE¨Ô\}Ö¥6ot6DÛÞ\×YwB¿‹ï¾=‡‹
ú¿Não}ÿuÎþçL

Žolnv9	Ï„ÙœÏoÞÿdvÆ(á.W\oÃw(€ùéà»
m°²«ó´bãñ)TłO^•šü뻃Õjé%Ið$÷^_ñ
Ä®[›ÿbûüf•%œµ€daý6ºm2ÊlînŒ2‡”ý%L_÷·|Uæ뗖?L1õÖe£ƒ¼¹­õu]ØÎZc«6‰Q¢AQQ€²bæ
³øäöÖV³»SD¸_ºÄ”q1l2Ø*'<¢ ,@’ŠÃâR昋8
 ÈðBAšBGÖ€.퇞iœˆ¢f8WÍZåÊ!ÅÂ>XJ£e9}ÚAŸÂ¡AEł
~e «d.~"Mô=ù´¾õ<juVYgÍ®G''ïOšÑã”m	^…„ü¾ÿ¸iKd™·¬½TæEJ(
4P}…k[Ë»h‰ÉхÉIÂ{mÜ2º'(¦«½¦«]ÉåýVd…új'ëöÀ¥­ÄœÏ¨˜ÍålÀ
1¤g^1Hxè*FîQ|ŽIŽ‚¡ÔÁ(ƒßê…lÃt%F?§z±”xDbœš‹u$rü%NК@®+Œ¢/óνþ^ß"f¸ØaÉ¢þ̈zɨ£ö²~θ…x?›ý=B‘Ρ‘È&ù3üj÷Œâ­/ÓdÐÏ̓
Áoð&m®ï5·a*ÝYï67Jx!ܦ*8ìg<#d\P¹ä•Ð‹*É^ÜF`¬aw{ß9~ÿŸє»ÿ½ð"-Þ9êìÝû³£Óg^"R"'¹5L†ÙDkšQFlJÆ0T7Ç	Vö&˜÷&9uƱF½É³QŒrÛ7žG¨˜øhƁšZ-\#È!É#ꌱtÍ*
kŠo©x_q®¤ÀŸ¡ƒW¡çèAŠàµÄu—L†m!Rª¼Ôt¼6X
³
Jr>¦6
¼"0öGž'2Xa÷›æT®@äÕ¸¯õ‡
A$p’È,͹~6õ6Ëͬ¨Î(Ç	g¡5š(œÑU‹*Wˍ¢O¨¶ÜÒüân¼¹à¿v¶åß9M/šêÞÍ	ÙêÝl1•ÄÝ0[Ð4…?fd×IÑÙ¥ö–{¹wê{sãÉÛßô†>‡5‘T{¬ƒ¶¸D:‚<a1™Ñƒ¨¯‹87ҐYùøý'ٗ´ÏÄRŠÔÁíWHȲ‘í
Ñ\ʽPÖeÑ=(.¼‘ &͇œÒ+ÝC}a*8FþþºT^‰±EV‘¹Q{‰ËÀ!–±Õëˆ
젚†KNmü½ù²J(P¬`O¾(¿¢®(ñHÆe҄ٲ#»ô6œâ‚ã_þ¨¦gg:ªl’sU’8¢“{KUÈãaØ­’¼Ì&!’IÛKú¢Î$!ñHH[9Ëtù°™µM‰Áå‰a1FøÍÅ8psñÂÄ̑Š4Cç¦)•õK×b’M³^Æû*ÄRaj(’Ž6/øY|«üC9PLpð<€¹
~î+p«îÀ0åÀIbY‰l¦apÃÂ&övÂÂp‘ö+)’ÆòYòuJýŠ7ôöŠÃ:3Dž1Lzyò z>Hrp”
§˜1€´·‘9ÜéÐÎpÔ*'±›]9zòSaéB
R0™¨‹H.uO‰%HMÍ܌ÔԔìCFIĐ\D>ø	Œ"s±[$Ÿœ# #L-AXòÕaøÜÁÿ	Äæ[`Â_,“á9ª¼`Þì‚ÞI Ñ
™´Ïü÷4I¢“£ƒWoÚ¢{k7×añ˜·ûyb
.ReUíZØ1§ô,,ùâ•Üy@_-ªaìG‰a§P/¼VQeuD¢áîö’_e;ÔF¨.P¬Y
Ðh«?¸Ú;dþ(#“ù`c­20ZŏÙ²iú~Alÿ÷Þ´å*ö:ËÏ9à{*€±lÝèbE‘ŠÒÜߢÈÀkÃA
“tñçÏõfû«Ñï#[j6zZ¤8àÉ|ô¥%ªz
¹OÇz³zht÷u¨‡[ëÍ­-2Hm<SO@%CØBñÇ®Á |ëœÒ_é÷Bqû
Àû
˪(Mß%·¾øR¡¼Šÿ4Ì­÷#'æµìWãÐ̹ñC©=³™\ÙÈBî~å†Ûäý0˝´Ì½Ñ?3›ö&r)MÕ_†"®"éÀ»˜èVõ*œÙ+)U|ýä³ß·Á—Ÿôd5›lâMw+1³¢+E„u–Øoh°Ò‘jH=
õ<a[²Ú$Žw:¹UÓ#\la¾WS³î¹"˺}Ó'KrÈË銃 ×£·|ž g3Áy4aî
y÷hY¦bràªv¡ùþfŸjׯnåt!h±\Ê?O"¨/ PÐ/2pÝ0’Á"c0ÊFÓCcZ´
ó6@úXnæo€te·aT܆¸€ffóç9<©†=KÅЕÙõÚÌÓ¬ŽsÁÿ¬Ì‡·u1–ÉÚGÏ⯫l~úóÁÉÑ«s9ҒªóÁè+dà0ÊǏSÙgìtYو“×H!ŽÝôòŸ*‹kÜ+S
÷ón>Ï|„…H½¿4•øQ€À8Z†ŽìSz®­yÕ[pnŸ7\à›\.@ˆšJå:€uûI—båy€qc–ÿüÌ+—Éñ]õ®yi˜"ÕUšóí»Œ—cvћ€=¶‰4„)ŘEiô»È.b”®­Ù_Õr+ñj¥ƒ?¥nSõF~[:	cW¸-Ÿ¤Êªí^gìÛø³MBáCè:xÁ.y¨ß«¦IõdÎuÝuznúߘ¼g2,MQY†\5‘JþøUº,ö ɐ\µ…R“]ØÝw;›Í]'YI•Y¢ÆL1¯ôüs`Feåð'pÕmxåûó–JÐ VÄõ!Äi=¾d2
L~?Dýp¢éwïÏÎþxpüæàå›#‹1ašó«Æc6ÀºÜ

;‚®…RÃNåŠþëñ÷ù=~l¿E…ø3v¾ÇC
}U«oSRË‡©ÄªáWkAûù„´ŠÐÂû¥æð™:m¡ƒˆäXN NäùlèІèbÔ@|kH#Ï)ߝðF¾ŠÆ°—å×|Eóð%žP®¹7n.‰QNºa±„Ð!q^àZ»¼´`Xké¾ð²(^Xä+oòßÈâˆ×CÊiÀf2GéÙ<,dª€ÀF€ôa3¡¤	©Æ׌F)fÓËT ,ÖPÙèkZ€8ܨ>`{ût-Oâr6…Æt˜“m\Ý,ûs	Ó,“´Óé->-ÝÀ¼y‘!Íð‚vڔõ†­ùU†uhE˜:ÅæŠüªÊ<,…qò©&ã¦t1Ì`ÿ¦Àµ¦âÚVy¤¹«
C9á‚`w…6đc	ç— 
>£JHR¿®Œ7+‚ÜIØ&ü™	žŠ]N@dXŸôÁ®©k@^˜W¬9Û¬ëˆa¸DD
QÁ\Ggǯd+ô#p¾
–øÂAlÝ$6ÈË2=¾ö‰Ð= /،&Í¡·éΔgB®Q„‘Y2% ½-ÒÕTx†ÀKÞ´°ªY+`žÙ”XK̜
EŽ¡µóŸÙ²S&$£›Ø€s唀Qâ“ÊVU&sâTWf9¨n՝‚Â
éւÊV\kWF
Õž1øÚ6‰Å
t‡®¬ö:>5]
i?›L
8m–¬3+IÐoê»~}·LÉ;˂pTóžº}#4â6šiV¦',zöAʵ€Ÿ{æSyY̨ޝ)9b®cÏêk%ªø¦ò>ÿ]mZi ©ÚœW>ýö”À2Ê%#´Çäë8é±”qw¼¤;²ðkòó,jüe]sìÂ~QtŒîØc”ËA"x
¾‰C(AҞ=̃(j£ñû?h/ríe7#ÃÕ¯Ó±^>>nا€-€¥ö=¯tí0FAæJõ`´‡ÃOš’Ž-Ф6²ÃòCu€Zɦ©¯X€_€õ[€€lž¾¹9÷ÅG‹k`éÉ´Ö~ôƞ¡Ã.ÉÔÑk°Œò]£ÖÀ7_Úã·ç°,žÆZoRœÃ/­¶}§ €‚Û`¢-Jt>f®¢8(–ÕMÂúœ‡ç®(0*¹>eY'ùSë*Åm¡ÝÐ!T±4á!6È5Yȍõ¼Pډ©3¤¸q=hMͯ²™«ÑØOûnLÉ;ÆÔm
CÐGq²!J©û)«’§-aýiU!yÕwÈ×[õzã2hbæ)ª}ˆ¼œÚ§]ÜWíkÝQík­ÈêzjßrДÑB…D´UÒa:ˆ'PÀ(OÛbwZ9¼¬²@‘1ÿr‡4QdŠRPµ²¨G¼Æ$µ0'qµB„
ϵV%ýò¡÷Òñ€[J€-ÚÉÝp[
x-ÚÉRðT÷¿¿"¸¥µl%<ƒ HãkÀïQ<°ÊupgT"M­-3 ¹*îJ~zÇ,9WŸ—¿Š¬Ùåÿ"ÔR•6,n©cWa–úÎ¥
 Q;’"žèÒ@¢Nrx¢ž’3—“~töÞR!FØîY¥îKWÄ<
w°rXž"/œíä·RµQto˗;Ö ¸r¶Õ—lð…“y—šÁG0b·>­–38©ˆhTõ‰óez…±b
múWJâáÞKG
µv8Š„9D
(ÐûY0Z]xE|tI	ÿcñâ{ë(û\:]æu™çvù&~—å/ßÀóÎæwÏ£õ‚ªg,[ú!TPŽ/ôÑ©¸L„Ö[2$’þ"øê+jða$”¶ýMUÓz¾hþ͎Îw¿‰•‚®.2Køø™Kù˜
›’ÛJ{Á?ô:›XK¾k;ñÆâÏ#5zÜ/öŸ¿†¾ú¸¼Z˜ÝOõõލ‚´8•)†¿÷¶‡!èoÄ=Œ÷tAîˆW|{K7®pÿÒ:+¨š•¯²Ì³“Ì¥Fë6«qÄYÉÊ"•Ég>W»Óð+O«©¡šXŠðþî½wßnç*ñþt×îٜû5Ð`Žœ—ZSÁ9,–ˆ¤Öv	ÄTöPjJOˆ;N8Ыʋ˜ù}…x?"QbÀ†Âüd1„XZdã&3Õu°×¬^´ÁrV廀ûÊù’—óßoþæÿJ½=5$'ÔÖ:«Oéä0WW
sEn1W¹Béý“€¿ ?ˉ’ÖÃ%묆™ƒ³,ƒxQSÐo®ð`…>,R!¾øqÀmævœhá‡ÿÚ[û‹_)ÖÙ°Rcûj²ï/GN¶yt’ò†|š*	;ËÕ©_‘òqGKµËEùÿœ?J¨õÐ|Íò>š‚“fY/˪ü4qÔÜG+»j¼hŸb5y¨]L{y˜aL{¹+ ñ¤Ó¿ƒ„SZê÷¨9›ä’FèU8!ëƒ_ãÇùMˆW|…ñÇ­ñ"Žô–eîMٝ Ÿ‘ÔEjhûàÌOf|lV„Åc`Ÿ¥MDoF’É<›Ø×R±6$眞föýˆÒY­\uS‘½Ã„#7©RàŸ
nyY‹"{ErØpÖÏ1ÕëCRÌ}Äõªh­ùøâ÷Ã,_ú­®þ¯»ë×9*«XŽwþëbüöb,šÜÿW+Q[¶-òOâšñŠ€¨67ïÜ·¬âŒ·ió kËxܟl•âÐa;ðÅ¡vøß%-½å*°¯Î/íã‚E$59¼¿H*4)Øý´,b+m‘³|Ÿ
)]슝q
_E¥Ex¦·‰q@J†"߁w‘pyP)ZWؼ{Ò²-3A6/ßÚZ/™ÐÕ­v&J·©4rq´-›˜8/€‘´b5¹k±
Ú
/½la±
ÎöçMö;%ºSÜK¯ú,.óÿ6‡¤à‘+%ëdž¥兒Èҍl#G,‹Qn™
îËDí°‚°véHÊÉLYv2åpXW1¹kÞQ½{11~Jåx/ËBñ"ra¥ˆSÛsm/õábl^\TRÄ«„6¯¤ˆÀä³`  ¢eçCùFR‰Ã*õ~:
HÁ-ª«ÜmÂê•éµw¨þQ‘K|‡êIÅËgòÞ¹Ȝü—¥3©êêo¬­ÔN·.ƒz-ÈÇ_DÍ`ӑ2N‰$p	®å4Ԇ—ÚºÚTˆ­[qóÅܗ…ź[n-—Eè*©>œéµ½Õivº;ÑÚfgk³¹ã¥Ð¶
§Ö0ÿeÑ(ŽÆ\€Àh—üÝ̦
*Ô§=VymHé
®t©ãìþÂpÂ•Ä@ŠÇ"á¨zˆ·‘€då>³oGÇSîŠÃûåþpÕX¤Qdáh˜:gjd˜ù{ŽYœ’®ÕÒ¹7ÖýFdÃDÂè=`‰¤=TLrÅ+qùð4¬}ÉÿKÌN$‚ÅO"Œ‹7¥Ð2šŽE£¢Ðʖ÷ìÑ
rÚª?I•Ç¨u‡cÔRÀçFðNÍ¥hó𪱛+[áW¤kÓà~OCq…«7zæTŸ"bzY«èe‰ 5/Ò,¢TÌꡔښYÑ0jòh±‰«öÒ»Wp.÷?úf¨.~Õ¢
®¸Ç»8À7eÓ-k¸mÑiAÅØúÈ]T¤—5	ãmxD¦–"2½˜«A¢šÞJ<`ã	kú”hfc Ù“Ìn¸Â0$Os¾¡žÆbHàؚ  v(	`×r4CŸHÄøäj!kZ"¹‹725Ûp.Ғ
ےÊâ°
‡X,äþnJ(ŸS˜¹OËg€ËOêŒðôFÁóÌÂép˜ôùJÑG˜æ7ñ¤ŸSâ«UÞÔN“©¿¼
[¢‡o°C®7bS'X½yÑV:‘Æâãª^Úϸ/0vʸõ.Z¡ÛdÚô#c½IÌ%_Åf}y@êyê†YqKií^×nîqb’k-~8!õŘó)
0‡æ ¿ø•êMŒ‘çk+(L€fþ³+!ÿ7®às½Å8ýóµ§ýsàùØú§g'gç‡'Çgç§G‡gÇïß5ds’«Áâ(‚¸)ó
LÉS•óâP©ù‚Ÿtóþ"¬Ezzƒ
o‘~ÄaÀ\¤Ÿ°å.
às/²WRs
ƒ±—È)ƒ®úéÅ(`7´hpd8ôóY™¹ÐÛܸ̳èPP>ðešRˆ®…â
Hæ×)ùq˜5hVzLÌ9wfՌ«dD7y
W¢©AtxüÊlÑ[3ðLÉôàXú“”Q‹Å7A2ePl>p÷2v±!²ì ¯	.âÏïÏ´pû Ô d]9~"‹—÷̝Ù_
Å´’{ÇÕ¨›£“ke[Yc^û¥4æ}éoÏ£Enîg
­	Ž¼fKÿ"Œ
okî”uášrK¥”´Â		ùߞWçBä÷ù!ÛÀqã&‰ðršˆ¼\@ßômŽ“\jàʏΎcÈ>¿L	›ò`*,–.D槗Ên5“t¬php#P®(ƒ3ÏFb¢¼E\?"¨úAÁÀ
P³MÉU×4Щ_žÀtyšFʉ27æ}pNðq¡—g€ç6CÚ·éRØ0p¦Êñ½î(w \50®!N3+¢ãZppÍ\§Ðt·>ґºÄC[Ő.[PZŽGFɸš€+‘Zz¡ËÀÐÇ(žLÄËÕNŃãò¤ì°Äï>ëE`øÂTìÆf{l؀¯ëœ
WÜÚ+Ú\ÃCðÉbmå¥ÔÕ*-uuÕË©”¢„‹êz©”âÜ´‚DÂxÓ/$N‡U§Áú¶$¤SÆ+&H¼ê˶­ï°N$Ð
#ÙHÔü*ìVæ1h12ªˆr4¢êìr‹qHdÐ[ýâ½háSÿ0†‚Èl²Ôï¡4°ÎÕ¿çrÒÇß`
kÖæМx%œvYÏ&óø&8Ýnv¹ò9=„–=‰ëÓ6­ßÀÕè*#ò3]µWÎ0m*-–þâÞö.^`•†Ef
֒fîbÃ[eô3›á4ʜ‹{&YŠ˜M:‚_·Ï¾[ÞEù0>‰ÿ—¯Š¼6GÈþ>Òv…™‘û¨ß]kìÙçϘÿV«"xBS}ˆÚâ{à
¡­»¡ÔR/CE¨RyÌE’Mm=ÍJÉkê¥åN¨4l±P$Žh€¬N,
W«¨ž…øxžKÇéw￀Êí <“¾#2[ôÚÖÐô
úrù•6ˆ4CµӑÁæ^Üz
T“¢ÎPþwäô¾ÀÜSP3Y̌NÄ¿¿p<£`#|OÄ^ú*LoÕhêàŠwö¶Q¹m³»¹Óô!õ¾š‹¹×ž¢¬Ç´=bdBµW¶^Lúçøm¿Ô²à䉶‘œÜs¾=ÖZž™§9§,ö9˜nMdÈwÈôú`ûƒ¢ÉÕZ7©˜ÞÀ¢z2y®E}ÏõçF¬µµÕë@bÅÅïZÿs›–Íx©L¢'«Ñôí°ÍÀPùóè4ýkòþĀ1‡-,˜µÔ¾æm•²”»Ý=ÞÆÝõæfw;p™M~ëòpõVï;
K.¤r)`dìÝGk¥íbÄìșî
?t¥XŠœ"‹jAcÑï£Ïo~~S0È=3ÄýmN'._¶Ü‹}¶¸ç7)wãÒzvã§ú•;ò<U]ͅÀáÞȇD=–ÛPŸº‰RÙî'ªT#-½JQS‡«Ê0ìoÚæà²8iELàæâ–:Œû¨LÖãUɚã™E˜K¶»±õ·W0©ëw©³°¸žŽ„Dq»d@·ñ”|´:ˆä^gIv/çütBY
¯(³».ߢŒ;ssÏ@¿ôë…`	å£a\k¶O²UiSÂ#u·¬!aOxžánêOS*Éׇ'2*T™tÉnJP#ww?CB…	º[ڌPg@(®òB#BP;â±ã¼eoM¹J…åÂe#pV<íëxGÛ{Ó^ìµÅ)½Æ…‚"vsP¬d±…^(Aç+º*~͌ª
ņ7¶à«/8—Ö÷¿uõÇù¶‰Ô2íþGƒïÂ*œ$¯Ã5zëì ¾«â‚LÎphªV›™9ð]s)x>þYQÁÝ·¸b¡‚[Ôl×V\¨jnθá,
‡„-ÙÄJáϼݨ[‡yºîBá.„C	Æñô‰“]Ö³¤W«6ÁuÉsJÊï45ªe˘(¡AJlø¯~ºè1
B­£²ÿtÑj0q=t[ª!Oî°)–ÌÿN#¹Ó1*Œ¼Ÿ\Æf‡*F*êBp\öAcyj”ºÖ†ãtàÁ1,HÌ~l»å4ãÿ­és	Ë°°£RÅ`Ú/Ý"ÝÝjX‹¥#µûÛ§)ˆ‰f¨
Æ¢¹IĕHµÂ €N¸FwuEé‚l×ÏðÙáZ-
R^&aËû´Æc³SÝËÐ8s*¡v)	•HAìC”Ž¢§”KPoDÓä`órþl©,ËœZºP,ÎQI±	×-CI±›l‚"|·×’y;„õ³Ë5‘T|ùF|èE\‚/mp¾‡ê9pd3:o>X.”f»Óž¤›$À/Ý66}\å!¡ÍaÓ!Ý)d¸t!=³æávF<âwÆ¿Fi<ªRg>•Í(þÒ¬X.=IT%Ì{¦×pÕÎì²SÀÄH—=Á/ƒÚAV±ÙøjKµ½ñÕ¹üs÷¡Q*¤§Šý†lÔ½8
Hñ Åä-M‹Íîð¤kϱ§Õ**bP½å„5õtT\ò'êA7,ƒðÁ0܁è!=—Pª5	Ezí‚R1\nÎ%Ÿ].c°@ßBóåà‹PL§¸Ós¢Ô0tb°ˆÅÍ8hK¥üáXڐN6Ûwo—¯ö9ž«š[>rÃ`Þ}Çû¼ê_Žé;¢r}Çә>]>ŽVàJf1§±ǸN‡‘­°<	ϪDѝ-Ý,®ü·NqBóL,nêú¶òþ/òÖ6·mF8Þ³²LŒÀÓÍ%ì%»Ð Àˆò¨ˆA™½S,Ç&°A6º€GIˆ¡FŽÒeÈ;gáÝýû„;Ž§,¼’
,^übÞA÷÷qžh+®Fñ)ÿ7'÷…îÝ­W:vÒ«Ò¿ÀË»ö@/ 4Ýãìý­ŽRÍEâ.‰¹/”ÀÊj’ŠÇ¬y1§rVօ]{‡Új®Àšuv&^‰ˆ–¬#s@2âÌì²as¨îyŸVd£ª.~sñ½œ‰÷LÎS3úœth»ðóCÙèmº£¨W6DI!aTY]²Þ‡—Rª¤G¿¾>þüöH?tù7±ã	Y!{ý^[‹f±äE:ïf.jMþ¥ëT’’AÄ!WÇæ‚j@ÃùK:êÿÞ¯íp'æ¿$÷÷Ð#òÿo$=¹Í=՘„¼ÌÎÁV|½¦‡X%Y.[8{‹}‚§p¼,IçT͙S-¬ø&éäE“ù| X£ª†¿υÛ{üâ~’Ù?ïÍRŠÐš'w‡\ûUÚ?$Yªöú'¸¢	\ÿ¸æ‹—Á<„˧6>Èp_táZ.”xPŦ
™8¨°×å$:ÿ_ÅP±µùb~˜X½JÌ’qæ Ü'n,wuÁb’Ÿ/[%ù\ƒ¸lÕrœÏc||§¥À¤r“nTÑíûOä¹ØBé;ÖÉ{’‚¥²1Aƒ\Ö
YïÛë¶{/C°#lÐCáK#¦M3Tü×Ô
iàe¤¬Ž¨CD›X»ýLfÌ}Þ~âêß4
è³bXu'¡=^ïó`“­ÕLõÜtßPÐ)žJ¡d|ÑýõÕÇO*{½Ä	Uª>sÀ–õÓÏÃ[ó?s	ɳ˻¹ªôÇ°è|Ñ
æ›!<	GJÕ¹¥7ÆËҋT=›ç›gÞ®ø÷n¾Ò ù·98iU„%º{i».A~
ڔÓQ<6òíô`t(v¼fþ4‹¥‰cÑ»oÞ°+0™ÏF
ÊO½Ù¬%\¦>ž©Ô}þüYØ4W #ʳÊåè`\'ðãÄsÎ^`³™i/E®§—(ÅûHVœc+Ô×0§dZ’“œ °(ÀN
p_T•m¬%\þl>Nz©ùjîê$p½)
ýpp¥èòȦ›Ã„Œúˆ$îÑÚ`{í¥÷Ò2ÏC†,dkë®V`,†Tð_.ìÉq
“°‰öZ1(uI¨	\K²¿*‰RÛÛOÆɨŸk‰È™gÔ.ÜaϽæG	(dÄÁ^ŽfFDxáÌù¾€ÝPÕ1•÷šÖ/`dÜW#me°|eB¤'ÏV¥W#J3räÀ#/ZR(R°g¦ÙLX¹Y$«S'd< ]"6g®†B΁-øÀº=Ÿ_ßPŠW)ÖHªÕ­¼ÁÅ7¶;›ëëïýzñÀHèXƧ,§ïSò¶‡ŒŽ
°U»Ç 	*¬O!эáK
nØRŠ¾|!k÷	ߚϑ}'Z莬¸‹Ôä!҄1ÌiÕߞÇ%,–a½}ÍpsѨtëJ#Z!WjöK|ËكY/I,°¶+ÑÓ¾ÅÊWõWa^µÁmNä¥B¹Õ@˜ÁµÛmýÝò±kO¢Ÿ\ýU>«¯ï <ªKk–©c„FÇ.%Á&¯	Ÿ÷GÞ´r,­vݤjR/çp£ù™—µß©H¼¬ÿHEÞ¥i_Jâ…úüæýOæò1ûµ`¨†ŽóOo 
9¦ùup^j#	g6?¿É®ŒÄÿa:1„ÚO'þ¯$|R83ýú!¾JVVÈòù<â!Ž…_½AÖÅ¡{!èÅF‚îy^›²ºr¯Hð¨Š&ynµÑÞ¶AU¨·Œ¹•
÷á<øÙ(Û^}}F~èç$”êˆhÌo؂cŠŸjœ¼=-vϏ_5‰äŸÌ>‰@_
Äݓ…h¯Ìysú®
#Ét¼ºï=<{s,áÕ>K‡É›t”¿RmÞü÷èÝ«º3ËÑ	F~a¡
Œæ*ôs,10˜mG¯õ‡´"¤•áÞ桽÷¤´÷T	
üÁ'/Õ
Úa†;4s9ú‚¨wÇЧFbÅ:-@IÉ)-Ä׭掆nCѽöÃhí9j{´²òšób‚œòmØTüQ1÷Þhz÷Húr}¯@¬œk®°tšÂ$¦2¹
ràŠh$±4Þ«^0´¡£„ ¹Yžû’æéE:H§(º>ՀC/apK¶†ÜÆáÒÇùª3=0š"ôd`£ÈŸ¯
IǬE;`s­ðn>ÕAß±Z´~OU³«¾ôo‡å—rÏUóÕ=ì[…%UÝIßx@=—!»b¼ ѿ⤹DÍ(<Y¡‹ã
Hä[ý6 Hèê¡ qJîÃaHx0E˜=‰¦"!•œµXHÊ,çÙՈD‰
¼¹0ÒQFñYÖ¸GO ·~Õ|¹½­ns;ZÛÜívš{H³¢±¤#²ÏÊp‚ó"ÉN…C³ú(òRƒ,
âgãñV„þŒ¤Ã,\y“ùꍪÄÆSgq¯Gå3"Šô"h&¶“2ÛÔìà
42ß4Dܦ#9Õb½f9gÓìòòœ©Ô<$Å)'JpZÕE‘‘œ’OK鳜í³Ä"½sàx_ƕùÛè—–Í#þYA†ýMpiTdkªJ\¦Þèòkmš%oèöVX“»’ù
µÂV•>bh	Zl\œ$É_%«®˜ó©Ü4<Ž²ôÐ…??¤áÌQ°+þîšigê®h	7[Ê,*stÉ?ÜÛÝjnn`·v›]w06áÈ»‘ æ*ªÌ8^õìy…-²x²s:wA»¤,³~L̶¡qÈ
ðR¨ór’ý՝:ÞçÔUÀӒ¹Äaùš¢Õy$|˜÷>nk•L$DµoVË%Ε-­;È5kB«3è±Ä+L/ïl?h`ñÕÆÖX~™å•¨kóÁ°®Ä0óñcomÉQŸ+[3m
dk¥v’Á[•6®Â[E1¥~´ša^&~³Ò#Á²þ½Þ+և8³4Çé…	¤9#’éh<™üÛbj7kƒÇQJ>–Äè£ n}Q³Ï.$Åõ‚GT ×.€I?£Øa¿ðC±æ;’ýšæÕÎ̊u¯„Là‘"ߨ¼hÙÿ	ìœ0FÜ»ŽÇ9É?}„õ'èô×d’Qqb{±Œƒž
¸D
‹„s%B¨$¥Œ¬
éo<Ɍ„:¤ËîÒB	˜«žä6Hfìm`4©Û݉-ÖBš»OÖwΎmYQòKܛ͆T¶`j„íñTñúÔ_[&AÚªä°ù“oMdô²¦ºAT–¦rµ%i‹œ®hњsÉÂIœê“G#ÌæÀڃ⦓4qµ¼­[…òÕ¹›£/œ„9Âh¤Æ“]§ÄáSƒÑ…ò{IV^h¾¾{‰$ÐوKÅ@:3ÂÀmSj”kœ\”a¾“Kì‚bââÔ{b–eB	(ë”$C„¥ÙL
ÓO(Ûà¦ÅKIJi”÷³ )'E˜“?J͑57Å͈3‹YÜׁð"•Ž)L[:Â>¨ÜØÏ$(iæ¾ÿå.Nw£ô#øtaÂê5òFt|º—ðΒ¯œ=”c­=˜a­…ü*b$?lÌ$í«ß­ÆBYÎÖEX[ÌßÔ¼4g+_uŒ­ªÓ…ÖåŠðƒ!»m®‘­x¯³ÓÜXßøVÂ}E¬G¯	œƒ/‚S.zWAñJ›°^b5uå†Àm”ðÓïAšÃì:dyF!÷ª…’C6Î¥n=E9õ›
ÀPHJ.Z¨¶æèšó֋
G•„©„²D,ëQÀŽQââ|Z™0]$»ãï.¹*#Š*kr©}¡ýŠWˆÞ«\.q´ôÕ]A›|LZÂu¬±p^ÉcOÞÖ²VÏMGš¤‰½våy]o¥~vŽeðG
ãÙò ­Äk‹Ç?¯N‘kÈÂþ í¼Ú·æí…UÙÉÐd3Š‹Ù=Ç1ûú@tIͤU®K–˜f/±³¦S¿GϤA—¬[/î%Èn-ÌÃðZ²ÃbÆì}A-Ìu]ðé;~4 YëDYø•ßlv‹Ç£i¶§Iüåaø1òò’=$/¢uz«T8Þüø¤k…ž÷‹¿wåA·à 8Î=uØ|ØKiý=$+å$ ¦Œá%ö»ß[NAÊIœ“¢Í¦y±Å{–U³] ;úÖNù¼Ô—Üõ“‚tƸçb­Œ½4-í%,9kóÜG•·d%F„†ój?rç[&gøTF虋 ¶°Â*BYØ]ÝAB¨ÉSèm©×ԝRÊóMGïè>Qô¨ïg*¼¾TšÌU8’yÆÝÁ¤ã.+
DpɜõG¦
aɸc‹¿±ñ¥hV.R$ Û¾„ÂV\–Ôåܸ‰¬ix©µá,ÓSê@×¢ª‡ªô¶ÅïU¤#”^
Gï3“Ê´LB£¼2h\Ç'‡2Ï)Á‡t!P›f¦ð'*(Éú9J HAYôáI¨Ÿ² DPô¹9aô4I8“}NX–b ‰³ˆìãšõîPËÙE^¨°—VTVÎ,½Ç¢\ž9idRLX|u!¶¥Ë@5?–+-à2tZä­%OxȉNɍeØÿ/#±¹†›íXRSsÜTôŒ#eEðzPFÀ½%ÐEæØ Y»ZN­ºÄIî´r<þ±Pšu	qÇÅ©°^þ[IÈEêU½`kt.ùÞ½^X³;¾U*ök:ÒëŠóy´nkPÜ[“êh@o."Ðÿ
ƒS=œ>£üJN9<†üF-ý¸¦þÈw…ðƒÃX}%8P^Xfq
ëiËeÞrëÉùD¸¦Å¿¥—£~r}<=:?8==BÈÞÏG‡8~÷“,
ýÁ¦3dÒø[	…ÏÃŗÀ"ã
g`Ü\gÀOL8Ø2ÁΣ=xò›íUð’ªDýoɨŸ^Šd])ËáþÞD7•wÚ?Q‰ÍèÉÊÊ)f I¤ÔïSbõ¨û:ӛy!‰ÐÁ1ì¦/±rÄ>õ£ü€]›	Òw‹ybê±Ç™{bX—(ekH3ºf@•}ALބ*™墰ŠxL9³Zˆ¤i¦8Š&Ÿ@C’ÀŒ^1ì—RoP)ô1^ݼ)1*A°!턗«9‘æú
Š¦ä
hˆæ9ɦaA‡|ÒE3”#Mr,‰Ð=–Šœn
S5+–nv¸ò!¤Ñ¸ß'˅$þé…2H®Ønž»]Êü°EêYuäüîo­nђŠ3S±ÅIT[I+„0Yøa°¥˜+ъñNìXâB‡†Dƒ4äÁ!†îÙÂp?Žx=™h4Ó¢:
1b
˜Ð%A:€CRO
ù­*GÒ.jˆJ¥€uæçï¡>5
Ùp…Hó¾YådÔ»eÁ©Å°pv«¬qhÓ!€=a LŽ¹h
mVD«‚˜•Å¤QéîYm÷²qA¨¶n^÷úó¨Õ±®ÝêJÕhe>ø‚õÛ~·ø¶"9JñÄ\ê%bÁ“Ɔ¿Ç•²Ïó¢ðsgé'4Z›FìO.Ý_+¥ìe´±YÂ¥SŊeÕ0þòjQÈ;¿¶¶_%Küê}à»Wø+âèòCaj
¬üÛ÷¯ŽÎ!¯ž¿ò¸vÔ¡¤YÓZš†ãš¯3Yråì饐ÌàŽÅ~ãï…;øЅiV^ǹ-&ªaZ.\r’®}Š³äD»àÕ*|ßTÀfo,3””À'º¡+ùÂÂ=-.WsPói).“MMõ»¯Ò72^k᱅aqô­[­Æ…ñ±ñ±ñ±`+Þ1ñÎê|ÎƳæ÷äC¡ž:R͝ž¢ÅÄ-{Œ4tŸ#dIÆÇ.Å@âyPÌìæ:!ùšâŽ¶êø•‘?“A_ÂÏØìÖø:DR†Tüù÷Vµd2I$^YB”MNÔ?Œ]åoùÙÉÇ£6ø/×BëªuŽÇ.¬nˆ¨Ž‰haS
€ÄœìŠÑ¨íÃHmÑ7]	+8_$³×G©âft3‰ÇD†ÖmÏÝc;¥(çt ÒUÉØ­BꚑߘB?+"<#‰ØÙivºÑÚV·Ûmv]˜À·z±ôœ(¼¨`õ¾W4èR/ˆ¯äuX4óßÃçÁÜoùàÐefAĵì4äRçQ
ÕU’kô2b;ì]F_U*dƕÖ
N#eæ:ƸÖ.‘Î΂ɷ6º{æOóSa°ý/ñ¨—¼A¦üô„YE­e¾©•áWÊ1µÑ“A¡êã;$᫊dӑG²eÐþń¾¶ì[eXi˜æö¨þ yàÞºËNð¬mmînñNэSW)‚-ˆèùlIž]6ë#÷ºp¸ùï·J'£„_û¸68_âýåežLß±Žñ$£‰EÂü£7š
)h®.X³tyu67‘Ųµµ¾^X¥¦IάËÇ
kBñÓ©Ãds{_âwÃÕ¡’Ön
}kÿ
:(ðÿÉ´±D½¥ÚrK¯iÚ²:›ë[(¦´µµÝ•šXº:”%È	q¯ÓAòóŸŒ(£Ý›+ŽvÕ¾Ï=ºb;Å	q-”J(ˆFü`õ‘³­Ò‚h†U¶ìÀ*òTܶaŠp
ø@äÓZ•–£ä†Zºäó‹9o†dïô)¦ðÚNM+tZñ"p*áºÜtd'0³Ò£T<-P½„GøT¿Ù¥TŸ­­Ýn³³lìÖ/‚öv™Q’µ$SK¤“eM»bZUìèÝQðˆ×ÏX[³ÛëoH÷¢Å
Y.û=|Ñg¾…bõ
»Þa¯Ø>ÔT(ÿê^
…Ðä™Tüêr¶AYH¶eßDÛ»”Ñ·µ»Ùe^Hñ¤!ÌН¸hšz³	•‘ÁŸÕ÷	
œ¨ø`Uû0{RjH7å«1`‹Ô_ëEȽÛb¥À#ÃöÊ*-îׅT‹<,+íïtY”ÙÝÝ|Ȳ¬pú¼ÛÊ`l†„/™Ióo‚ w—Í+C‹’õ¼T$qÕïLºŒmÆLJ×jE$³(#žtÊ"ãò/äG¶LƂH…GZI„Uw6¢µíõ](PÁZr¢Árkiº¼6c¹ëR\Ëq	âÕ=;™
´þ¦*dT…PùP3æŠOÍ×/=a)
K¾h`ˆ¤WÛ]ý[à£EÁõèo^}ÕkºªxZ/ÌIVŠ¹L([ž,»”ƒçsUì&ú¡8‰fù§î¼rö<(ùŒÖ”fjºÆ¯‘,#d ò^ƒK8 P'𑅊˜õL˔nQ$ǓٝŒ(²Þênï5;†qnoQ»³’µÜ§‹ÉZîôëljCZÿEç÷£s*Úé¯cUÂa™ð#VÀË­ÿQ¥âtÌ=;·ƒ‚cbš.¬ Ù½“z¼òyaXìØÚÜÜ¡¬›ííõm/ñœN!
ÿ?x%°!O7Ë+LV°Ò kËÉ{½x%—èäô烓£W¶n¹dŸÿRôÿw õeo´*2/Ÿ	¯&óýSôÎ:éííîzs§{_Š&‹[¥1gI©p¤ÿt¹SîZ-þ¢©ROêHߑoe„°‹—[\ÿϕ”Ø÷¿¸(cOÌÓ:«è‡ŠâÃd²|²è$Ìé(Œä¯é)¨µPÛUX9£¦«àÔvU¬ðQÓY˜1UÓa
x¼·
sórürÓL‡!5+ôÌRTM$W‰§:"9²«[Ô+‹k%Un-PåÖB[¡ÑPF3²)*™àŕô.y·¼Þ½Næ¬òÉùË?|8IdÒñ"üù-‹`ÇÏ¥b¹òAÏ"âxžgb)(¼G8PîE*;þ”æKˆ±1¡B6°b«eB6Oêô?¿yy;MÞ5håjU<¼ÕÕUŠóåè; T
<%×F
ðš|Çûzy»,Š¿¥Õ«¢« £|
Þ¡#ü€?@«R«›K·s;ý´þö·è;îÇzŒðá‚(>¼;>lF«ÏԳȝkìÄ]ŜµBÁsMÎg¥hjuß=˜£Xæ©ä3ŸºJÜÌ»›ëèîf.y±ÂÎeŸÔó.¶vwIdØ]ßthZÝs#±e˚—(
˃±¤«ÏH¨ˆ6F†7S2לsa>ȞÝ͏Â(vêccrògÍevêEœG^‰V|«t
xÖÏ¢Ù©*£(36Ñ÷³ÇM’pV÷­Iik{½ËëÖí4»,\6›ž3hœN
v&MfkÙRN¸Éªxçsnkž z-¼ñU{¤Šß
…3æo±dCÙp}×!ã<?¶²ÙãÕ;759™nAo¡|Sӛ6[Ð[QÄ©éϗ)ë{¬‘qêû´ •+ø젟佚m”k¿±S͐81¦Æî&SãÖ®§ÉÞµ3ÐdÍÀÙHúŒmZy´NÏ— _€¥¾Í·¸ýÑÜ$ _9+¥kAÎ]äà¼ÙÝSö÷p /Ɇ,‰Ñ‰î¿$+Ö4S·2Ìwþ‘+S7²}ʚø~öL#¢%ä;¶’@¶«~©ZþÑ·ôfÙÞÜá
ØÝúM7ÀÜþµ	åMØÞdñž¹ßÙãz¿m€ÔèO2ÿ¼±«_ã°jÌ@uæµãýl­X+PÝ;=*|mž)«®+
à]ò³^ӚßÏ¢Ç5vžúK‚–ñûÙ³ÚWÿ)ðñ»o¼·
’3´·±îÑ^÷Ä·„k×`ÍsÓgˆà³iþo?º`Ý÷5•Nlý6-ÕHÄ
»ƒ ÖH˜í|Ü{G!,þýú­òóÍàw±6ݒ—Z$áÊgÍ*'õ;Þ=?|stðÎÛð
æø{;fgó
û½"%
–XžÊe)®™Ù”Q暒79—)®Í¢¯vÌ/ÁPÍ}× Xtð­N¡$ ÜPÔúæ×}åÅkNìڒ\BwyÎ%öñÝÞ½ÿôî1« }”ükµ®P“èi>é=•DЧŒü“
_e‚¿µ{ÑÅ2­¥£~ò5ºØî\l¯o´Û»—Ýõõ^ÔY_ßÞÜ|Ôjµ–ûÚ£µµµ%¿ÈÁ'›>¼íÇXP£sr.U
‡±xQ`á›dٔ-0B…šõj»”tKé‘ýd"ْêÙMGÑål:›$m}ù)ÿÅë¶ô$74Æ™ÖÓ¯ÆñêØQòL8vPÛ؅Œê&º4ý‹ttœ“³Þ¿:zsdT¡ãwçNÞÿtrtzúLYx‰wþµÄ]â7Ç<z&Îÿ.u»¿É¢
ŽÁ9Õw°®®IÍ¢¹±¦"»,cU
º'k<I³É繁Ñâv[[Ô¸°ò%@Æ£º˜Åå?tqQ‘«Ä!I9™a#¶†ñÀÔHªdÅo=SòJO’j~~Öb¶!êÇÜsyî¶>w_ º'ìEÁ7þÎî.­ýñÐu*Ñþ?ûbüºôe8In&étñu´“q/Þ½\ßê·ÛÛ»ÞîÖrbØÓü+1l‹}ítIÃ¤¹OoÇ	PDòéd֛F'üò©ž©—%
^ÜOÌ&
ӑ&u¹Â.LæaxåDS–(š%±Ò¾J»@1™â\°ÚE²vß.eFiµO±˜®k¼|ÖB˜óÇ»-.¼|W‰Å¹ÊyBo“a6¹=Ìq~bB½¯Ó}:óh}ç×Ñ÷HNÑåɈñ”	¶™Žˆ¹“‚éhÅ´hå糃—`ªOL§³Ñ$ɳÁ®µ‘óf£a<%ŒéíL¢Ã:;Û´‡;r6=«q4‰oÔKÀ©¼
Ւ.2\ˆ)Ó	¿GÅd›Zî¿Ø[†Ð+¨WÏ4£w3ª&rŽ|J‚ÒJüŠ§XÚaX.éCñ@¨'G.ÔW{Ûë®r å4ú”à!•o+*jø6¾iF{~VVBˆ+Wcš¹Â½ÀÎCKaÞütð™
WÀUÔüÇFZ
I6Žÿ2K‚sÔDìuÖ#]!µõ8Œ:³=¦­&ïì.Åwv%jé쬡5¿å#3‡«tÄ=	{p…RA1›ÐÛa‘”J9Snë$êPÖuÕÆtÔ·÷®¿™¶¢F¡Gr”•ç¿_>°7t`im»rët;Û|j¼Ñ
}µõ'˜‡f.ùÛ~ðØ{3ô_a3·&”¢`Y§Y†R#
CØ`Ð[
ÖéH$ê1W÷¼·Ï½èȂÚ'±UT9Ïr
,ÜÚÆf‡iSWc¹+HÒ|¨6T¸X+äxUAl‰^‰
¿a¬©ý­—ðl¨@¿·
@ËhØ/gGΎa÷,úG<8üøñm”\šÃ?Uì¿Ü|‰ÁRG¡…Ž
·©o\­²j[8vô¾o; éêÝ´ñÂ<_Á"£zK†[:%ü[˜ß\¦øNN§HÝhGŸ’Þ9DCn™­ÛڐXâ¥÷ΎÅ/d2ےîŒ%‹fZÓ¬Ž9ŒÇ¼åèÌ퀫E¬[!ñ°1'*Ru¯ øqURg¹û…ýW?̊¢¬àЖºåϚ{þ;_­Ò"ka{*Œî²O¨$Wb[µÒ÷ƒþYö.¹y+k*k+ò4’©‘–ÍJS1èu€fý5É.òÓ*Ïò¯öœÔUNd*̏dé…/;iºª‡Èõ`­ª'®³’¹>…é¯.”ÍÓjøôäèàÕÛ£j	9l#2ùÖÎFo/62ùÖessoo¡L^è¥V/´c]”­èò§ùi‹äqyøá>Ú6Öå]Fèm~›"
ꗀ±¢<á&|.!¤&_ãᘹo?#h 
bÁû„×[®0gÁzèÔ6ÍK¼Kü9	Š\PmïQË°Œ…j³\ӎ”ä$bÈ2AWTE Í—>u¡¸nÚ9ð‡ïםV*ôfkÁÁ»?žM¨LJâۃ„±
’/É@*f2ÐڈCÍz±"W?j9D;ªIâ F×ïä7ۊ‹ê~ò€Oû
	m£‘¦¿ƒ¦Z…€±0zTh9‹\8Ι,ä–Úul?Z«cúÉý!z?UñÑÆ}“!r%­èT€èÐÖm‘ã›H!>’­!NuÐ'9ó„!Df´OcÁÙ(‚ÝM’K3:š1úÈÆ-ÞéØ	ÁIo
bâåéÄ2!—L³¡‘Ã	Vq<ɾ¤}àf´X«8ºS¸4r+Sc<¨h(œj÷¢¹±»Ónw{{[†K-Í©ü®²+¿1É„Rbþ”¿E@°Y>½š$§ÿþ†Ÿµ¼½€êd¶}_%RŸZ‚58–2:ÁҀVOzæ­Ö ý%±O¸ˆÉÔì:i][J}:	v•K°ð§g³rÌûŠÂýxhN‰a¢†ûN…Ш/öW·&Ù
—.JÁG©-a%®D~i(9M:(êÁWlPžÖ°‡Ÿ²_š‘»!r’âñÔwÎ08³‘|Òm®h¨d"Ϧfx)8b+ÇYDžsgŒÕ9$>Xól[øÇo°%TiÕ_A7«Ü“(Z´)k‹7%ŠŽ‚~åƒTŒp8ž¤Ðs€³Ä³”;Þäh›—ƒøŠAÀ#ZŒ‘Èֆ˜‰škaðŒA@'©Q&±ìÍ•Ö‚eÒW‡°GpUÏQRøz#ùÚKÆ\[ÁÊ„ ‘²Éeã<ÉW›Ñ5±°Ç´)©RÓM܏os‹4Ûdtýq2¹$FF
Œž;M‡àÆ|H
+»Ø>Æ87°qÉ"‚B!,]æÆv‘¨–[>¦½;Ìú³€Rݺ³
ka‘Æ™r¹ÙxhجK}P異¸¬hE>*ø½>ƒçEË©D©@ýâŽâŠHtr´$J*ã0dkn®‹ñÊ"ì÷ _Êbtz#n0¬=tî@¯>%\vç&‹Nߜ|Äüb³ØY7ˆ ʋ%w¾Ø²p³‘y‚àÕ|J«žñ
NµÙyf\¨¾†ºàPÞa‰#îL¿››¬æQï“dL…Ô؎õuÚzx/ÂÞÅ¿xh¨“•E¢ë
±›Bñm¸“Í_¸
îè–Ká d_|ã.m|¢m‹Û~â[™ÊA“ˆE•6óä
ǔ$`)x× ¸…µ°gÞ¹œQ)!ė–„äÐÅLÁe‹žé×¹è^“vÜñ+ãŒÏºÂÓÛìF$tŸ}
t&C°}Ht@ËO¼.ÎsÇ©>Ül¨VÛyçå·õ­æG]
²ÃÝ´/BØeF‡ʜdÆ¢Öª‚ŒŒ™ë²2‘2ä],ú³Lá©N‚€N€A7?ß´o8çóËï’Ih6êb1-©n£Ü'ï M_—ËHÈðe‹Põb–§ñ/‰W·[ÈÏ“`³.D9à>Ê!poæ OÒ¿¢¶±8‚õ V•ÆáNìsÈI<ÌÆ·ª–×è­F½½íVw½ÓmFžèòwõ
‚b6Ɣ£ŸÌÇÇzÚlF'Éѹð«#Æ&9|$æ—Ãxš“>JcÉëknRUs·K'öߔ	?VAì&½#i_?žóô|2¼šT7!ÑÌ<YsOzœd˜?í_è_ïÓ¼÷Í:~7ĉÓY
Þ
O2Šµò£ñ07bz<¨yÓHÕ=Ⰵ糩‘þŸ¬~jXuåCs!Ð_
æ‡ù(ëÒHÉ<là«e*™éZ~Ë®GŽ3€ù$‡ˆ§Q„”!àå›Ã?œþ'xcš«¡‘“[®ÃÉAG#%&¹2Z‚pûÌ*£†«?‹3³Ñå‹õóÐC$§Á¢õ¯¯åž5ÇÎx¹„F€s÷&uæÞ~J)ŸÏϜ8:9ÿpðÓs.9ø~K½ý·ãùéÑOoÞÚŸÛ+Ÿ´n”áæÐS_ÉWhÛ\¿*í%|†`Ü%Å~Š,1qÉvð·˜F%ãd¼L3no¨>ޙð3¯ì*ÐÒ
;iúލ&K¿ÂÏ­ wŒ$_ØÊò.†[6g»Bùx©-[«[ô÷¯_Ÿyk<gã–îcÑö1ø?oá7Ø>–ñeÄKmm]¸Š¼…]c_Ø£ÖSPˆò.a0»¸Åµ8æN-ŸEë^x,‚'|ÑûÀ§þ­OL&ª_Û¨!Ì䩚kSBe¹›·Go_Ìë&¬_B‘*¶']žen¡wò¿E+
þëÓ¨4˜93Yû#˜K_øþ®_ðÖâ3¿p–ñ	õgÐòf®Ãœ%\­ï;|Ëü:W,uˆF˜Å¶´C.ՒtD¶ø~}F‚6„IR+@eªQÇ}ÅCö´0«BCƒÎÙ’(Š¿~•Lm¡2úÁäjDÇ.Ís#¾5ÝÇ=ÕدM­"-ÙÃò1š
Ù„ö˜«>žÏ̶Z7°µ6ºë-t¶Jºö
ǘÙ?¾‚|õØՈå2lÙÃòp‰HÕf»Y1Gµ‚ßýå¥ÜÌ4nÔ[Ž6×÷"ê“DO¼©:ԍQq̌:]ïør0ë¬1té÷ˆZ-³gCfl·T¶D»»„õÙÈß«’‡(i>FbfryiÚR}U÷&3¯x
ãÞ$˹z6MF6š® ®äGƲûacr‘þ'¦ñ0A„•ô» òӉ”¶yÌq׏ÙGhhLAð=æ•pÉh2‹›ÙCT$‡*z!5꒔{”Ú¡1áuwN­ÊÑ;~\YYÙ­i÷úÍÁOÜð圙†š†ôwÓëۃÓ?˜3׉~÷»9_\Zräir×|Fq‚6Y [ÖIØVYyü>œ—=Ç,†ÉßùéäýÇ++›U-ýÏçÖÿõhm¥1·C\[õDœƒ˜:†k§[—O füÞHÎOÿó(¢áT^Æ¢ÙDkó×fuÁ*/¬úÑÎéÎõT\áêÏ-19%÷Gb§‰õÒO‚ü’„°ðÔÝE÷º‡xo2q95<^ Ê0Ã
¨‘’xê¥WܓSÊc|SÀÿÐ;Í,`ãŽCõÎ\…è#ZøjaW@sôâRï•H"œÑËtzz^†sºÓELIF6‡áÜiŸ
AD—ËlSi§æìä‚ãižórëº,µõ%éÒ´ÖÙåpÄ­fg¯"¦4¨Ž¡Q¥¾‘s`.bëMÿ=a#a¨J$L‹Ë“¡
ñ|fùûiþ›ËØ@”8°Å`¹7qsÂvd:¤â0+åÓþ¨÷A¾¤}Dmž½z¹¯•nՖLr4M[žÕj˜Ä(ª—W|Œ¦öǸ÷&¦Ó"ð(?ýOFsŸN³ñ¼·Í0ô1”ãz>$“–±#dg1F“ÜANಮ7™Ø¿=Û&œ˜{J‡Ã¤Ÿš
˜‹7ƒaZråýÊh³lHeë!Ù h”;{ÉC‚7Š^·š[›ÑZw“þt‘>=yO›òGÆ¡}«{æ›ê¹i|À"Ú2„퇄+•@5­k}•i¬«3õ³É‡jȵW&
D«¶jæt{‹{Åsa°}žÛÄvùñ»¨b˜ðRjeK‚ `VñbØjn%Ÿ»23vÂؘèɄ	ËÊá¡xç$SE›-%Ÿ?¦3DH¿*Φ9ûØØ%4û,êªRW=Ša®Z7Ä1@»B{ù9ðn¹OßPˆõt‘Pّqf¤ô[Z¹ËÁ,WV [b×MJ…¶©¨
½—…éJزÿ‰Ša¼®eAŸ`MiaDM¿šœúpŠ ®bÅ¡&s~†Az™ð–؇ækÈâÓÀÉÔlUŒ¨Çgnn\ò˜‰‚mƒ!ÔBXf†/
4ZŒUÂ4øL“3ÂñOêã$é™°IÕ
 ÖÉi$°Hi1ø$´]#VÄòºÜ¹=nÍ_¢oˆÅ¦p›A=‡Ø3Ž®z=
ïn‰’miI-sæ%̯êü™Ãðÿxpr|ðòÍQôæèÝOg?G''ÿ!5ÄKu¹Šng-þôúÍÑçcÓÉ9½-w쟑rŽzßÃç+Lç­ý§E³\0ˆyæ†òÛôQ†óK,¤»÷_½üø“³Üô“‹ÙÕ9Àsº¸y±ŽþVÕfOš=ת٫l·ÉϚ}¿e³_ÙvKŸ6“°u3ñd?×~Û=o^ßh¢êοqZSÝçMlþd
ñp18*”K¢TDöœ€`)¸‚¬2^•Êðš&Óàòc°í}
Ê+^“‡äŠó~i ‚˜NB1Úý	~DìçòÝØÊruõìV÷ÃY0èB;õ…¹Å÷ÄE#¶›Š°p
U+ñS2õ¿®Dñ‹£®¹ŸúÍeæ[µ|5ß.wWú<‹³~óMÒIÕl;Aç­!™Å¯ý€ÑÞ7#®Ø§B7Å~hÇ]Gf•›½4=¢!Á~ðš’!6b]²ý”?÷$ž\ušQá—n;ԭÒ]öyéÕ*õUÑÙ–LÇHÍ=¶{¶jQ¿óivžB€ûHPîïÖÜ"­Bi¿ª·{ìò:,¬ÁÜE¸¯w€Œ¸ER~:ºœÄ,[ ±DÒ`ºëÍ
£‹l¬¯7··=]ÛþŸÉ$«ðB
Á¨
Je¢ààÏæJðøa©Ϟ´Tô`ŽÌöÒáÕÂ_»µï»¯/z¿Uù¾W¬´[0ç‹~«‰Ì¤Ô[ptlNEõónñæ9ú:5Ph\ê‚×x•jÆe‘–<™zmßû„~ºÀV`Ç͕Ѓƒäë3…úç|]Ÿ’Þ9ÍX¨_Y9S$Ù9Zœ$c£"šY…ºêG²æGAäʍ]ÁG©¶ôúýIDàßûA˜ø؜ªÁmË(iÓÖWv_¶Ú2ôÕ¢Ø
å)—x½xp£{<bÞ1£œ¼Çw8úÑEÒÛý¤Ÿr*&¾1²µjǬ¥ñW$ÔÛHSÃ*Ž·\G_Çð…!—C­h­eÕÌb‡á–F=BÑwö˜!°ÓëýeÔrÊâÑ¥oQZU•Rí4ùêNJ6m$gÃ!Í°.w`Ôè‰D¾m{Šõ	yÝÿ(ÐM£¤(ÕF.–g?î#±ø-ë_%Ei…”.2O1FÅÁäªX$‘!‡¿
¯i)/®S5^TàtI÷³-ÄëWßÕ¡ ²lI5̉_—OøÒ?ÝuÝfô˜_{&õPA}ßÏÈî ÐR¸}ô3ÍHrÙZ²ÞbøÕdKKÏ!õKTéÂÈ¡Ð.…矏_åÎY˜^R^ÄÔÙêÛ4‘qI5X)ôÏdm/:ö›ÑrtZfƒO˭҂–I¸S”@Ìo@²_îÕjòïØÔår×uït%±Ù_G&•FŠîŸçYðfôŧ©Ãø-‹vW¥È… È|4”ŒG^m½¶l[àZKYéNôÝs»*…´XŽ¼š(ù Ä†›Žè.$ï)³é©1ÿHÎÂÜöUÚØޑÌØûÓ
Nà(¾¼Ÿ"Ÿ€¿mn
~ÓÜéôGX9þ /™Êš‹µ¥­]ÿ3s³Î¾þґ_ºŽÁå
ãëX_ð¸ã½×-<(¼×åŸË3»´‡\L{QC_i­ø֓e¸k“9,iþ
U2ÚXöF¹ÓïsáÐ+¥ÂuçR¨¯Ä¶#F‹îî®7»ÈˆÚÝlvwHAáÀÍÀA´¾ñ9~­äkÊÙ{Ù±~IÝߥjÜftý[çãý8Î!Ëy}5©¢iY¤µå­TŒÕÿ‡½Ø„Ù2í5k>k¯+qzë»÷g‘éq†T®zë%ä×é˜=0þ²×}	²S3rŠMbaŽ£æ½J†Ôì­BÎ1§¤apà­(¾B–I 2¢l=‡œŽ²)ÑÍÅ'‘¥µïbùtrKw½—"–…Awxv™ŽÒüz_‚)õ+^¶Í?ø¢öåég’öÕ3Š2ªJòµÂ©™êvÌ
œ:C†ªi›c¬h%fã«IÜç
ŒQ+þ)/ÚwŠþá˄ü(«äŽÐ¡S犨“,ø¤.6ˆA
äŠ;¼X/hßAhPóGżTïÈp/V<ó_J^ý%uýoFdÙXß Ûw³Ómv×¼óNkê‹.Þ*¸°"¿¤ˆ³Zº˜<±ŸG…‹©—¤_’¾…m
¬^MÃ@åv&[ìßX¶[sC•­vB2Ýs£¨ˆ[Ù-­×þƒgv´1|4-c T3f7ƒ¾¢)I”ÉùNsß(¡H,©ˆØ?ÛlÄRJ÷‰}ñŒx5:§04׈
uOf#ˆ.dã®sK3'Äöð»hñ6ÖVJú©ˆGPá¢EWDeò)žÓ‹<#°¹(z”íiášXFKð
׉ôP¸%Ÿfc+|Û7	ÇÙêJҊ‘ÉÃt”:k¸¹±Á¥>Ëq°éTüår˜ZùÁ‡c

&Ÿ<Kãƒ[Î0Å<¥§i–™mŸ&#’|Y,NbNëB×ÈûÃ
ëš“I›;fÌB­ý‡ÌëšôDzA`‰ž­A âb#sXƒ9¶È14kI®dòà¢e/t‚î¾ÑÝ¢DûÍMb‘ÚQ‹ÙZ¹‡°æˁ´ÜHdhQ-~®=ðcžH¸2O&¬(T+`Z
líº‘ìÌ)·WS”®­ñ‰Dù*Uõ¢ôÏÌÍ	Ïlqã6Ão#Ҏ‰VVü‡JƒJ„ôÃH?‰«fù|r¾|rÚ\G)›µÍ­½æFç[’Ó«ª_¤]ûAHEõ#2D\“{’ôSA™fU’wã9»dz‚xîåNEÄ#î)OÓaúWÆ‹Ñóål@ý¬Ò`Íɚ×JÝÜY«‘{p‘}1·áKĒQÞ×#¹­9'³dÙ¸½Êôúu15:KΑªˆj×k!ˆ³9KhQ‚•0"ðÅE"Ᏸ>s¤¼p+^B6˜SÊZœ
b$Íâh`™iÓ.²	áҔF™8˼Ütáæ-Ú7'—,Ú¼%ö;+ož”9™øSY™ÊLŒ)`¬6œÞÉkQgÕF\Ÿ%1š8KØk¡Me¿QÀâs¼3§;ΏG&rU}¶ÊÕ4ܨÿôßkk°A¹&û•Ì°¦¿6qCX[iT°ÃEçu6ùCrË°b–†\éUÚ?$"-~ˆ5	sÁÔî6ß/µ3Su¢Bi¬Ô^‚jÑ5’>«¾\ñ(ø˜~!š/–ü7
ž1-Z#žPWByÿÎ6iY[ë[¨‰üÞ·l ç'̍*ü¦ÐKëõÏy*æ|Òü£Ò¼gÇb®Âß?v÷ß½5¡»«ÓÉ,	”(„ÊZÊr,‹@WæŒE¸URV+`²ÇHÌçžÀÑöÖ£l*ñÂ0³®ÁUó$æ”Y›£hŽêIõºQÈ^‡)¤»Y¶‚Ïßâ‚4p¨z	¥6ÞëL;žË9¾
k¸í/Ùπ>^K¹mÔÕ%ª!sÖ¢¹d͔¿Ä‰ÎFwÈpºUß2—q¬­¹ò¸/3	M™…‘@b¹ð.t2Ž§×rÁ<xû܏ʧ“• ÁÅLÑ·!8™^?Š
lÁɸ¿%¥ˆŠãÝ«åI/=ßJÈvñƒ_äú~Xð3ð*‘¸ê¼?‹Ž£Æ÷æj‰‡*}‡²ŽRu¡Š'ÂâäÅ- £-O(þKVwÕÞõ"]¤1xË#JÂ÷}³L³U¾áGmً´éÝq®ÀEðsۖ¨*­)~óè]pôi¥»{ÍÍM³ÒÛ¨Ùw—…þU"Y
8j–xð`eE¡·õ˜g©úðTßm?à¡·˜àŸ[Ç£âñx’'Ș±Y",Ê
z¢Kn ‘ü:MálêÂpL—Œ~3¸õÙ%9‰Ð
õ¤øûy!žú§¯Z¹yµoûš?ήHÿœ›‚« #ÖI²Œ_&^9Í‚2:ÍlBõúSúýâ(É$(è¤vï̍GAŸÉà–6ÑÈî$¥´*/‰
:ká âP0€©
á|ëyQBi9	¥u?£%°ÈáݲKe~ZÀ|Zà×­~Ù-è–+áÑÂÙnáÿÍ‹œ¿É€¹óµ,¸Ø¨u^vtžª$©)c‹‘ÏÍ[êôŽ6{¶¸JÝns·­moo5»EZuÈ|-ׁÎΩâ-ƵD¡ÌA#tF¤#d'¬á]`JŸ
ÓŸàFêG©€£Ø¿•øõLhâ,OÌ)zB>A¾ÿ-&ྠ>¦š÷Dظ	Bï¤8ÆÀœ:Ò¶ùùr¤ù{JÙ¥ƒ¥Ëi‹:«öK/…Œ>ÆD@²‰O¿ÆlmPâ’9BÜ%gLæ•?QÏîdžá„9‘T‘ x°01±ý$oB,7l0dyʨi*7
’«X†Ä¬Ç®>,*•öÅU·å/gÓ …ÎHü쀵Ûß$«ܓ”{×´gN`P…0eL4J¦"öÊøøyæû,V¨Ùò	᳍€ˆ™­oKÞVÜ—|õ„~ž8ë)eûÈ8S9»°Z 
ç"@:e—h‹Ýޅ“RËgïÀO¿}ñœ¹(sDŸE/æ¢Â	ÃAË
­ Ô_µVXšgtFU½‘¬B“bGd¿<“ÍJé„6ü^™s—Y7(¯!ª=-T²Â1°1…“‹!Y/Õe™È‚‰+ò̅”<
ïëúUQS°ZAæÊÏ+nw½Ð~sb,æaehû6
­_ùgnòÑ)ÞíŒ7’ù,ä…æ=ñ„ä*úÔÚ`XV@¸ìlhú¼-
"±˜Üf·ò›OøøAL-ŽJFø½½ùtNí¯h›‡lج—	*6’Ä¿÷m',F—z;Uå™ärôßE¯añ¯!òlò÷‹Ï¸Ï‚4f#…UàÄ´½Õ•²¾Q‹ïv*IÀʬ6%W~TL¿f¬\Ёo‘‘ø4€ºb”Œ"b®tm¤«ýq‘¦Á­"V‡Â½{ùÌ@£¨Ê?¸’æ*çâеÆ]Jd~𢬅ïF~Öf ³Ü9
óÑÚ½S.ËBCŠjreØH²½½Áå)Ö»J
wt„Šº6 ã\|zTªvŽ)7ˆÔlUDjJiœ€~dô]µ`,óš]?].oLÆÃÓÄØ	Íá%¯ŽX)ÀAsDîûx)ÏÄg¾6§'½–î,bóbKCï
(ê
Ý
–Á{Á&Ìí<‹%ŠHÄ2Î&apä3
.›²ò~4ô´Œ$žå8e³uÎSìþL#C(åYƒé@E0L–otiªI0M0ÅílQÑɎ”“½½1…M“5¿I	`Ôl_‹³7]€ƒ’¾BÂYø‰sί]Žahžçp(›ŠTRŸDéޘӴD–ûbïoÓbA~’{éL¡¾ôÝc±…nïrEÔîöƒ]a¶‘AOæÀ0üt@p}ÌE¡r (ÅñÛ§g'gç‡'Çgç§G‡gÇïß5VÛ¥%-gMË°~ð²³ç4¶kúƒŸNm3èê2R+n/)‡ƒúæ“ôB¡lèÒ2'ŸaivÖ)æ{mgs)¡÷^»§Ä&
KlÙ5©ÜY~2ùs˚[ò3õj~‹5ýÙÉ©žÿ¬à“bAQÇ?æ$ù0ô8P%@0†é¨x¥0"PÏA)™ÃŽ¸t‹Y‰ST•Âgö™‹Zm§ÕÜà5¡ÚJ,‡&°”‘úR®’ðù
e<¾¢ªj„7)¯Ð1"h–‘…Çÿ=Š"·õàièàò¡å"2ٌ@Ô¯ÁÞ¬le$$NÒó¨Á©Ç«QãZ[’Çl£A‚*XoÓÑiú×äý¥]*¦
´Â¦5í¼ïr-e”Ä勊.MFŒêñCƒéüÙT§<r8±
x(L;5è^’§V×¥çÂ-öª¤÷¤gûÖÆϹ—Ͷcg«&Ñ
«uDÇRóí¹KE?~Õ¤Óëýtxrt€ÒåæÉD+‘q)ÄwÙ
Ny2±NÙɐiÖÁªâf†ŽsfKØ¢ZìÎÃ_â*¾Ïã}…ã@Qq6T>OØJä{ôîUƒÚWO§\y$)ŠÝʶ9Ο.†&m2ßµ÷p4R±x‰U6ª™ÆÜ«	¦©1q؍=®B½uﻩˆ›òèï9rW˜–ÑYýçÄnõ€:^çú#-ËG‡îv;ë3?=lN:â>bN\«ÃÊcÉAæ%Y"Öæ[*ü¦"¢TÚ^ÆÓ	ÉíHhßèRqdº

¿¯Ð_PcuM-&9н¨ù¬÷„XŽCúÝób ’‹B’`»P•èŸVº0ÄBrDeS–öqeì+Z>ß\ç´öa!ýƼBå¦93‰HҔI~÷<òˆCüÎ\#~Ä]œÙùd¸"á$+–ê‚ïŠÑC‡ÓA녔†zžóíò§Üˆ6£ìÏ´®×µç‘ì+ŠÅ‹jQwÑZd÷JM7OüA“iAâã‚¥°3»‘2[&r‰¼ÏÀ”*VýοPmâð8Ù?<þOcIŒe´aRZ
;ù›{ÅQ
[?ñfêN1mù‰öÓÉôÖÎó¹
4à8ƒÝÎ6Éâ»;»Í1=]6/åÂ'#qHïÞø"ðX :“ÍrÆ<ãϽ§­Ý4ªlÿQc`Ù‰ë½ha”gŸá<SÆýXƒúôۚ—JbN½‡¸±Ê[áÜy´A}kj 1HØz…šì÷%ø z{k±Fÿ̖†q/“©à1>×[æ˜ìÖ@&“‰	òçÓ(`Xx‰hg®déEðp”Ôœ¼?1‹"U7Ù×&=*b>^åä£%,ÓGŸß|<=þã‘[ԟ)+Ó/¡$^Fk£¶5˜hCCќ]i†öpé…:Û´ÚØxþäÙýQ÷ê8sjÌ$ˆD@éT%WÚÔËSÞºB_¢Ú©‹aŽž·¾eÿç…z&/Ò%Ad=âo©ÚáÎBfj…$²ÙT^à }?¾6¬¬A–cË©Wk/õöKÒì.â<íI|álÀ5¶žyÁ€Çp½ý8!Kµ&+ªp“Q\½b³F͏gÓLJŒõn{JÏ­éÊBk_¨AõàbÊҟóª…'†¡ÿ’,—6Å£ “ä~t£$x'9ה3‚ÈtŠ:oRDì¨²ÆE`¨‚MXƒ:+l­žÔï¼o[)&˜f‰^‚%¥M!æd\Áx_£ô1"“_¸¬½DOEÅãŠäÔM¨f†tÁu²PØBVµ%Ó^!¼5Ïx4›®TtÁYÜÙa&”rÑËF5Ò»µuxl!’&±J;Ìô}C“éE:Òeˆ¯¸A÷3tlX¡­pwŽ"™Ä¥Ãޔ^zÙøÖÚl$PV
ÄÝ D=£âê 4Wö§ìµ°4Xq˜Ãû•ï[B¬{?Ò®ø¾i×~ßCÚ^ÀpfÂBe•žÂ<ñÅNõ€øÎtó›x8V£¥ÙÆé0¦´w²8úJ¸Ôµ6 =	Ê›é3ØìQd{óU°ÐB™œ¼§]®„D¢ºô@Y_Âa¾Œ;”ì,䃊IÎßyÍãüã¨o”*7ƒ~ˆälFßGÛ[[Û«H£[gqùÔ$×ø”&Úøðöôø§woÎÙÈ|ðñìýÏß||wøóщ®bÝ÷¨ã¹<"$?ñ63Òc
P!Ùçç& .4J¼Eìªy³)žF¯^Rši?͑oK§Š×&~O¬æ6½ãÛH&@KàçÃ÷¯ŽÎ?œ¼ÿéäàíù›ã·Çg&ŽŽ^½Zµ/Dæ…a~Õx염$)¦‡‚^Ìn¸ª ¤Ÿ%#ŽP*2zÇt<ÁÄ]‡fÊöÿõøûü¿?¶ƒðÏM1°Ý¾&½¥j7­›´ŸDf÷?~|i4š>lÿ×è±ë>züÙL<h”Y§àÝRÜðùI·/êÔgZ ©
^T[ûñª:#	ˆøý>yoÄ*‹sVØï?û^üÊrxNÝüû?¼RþùÏö§ƒ“wÇï~
¨*$>IàE?à¥0kþ~Æ> Yá±þüy
×dK´Ízª¨8¡‹WÓ;ßrI
™ü_°¢¿ª|$­˜UV—`Ì*”[¡î;ª¶k+K©urµKӚ*×SYQ]“y<qJjN_1Ä5S‰5+»hÐdÇÚÜ%ÓþÞýi~ºŸ±Hòý¬5G„$1¿K33]‚—ãBkkû+̕l˜¯„Âè­«_hͅF.û
å	òù
¾^´6UƒëºV¾‘i‰¶EÛ»ù‹<†¢ýäÊbö†Yo*Ø+t!ªk7kg';ë]ó—͇ìV$ƒû¤Ù¢N›Q1¼"ؔ
|	?sÐ[ܗ
îæqàö® gdAӜ…!馋r„”€3\²ŸÔÞH¾*v®Ñml†	:—x’RÁò¡E¹H<¶‘yp0҂ēÁmÓ#ß_“IFÁ8ܗÑ#nhµl(—8e1jÙu+bM,b±óËI§\úœR<¤më"¹J9¹˜
ÄÕ.‡Ä1,¿&µËÁ=%)–Ê´ôҔWEŒOw^
N©7®@'·ª…Œo͋QYÐÌX‰–‰˜¥C¸»³gáƎÀˆÝóÚêà•
ޅ|Ãk¿WPå:M¸(fã0I¡¤•=˜ØÜ>¢R¢b«£Q…c?gð¥
‘›r’v‚¡›UDzo…„^œ;¨
V,YÍi+C3¦-3õ„crÄD•L|Hç-Œ1âKäèÝp].IDa©æ
—Y‹IT¸uŠ´÷±áè|ŽŒTÁ؏þGÄÙhRÏ}›ãÓœ¹C–Ž›øVîòxê°¬,ªY
xðFêYÈAbcè I9€-¤R¤RÉg"CX² <Ä÷œÿ”M°(Î\¶>`k¼…ǃ'5ãCnæhxƒÂ¹pYn»¢n®\ð,Î݁·vìf4‰ÓœBàŒ<™!ÜËèC_Òl–nµC<‡hÈÛ`&Ýê0×áÐΩbži>sœ™èKªÖDÙGH?6A¬L(ÃLs)E·øÐRdûVg]Txô*‹÷l¹÷K1O¬‡êÞ¹!„»mì!Z°>µÝ
d,ó©‡LI?5HFWÓk÷ixF‹¿…¨ë¦19Šë£€ùµúÁt8.ÿ^á8,åֈ˹´²ô{m8–‡×䙡Ð_؆ÜcžÃ[yaP.»À†ÊaP
ÅËXÑ=îk¤“•G7-FòÊ/|É|áBp
Úïíi°61§ð.æ5%4ɦ÷/hìÇÃÛ,dGW¿Êý»×Ýmn’l.â͝oB×O4ÌàÌµP©øíKul.	‘º$Y[¨‘Åñ3Ž"£ yw"ì«êFþéÏlX™¤ìõI7¥•cÀL¢åì;8ÄÉCª*ðkvT·¦RúC¤k4 ©s@Ÿr|ò5&±T%ÕÒø²—œÌvnËØZ¤Bˆ{›¥ñ¦“‡ÝèFMPzZ¬ü#r´íÖT×ÈF-Ê°5s°ÌÜ©6SG]r!°¨ç§‹¨ŠL-&éî
¹3ü’pÌJÉUïâ½áúæ2´LÐKq¯
Ǧð+–-ì-6I®âIÀh)—~ž­‚B˒½d«Y·ý°a x¨¦,€ŒdnýZYCo÷d”³Óßb¡Z¨ ªÑNââÈÅKs¡•x’8Ô ©ÅMô×#ï%#£udÉ9®œÜb9ðêHx…8§–dM²¢SœKXöª Cxºía62{–'Ð_b"ãÏ=”iǍ‚,O
5÷’å>0xÀ‚0Iö“)/½éÖW’Ͳf=úíÃO„ežx:Fú™
Eä­ Áq•š*àÙ{Ÿüd´@`Lúå¥:e?)§Ó‚0©Î6
›BcZ`±åœÁ`o„¢Ž$,": sH2r•Ÿh¹Ø*æga4u·©†/›5±š-aQ29ÅC†#VՒ̍BŠ5¯ÿ¯d½aHŽfÆVFû#2QysìåI‘àøq¥Ñêì[‚"æIÏKM«O¨I„¾ ›€rÀ“ø"@bØî‰ÙTs²¡RÙ	GêRà&Š-
ÆÍ2yŒ¡°»|¿ðiîëŽßWÿ.°ˆœñäÉÅnŠÿYñãƒæÅå¬øfÌʖΆ¸”Ù U÷!„é«%2§±7õUý´<½Ž’›ï*	VƒÅ¬Âý>¢®:ѳÈs ð6®¶ã]”‡¤£ÍÆD/ŽAi±"+P‡„¥¼9a2•ËUéà,¹7ßÀ-O­Ô—aš…)1¤òTÂþäþ¹MLK}'ìðË×H\R'F0@V«H\$V2ÈC
ü‡š„"®%ez¦èRš#"º³¨á`ö-2,±×˜
WÇ\¦³¾µÕÜ5²t·³cþ4?™Í˜Ü>›GØLû(ø;ɉ×DOG‚0*ÊGM‘£R£hoÒaI‰«í²Ð’U+´_/GÑ"ôM24ÒÂ$ÎãI1ìV ä*âµÝÞnîamÂ˜ں¸¥ôÑr–K^ÀÎ.J]¨MJ(%.xY
ÿ$™KçtÖwv˜z778_Ç.°öËZ}Ó°~íó›õGÕ¸l[Ðm_
€si;])„$¶²@ŸtdÑñïa:ù“3×0tl@P¿QŽG]ÒAéxß#á œ“¢Þ³*6±Ø·
—!ðⅦD?„i	ô÷—ÇgoNÿ@Ýù+¨—V-¿,qåõns›·܃­`÷<L@k
¡«ñߌL<˜ë1ªZÄã´}ýØÿ‘¾æj”1²§§ÖŠ5íõ‚(Mä¡®ø¨¹Ì$‚¢óòœ|¨&èz£ýxeVvøhÍ|a)öÙ¹tÐøðÓùëï(aðüàä§ÓŠÂŠ/bšþttf4—÷F·±î®Ñ'±=ú~~mÖãÐ\ZŠþ	¨÷•GµÒdIâoŽ_889x{dĉsóïG%Y"e¯¦oô{&vD†Švc:=y}~|zþúøäôìðà͛†‹ñ}Kè®:#ŽñdÌ}5üU’÷VŒBŽŒqͼá	#õ×ôj»4Ã>>kð!ä^pbýÎOÖ»>Ë҃D–žCÇƙ–ç½éW=pô÷i€n·E~ôo#./Ä1¢ê
?HskúÖ²)®']™<
™»Åª>KÚdþÔÕAí7¯ûûñ(ò
%]4£ÆÁt:yGòÔjÔ1‚³“é™}>~õyp>¬ß±?â¨txvôù,ìÑÛÁÖ#¥¥få(Ú~ȬŸé÷xôÖüë~Oø«¾;˓Éù¥Ù/—Ú¿V¢'»åL«.ì$¤¢G'DC§Gg?4À·ã`äåÏóg9x»áïáï¢mX’ÿ9‰Ç4Ý25ѼlÜ+›\ƒäßT¸PHqƒËñ­äã‰áR—
ÛÄl³ã[*û“7*…›uSýÊ¢Góú°e˕DÐ{9K}š×ëI6<<¥~òFy·›¢Q'ûÆM³¦€Mv^<`lԉ٠“wçï]iÇÍÈ®§!bÌ
Òª·ÝÄGõ…Ä7:T0_zÕ{ Cõ†ðêý»#?¥/IÕY¸â†_½{qHxªÙ„½Õ¡JË{—Öo‚Ì\¸©¬óS"†sJMpÖ0¿ó:aèøEäTs…Ê•Ã iݘf‹bªBm'ÔZI§·ßX&ydiì5¥`˜~¦…]mõGk•ÓlÀt:åZÛOâɕ9þ…_ºÅ+Qހdé¤B5BU®/~¹»ðå®w]ò÷Hžz¡´¹¦œÕÚécÅÖ¿«kÝ*5·¥ô
[ιþšë9çþü7HPÃ-Êð7Œ+¢…šÇ­e=_Ȉ"µO!â\g£Ù…<·±»!¥9UœHxÒ5ãÿÎ&’àÂ^z˜³Íl~àVÿÓ³Á?p%4òø‹–Ž$ÛÚñÓ÷ìrÄN¹ùêo?vð±
¼¡…puï,màÞ7wsô„4µy`ò¥g6zŠ|¿ÿX@0æ3DEKŸg>Gƒ>ÎoÙðM|³Á#TZh|ŽÑ8ù];7 »J³š¯zµaؙ	ÅPwa_œß‰µ1Ò&ô'›U{ýŒBßIL—ŭקJ›ß¹h®Õ¢öûˆJèᒰž—¤€H՘ ¹ö›ð›Þp,‹*ôV¸Ö–儤÷åÙqØìaKGÑcæ^iª³Ñ÷Þì–È0J›5Ç
fCqçU7pô/HKú1g«U–ê?Quvs‹ãâ6;ÛœzsÕqi^vLš!‹‡ãŒ­Ã¾À–l›@ YĨî¡ÈNjû «¢[F^\
¢rÅn/áàÌüålÐtáj⦓Ýï#Y[Ê“ûcŸ“9J’Xyi~ÖÅ-
WpíÁM„™¶:¸¬U›Ù{ÅTïÛ]Àó)lª²|ÈÔRïֆK-`üL¤ÛÝfFYT®ä ¨Xì³?Ýè¹+ßQ	™«
J%¤†(™'€ï2šŒù¯~ÐßQ¯©¦˜Ï0–vI	¾mÁô^üV‘§x_óC+‹MöòI´-æ[lŽîoæ—ËõÞ¬h\YjL]’Óåf¸:BÉ_Ø`T«²z!S´ÁÇKtYÃ×U~(tì•ý\ŠÅ€*ÒOÉTC^øzå‹äõñç·GÖNY‰eWÚ­Œ6v:ˆx†}s{]€wrh\}ù"8×wÍ=®œkÖn!Z®]
´å± ƒUèBç¼~KÔ|÷ÊñRXN­ø©nÐŧ¶¬2ÉÕLã;ãs–Ϭ(öô‰D=÷4hÅi™¢$²·ªùÐæ͕à[PüWL˜mTŠÀŒEœÔáð¢0’ÓDaã_ã,{[*ÏÈà¶ìëy̖6•<5ÿG#¤ÙãB»ƒ7oÞžŸ¾…Ñìíñ»Óãÿ<šßÖYnE‡­»¾ÝÜ@xãæÎ^s{;<l÷¤kl´ŠÛU2’Š?wZ¡€(,Œ"ñNÂÞë÷#D­y-çɖAÎéSi5Zó/!ñî»Û+YM¡­•@±°¹"-½V‚[gq3)ª#~nÉZ¡çâQ\Jˆ·*aY¦Ý"·l?Th(eJÉ¡¯-–Uš;+uêÈ=uGO•G€Û©Ò¨>1¹0f·’É6ˆáAÑ5ÁΖ“)<j8+Ù¢{
€Š_ ”‚åžùôã_’Ûüúñþœ÷*^Zð#†¯d6îÏ}Íb–Þ4ƒœûrÕks_¨ù}‡ßê'—±y‡ŸHT³¦®F†Lú‘Øö¾ï?nFΘîuþXL×dÐû·ônM‡¾JŒ„"Z…;ñ^’Ár],'´œS#'‰Y¤ãÎV„‚»ÄmPm×üg“¦ïÍÇ{K£¶ØŸp<ºÌ€Z¼r1»,T0m­ä#ñˆäš7wÈbVùOÎ+ˆêZ€x€}§Rõ
˜_Սinp7„Ææûò„²™ú…gÞ§£Æ÷ùª÷ý"gñW—™^éŒq-µ´y
I´SD¥ÈAÌ2›ÿ’Mªu°<M6°"-F©KeñÜ«d݄љ¬Œ8
æ6wriqræy/žòf>þ3Aµ•¾}hˆE¾ÿãŸ2š”\¿ÓI6.Ë?‘y±-øÅêïñ~²
9©n†
ÿ0¥ÄÞÝÚâ<å­íWa<˜½Çi8·çBæHøç"¬<Û\ê\Ò[ó¦‹û*Í{‹vJF˜Î…Ù°GÄIªY.Á±ÄŠÇ昦¼«J5Þþ*RÙ(î6ùŠšé”ê
J4sAtÕ°âà&¬j¿¬Jg£Û¥¤þÎvWÖC8í×ۂªšË+¾HaÃ4E.ÍۅûÍÞ¨¿6<‘üƒi«Ó¥à±Ýõ­æÖè?“IV`ÛóÆαg’‡$ýøò\†‚ì5·ZRÞ¿;<RDE`mS£åÆFuJZZO‚>gcg6<å¨.QmiÓòbæ׉—4÷ԋV¾¸¥
ÀS<E‚²ŒýÔ÷¥ô¿,Ë6h¯¼³	û7l~D\¹‚rv)
â[3ŒOoB N.â¡µñNƒhÚ0W/”›úCŠ
[fÇWç=«ªëŽi´EþŒ8T2cî>#Ý"‹›@‘»T³eF)e¢IcƒÛ}÷6?„P>ÍžS¤L«7:Lf힤Åòa(ÃF»ôÛB¿Ý-
Ûíìqð£PM™ÃBw5þxAh{Mž©òX2
åpÄ#$’ówXÚNæFԖbŠ«#j·¶÷š]:³Û›Íõ¹“6Œmƒ®'É0N
¶V,¤«º&Ú^AÊ&ð*àšá^Î&éðМÄÆ*WèΦé·x¤õB–Ž„m9[1¶’›è.1—x߶ÿÎÏääÝà0Éýª°á´F‘¿wÑÕ/Q‰áx¼™ÌP8f9¦³i9(B5ƙí;<°JCõ½Âs¹»BtnýG¾Mìn‹Œ(ðpñ—šÑz3zùæð§ÿµÜ–×ÙXəӃÿµ„‘k«ÜüÈ°¿úÄŠ±Gw¨‚ÂÙ¸šd€[p!3É-1±xpߢæ*]:”+	.µV|(Öök}áâX-‹Èzȧgœ@jüC–r¥j‰ÓlV$B2÷C‰•cz‡b$S‘íғÙ
<µêÓ5²l žl¯ïÀAµÖ¡<~Š>½žMûÙͨÄìü"Â?IRC©ÊjL ̗âzÌqç”´7=.—Cw£vãŸt'.x“ò\öÂ"§j<æK¼A2TšŸç2k
†ûd¤6õ±x‘¹6ï³|ɖÍrK|ӓ5\‹÷iøäÕK±ïß%e­eÚ»A,J@+wÁ]
|a„Ë%ąï¼z¹Nì’	oókÓ>ói¾f»0ßϬ!B}¤í÷衼ûâ¶~‘·ð^Ÿmúr'´wCñf‰
å¼ñ4CJ*ROé¨oìÀ­fŽºù©kt^ˆW”{ݾÌòë’…»ì“.麶޽¬m=Æ)ì*)
¿‚»k« £vND05·TˆÚÊòÖåSgdâ<Œ	®:’”ڎÒ|¿–h6z¥—t‹RÎY¥ê«–÷V½d„ë•‚(ð|JùBçÅÀ¥9.HÍoèV ¡p¡™÷kHLÀu@A×Õ.×2GF™QI€7õcý°áX0Cšÿ½˜K8û¢‰ÔÄ^üg@|¾Ý!Ìxþ®ü¿Û;2^tvrpxtþáýéÙO'G§ÿþƯ`õóÑá>¼?~wÆ¡¼J!
ÀÑÙÞaÍyo»ÓìtwƒJ÷¾’XI=vn©Í«Bz¢Y(B»÷ßDZhŽ¼ñ„”Á­UêÎ,£éŒ2=iÒô4È°G¼"àIÎV¥ºn·§’úBxTÄdø¥U§’S$¥b‚VxµÔ;ÒhX0]‰k§Akkäð8eMº|B4×r¾™O#~¿êa€Q^z —ßõñÅý§fýß²O
i=*NiVšÿ¢á_f–ÀÅ3o‡üea»ûI2¶•ô³¸Ž—€ÏâàWîÈÆkɎ3 T¤è¨EیÃõùøÕSšJ—2C‹½Ù@J±	PÂx’]PÙfèC·Ä›Â{“qò;—þLsO<ŽEn>H¡æܓaI³ž<„,*„3È2@­
ÒéÔLÈÈæR±ôM'Ù
(Òâ™sOF>sÚ<q„”Ã×	“²zÛ«´Î@¸s¨æXÜ£Á4ÞÆ_}ò{ñ"êX%³ÐC]%è°ÕZ%ž©·ÕŸß«È Qš‚V€Î
^ÐÛq´Ì¢tÖ×¹/vì¢P€"G·ÃùûÐû…¶ÐM0U×xÞT]«ÖrSå„n…]ÆüÙ¬è7Æ0	göV N”Hró9¡GÜ¥èaþKªÄC9“W UŒ½Œn³Y40}ނu]ŹùÿÙ}†;‚č•ï|÷/g#ðå…7/’ þÙ*è(ç
›¿"Ï#õÀ¦ªË8Plˆ¹m
ù3(A»H¡wH&|¡m/w´-ˆ1Z@w˜åA0	ÏHâ0§Å†ì ~pîÁN2å¬aJÇ?£ùڒ!¨Wܔz!¸’¯²Ñ(fðCŒ—;Á%ž^Í&WëC CÁ~߬h ‹„o$S[qB·Îò²‘S8™
–αW‚¢H… cú_xnísÏ­mu'b®/è’3U—y™¿,,SːËCÆ£¨»¾nîáÁ€vÉßîlÐ/g½áj¸Yw½j%ìKóÂ6šÃ¿¢Ÿ‚B-8U0)¹U½o:L§hwF›^¨ÂU-Ä/’¦ÈU/—¼^Ȩ,†bYn¥äQYÿ¤DÝõ_ñ.¶²Œ¢rÉ"˜î¥Š˜“]Yl,ÞJMfpVU@"ÈÎR0'Z%ýƒ0“ç×8§Õ,ȀE	êø’Ky…UP_‰Ï']Í(“~j–
°rT©¸S®‹«Â"@§¬°É=À×£’ò+ì¿0rÂÛÒÞä†Ñy¡„K:ú’‰‰,ŠÞã6'Tm'7ª&Óµ8{’[ؐ¯À~ ‰ƒEðÀ“x*…Â3
¥òHàݸ^–Å¥ƒá×äRbhÚXòütžd1›ÇÕ¾R"\•Š.••e¾;©æFÌè
ådÀ R‚ÚusÓ;R”<ˆ$ñ€éb‰IyU¸üYGÏASÕE*Š6kÎ×ô]\¸7pS¦Ëlcï2h
Ié´¬#KGž§´A`s#AT³`ÂFØÏ]Ɣ‘A2ôÚ­ÉKLÏ¶¯F¼zi(ö=ª°SÛÀîÎP{¨¸Cq3–jrPÎWv–íçã›7á}}šÆv…™L²ñ˜Ìt)K/L·Ø×&×öàbã¼åB¬ïBD¹@Ò(Á2Ù±\ÉóNç”R‚…˕ñê\”^—&ýpU¥‘šÒߢÎHUMŒº*#%ýÁdkbزX®(FdÝf—ï_1ã[Ì°;³ô*ß³þÈü¥ªü_¹Ò°¸&¹mG#-êAêUkšµ.’ëÀI€B‡S •¢²a:Rˆà€åŠÐï[¯«^áGöp÷÷\܃* ”¨:,x¹ƒ3ÿI‡Fú 3žHÀd™1­>aŠúa‡QԐ‚€ÆµxÝ3gô€†9Ì
W7¿äN]•@ˆõuBt;ë{’bׯUÆmÚÕ’Ñʀ•%‰›¦Ãº6‰?Z sȘÀ=JP8ô‰7¹Žû¡°8>S©0ŠÿÀ
­ŠŒ€u×öBÍ!ðn¬ŠìQ¶Mƒ(ú0‚öÕÄӒû
AL¶p
åýn[jÒ
èÝQ'¡3µY)
X"×f$¡H$vºÍeߎâíB8*Ù$6C&Ûæ/äe©®èR»hâ{]Ü¢À›„КÅ\˜©‡e£Ÿ.R˜­Ÿ"à 1äaS˜ñ_ öƒòÈ¿OЬ78ÅCI¯#µ"N‚»D¨!*6“ùN¸`:›%‘Á‚˜|Ò¥ë#Ì^.D%ÉænïQÒL·³×mnt¾¹Š‡ú¾|FAPd
£‚,÷ÀÙ·Û~E8"ɕaQ_’UYôÌi8ï
cŠq™ó?™N›WßvÙZþµ5ŸZ°èó^“Q}?§CEÙÑû”¸Ž0 R,šŠpÿVBµX‹ëŽ;¨°7ZûÆíôÔÁ…Ë%ZóӐx
üY読ð¾Èã,ÆYÈDˆo‹£ÍÝ5b+Yú†ð…
z-ºÑhM‚Œ!Æ]˜Ÿ<I žãqúQ'â»3î4ê Á]Hp¢QAÚ) E;-Ë'Ü	û±Ì	Lt¾¢(^g”Q‚Íjë±hß¼™Á'ìÊ
» ŸÙ’,xAFX„H$–@ï҆*ý{®Ã‚	Se)_­ÞK/ª„ÜËvç3¿*‹ÅJ¿Ðb ¨€.p@ûæHötªÊ$ã*ܚ]]»5%g³ØBœ}Ž:ã±ZV¯ª•Óã¼
³ÜVj!³0G»´‚Ô²¿•Ýök>a®U‘«ú÷ÿǏ!
‹c´J‘œaŒ
ù¡îE~ì^e®j¤esêÂç~+òXY	º.<l
hË¡µ
ŚÉ%áܺü°‡ ÔÇQ/w}0´Éñ˜ñ…a&M	¸/בּ[Ÿ)'RfªÔ€®J-ø3•ï£Ú¶ÔŊÎ)í& à@¨qPÅ$á/Þ›.ÀÝî&EÆv»›ÛÍm
g¯#Åhe¥ž%å_4æ®EÕKpæýh@OU:{­å¡²[wÚ¨ŒrAwrˆŸs¦ŽŠí?…ÔúkæWêæ]«A·‰ÑŽÌžMÄo̧p—®ù¾‡iv:˜ÌN

¿JQD‚²˜
ÑàÒ Ç++êj¦ßœº$i›òµÈº©IÌ`ßY
[ñsÖ¼ï^^úHºhàÉátõÞÃ)pˆß!{FÄ9Wè½)c”ÒÃ3÷液ò„þN)ÃîgDåâFZ/ªÖ²[«ýíodDÔ'~µjŠǜ.æÜï蜮l?
@
°eä4¬-óWoﾝ ²6_P¡çyĖ:‘*)«K7#Xõí?æÅxâWR!„¹­nW§`y	£SÊlˆžµ=ÿ±Ôiª¯eÎRsócUxMWÂ˧@uô×Ò½¢»^%ÇT½FÓ8l….|hf*ž#ÂÀ
€°d-¢›„˜±ùÙí4»›¯’)EÈM•rÙÆ|3!5­©UXn³Å <¦Z0ר7ck¥8&¶Ï„ÀzüHK܈Sb”9šó¤oH1
j­ñ˜£æ¸'¦zDQM§¨Hcë94zÎàŠjÈá«Ùû —‡\„Ô8YÍ{R[¯o9aЫ­&cy^0	Ð\t6Ñ¥CLWº¤Tðc^Èõóa2¡µkØ	ã–xze´e-'nF?ÐG!@gû<šóå'žVöþõëÓ£³@+cG³¡ÏuàxsnÚgqfáúä*Ì!ƒ"Cl¯ðAd<ØV%±V«(‹¶3å¼ .¡•IYòÒݤL½†ˆç‰¶d#qŸÅB9|ђ"hHõ(ŠX¢í²4XŸ吁šl’(|šXÞúH«žïæÆ!͘W•ˆ¢6}Y¨ZÜÒªÆ^ΏKÑ*$
±h¸µÓÜØ4¢áFw½ÙÝX :ø·eg+bV˜–ʯˆu)|‡ò¯k³‡Îñ˜¸*›¦…]²±¥ˆ>¥±ÿ«ÅYœG´öàZOÂJ(o¯ªq¥v´\°eGÙNý̧¨DLO¸•ØïRãÃj%îäPoO
`ãk‹âü$þÍ[‹6"ɨ3œ zá	&÷¤¦=˜P)ôڅB;õuiúE¾P©ÇÊmuÓ6\f‡º…àÈKõª­¥F[ˆÒG™­Z–¬µŸÇ¶žªcèšT·p•u?<"Z¼l^zA°l~vÖ©KQÄ7—[,²i6èûi¶.þŠBõ¼*aR3.	Ítž}Ï·ÖÝ-W«`ï¨Üù·
‘Ëq)ª¸ˆÜB9JX¸ü¥ü‘½MT
énìn7Cÿ—ëÂJšÍÞa]ír»³öY £rÂ,mhd3V¿œ¾ö{ê¢ñJ’D*™ûÓöjh)cý•þUÉ,ï4£Òo]Ww£ËæopSúçªÄþu7ɍù.ì®w6àûYënno
ÒàZz›Ÿޚ5à <Izä£f$ÿ†¯ò	û,W™®pAºK|ó’%BñÓ(NŽΎΏ_YÐׁWƒa#¢'_öBJvåÓU¸Ç
Ã>'w”jLGÔ!£:qæ뜯räÚ¿\J-Æ_Ï)ôÐ
 ©CÝ=ªŠLaÚdü¨È¬—	/µ_L½!ó"BÿnXŠý‡‚G¾OŠ<£·vÙvö^gä|•PØ.’ÛœàZ5QqwC±ç‰Ö»¨ÝX
Œ×üàOZ’†—íÉI$QM§¥¹ŠÃ1œñç”Ì2G8>¿Š†jMˆà’bŒ)·I¢–Ó·±Þì¬ãôínâ/÷=}¤<~Iûä풯áð±Óc@Ÿ¾`Ñßú@ÍB¦æˆpWæŒ˜nÍ~+rùëìð}êZ…@@ôÜ!8*.°ŽÇâð…VçюQ0øÕ2ä*èB¶åw[ÕÌVˆâMçÍÚÙ&™îvm3Ü,Ti8¨¡ˆP†PÔi×|àQ-æk«wg–Ñ=™¥yºï<ï‚}UFebP&yÍ©sßϬstöŒ•îóª…ŒjøÎê²$š¨‚ÀS9f/(UÿfVy}ÎÐe矸hdù]
߬bà%‰ÿ˜$
€ Ü%‰Õ¨ÌÇwx÷þÓ;XÑ
Þj]¥†ƒ>Í'½§"È=åhͧì >ýOòÙ¸mĈeZ=äÇ×h'¾¸4RR»½×Ýèwê¬¯oon>j¡šãRý¬­­-ùEœž‚fÙÙ⚊?!'ò&8¿š:»`­?²öL1ÖNÁ
l(|Ó˙Ұ6?Ð̜¾ŠIs?’1«.^JÖw¸CVDn°ùðŠñ\G‘9Ôñ¾Þiïš;’kúÕËs—±0xÂ‰¨î­
ÅlUúðe2Ê©ÅGɪ9tj¯Á^Fc
¨IÄ\´’(Œ2o·ìÿ¬c¬Ä_g(Vš¿Ÿ¡JKÞ ^xzmòñ$…Ÿ–0 èˆht¶áŠËRҌÑ·JÛÞìö:ݽvûbk};YßXšÒ¤—…t&í@e[f6tF¥½Ì2 ºÅ­FžÍ&o—qÖ÷ìj|¦Ë‚ìiï²É0‹^÷
e–h®Wï9³¤ÔR³3*RmjWu
z3=Ÿ®’ª× ÐÂÊáôªÃóu¦8GYä½M^ä=Ñ®ª¹Šæ2 ¦ÎFv™¾égIWmO3ªß4Îì7¢?\ثڔ +o«Hz¬Šú«Þ‚Šn\,  ?A§—<Â.#ƒ>ÀÄñÅ»ÆçÃø*ÅMNr¬Ûço~:>d=m»ÛÝÀš›?·›Íó×/fáD~À²žg£ËIö×$È-‹Ž_=£\ÃylÔ°wmßiþw^BPÙ^óùµêÏ/Z~2TVå£[$°Ï$F.èûÃÁ»ãC™}£XÐbÞÂÕã fÞ¨.oÔÆnBö¯£
¾NQ&]RLñ-!Í)^ó,Wàþ©g†y½IG‰Q¬(ˆ‹Ü‚4ÉÆî&•~ÝÙÝÚä#ÂHæ9„,=EÉà^¸EˆÇSÂáY‰~¨\xÅá©yîa±,nÖ¬nUÀSÛ¢´¾?S‘,®§†ÐŽ„=œ%œ"
|bꤠ¹ˆmꬭšu%ÒÞÝÚê0iã潓šzšvK¿ˆº¿yKúv–væ	’.”®-
—¾‰	$Œ£ÁQÞ¢ßÊ.	s6æÅßÞ$	zw{Kdè;/~ÅrÚ%`öw—•\Ô£.jÑ#‘ý)¼¢×ÒGâym–°õµ?D­ Ad3Œ0‘Ré×Î9hØ2§½ŽÆ™Ñ
ž	QŸ0çßÝÙ]ÿÙÝÙëz;tWÃÀÝÐQÍ3`hdÑ÷ŸŸ~ÿy?zÌ{a–ìñth¦ýèr|cÔÙ}hLæßOñSFݐúEõst¡ˆbz9ó›äi_תB}•î¨"Çڒ/ë·½'K/W~AíR({5j¸Õh½ Õxñ"2š®I±…ëÅkœ»\ªÛ æ>ƒOÀ¹Í£ß›…žÌ’Çѳè1…S=n
	ìQâÍîîúÆH b¥»¢ªQùpV?~õÒíX¹Ax렏úXUB¬\žÒéÏÏ^½ÿôn‹ªü‘6!ùé±øYkÕS-ïm„ê²
$|(
io¯Ó¿Ü[o··.7֓‹íz…´ðzY-4 3á¥^1­Àÿ¹bäHȪµËE§µö3jPzœßæñt:©~(úpõCí“$¥2Æ숄z<Pч«ÃAœçT·q’ú…ñ31vS
íŒfÃsûp’®cÊ®®(
"¢JÁF-Ø2»“>Zá úMiwçt™Ï.èŸKt©Mçvɺ8‹t\wU=Û7è:«ëWƒ¥WOŒ¨êSQŸTK1?Ž
ÀkÔvUò{꾆Æò%þ×¾YNëÒ=´µÉÛ{ЇëGwtÑþ®¬\±ù— îÙÃ

֐œ¹sžsj·]k¯2¿æ‹á'GoþpüîÕ¹ùóàìøý;„ÆR(V©ÅÙûƒÓ3®.Oq–ŠX"ÝÞlv¶î1WŠ¥Š§®d±óŒ’,5þßho!)˜u?¡ÌÆÏfjûAÿ©¦‘6]§$0}kMäbKä Aâ’XGÜ
‘Í‹¹ 죉x“¨N®zz¦‚És§¼`Çpg“S?
Õ¼žNü2b‚
 ‘’4Ž†ÖÀûp]5h	lÎ&Î`fyˆ	ú4ÀH4½QÈÅål‚à6iÊ)áÄèÞ
Šó<@ҌMïØ¥«ç•ÙN
Ðqña|G3ÉìnÜëtÐÆ‡†²
78ˆiÛ½öêò”SmZ«žaÅ{uPñ€+^5×h2aAãOÐ[Œ®ÇÚ;TžÊ%ºÞÛêìu7Úíþz²w±¾¹øÕ÷ëoQmA×(™»ºrz7Úïf£4ŸöÛ×/îsƒšå@8îîW`wc³Iù%šáSa{™Gü«#$úœ±$ycÇïNNÎΏߝ8yøÉSBë°¹=ÑlÄ8øIß½Ìþ
–¦Ü웑<4¤¬b3Ÿ©Ñäe}ÛöÕ§"íBáw
H¿õ‚Ñ+ð'D¶aœÿýý|tðáüóۃÏçǧì£ÔB++_¡»BûYûø™Ì›æH~Æ_Ë][sHý‹œpnÄÇÊ·yUÖ½CfI¡_‰>³ªbõÿ¨ÔJïs™Öè\ÖhUd¸2%џ»\·œˆóœþÛ@ö9ý
Á»ä·ÊIÇçle‰|N"q1o–!Ã.@!Rêq|}›§à½%ŘãS¦! üŒ&`U”¼’õ“FjþѬä(øq÷7ƒ¨ˆ2Óñ´ïãð‚ã!óÏ“d~ø4@d§

§š$­D+xDã_’[d$N%!;±ÑéBH]3JMÝ	]1Úów
ö½§VÂÈ^ôN7ŽMjŸ¬2à扢WzëE§ù
H­Øb¨E/rD³9×¾ô“¼t`>ò2ã1ވ¥š697GVøÃOçg'ÿÁ·ØÿÌaÞzÅ£xpûפ̿K
„…ïmwºqw§ÝÞÞ¾è^lîÍaáå.*¸x¹cãRMŽí
F>Œ§×÷dãsusš£øÅ°¶Úçӌ¥”™o±éfk·ÃǽŸË,@gŽgæ"Å>ý‘Ò“N§CC_â^nþâbÓÌ°’Iv“»Ÿ¾ ÿ1¤Ó[³Õç—Úà¾V]##óÐÆ8«rýÁ®}Ü,>-]µ
Ÿ §ñU YÿQ²®Ør†{2'QO0ƪóÈSP3{=Öiý¶×»ß`ýx
é›á*®¬{§£â–jÑZ-X¬šÕ"î½baž;{GÖ:Öñs>êyN0Uçny²àJæZþbþî.ï	òԁ·Ë¬‘îy#þþ’S…Šñ$'ÅD¥Ø±ìµµ\™‘RÒÜÖ´¸réèð¬–îüR¼@͵YsOãÉim¹5 ê
»ë¾ªwÙñ¾iõE0G…
¦Áÿà5XÌ0źžaÚj8ºLz›’y;Ý͝ÞÓu1‡aºFÝAsç71 Í'	Õñ"cÖ2"ðöz‰´ð²þUp—´=ïY:fZÖ÷ÎJH÷÷$IÛ0ºÝ9eÂz¿‘žË¿’Ðeöû"ãûÒÿx/ߞcDB$¼?~eä÷aóï` üïcæ¾I>÷s$ó:ýød|zc¨—ÍK.$ˆìËB”òø5õøYÁáîûvS_öCÃõ9ýæ­K6«£‰PE¡ÃFP÷PÁÞÏ¥uqµ'ÈøvÝ&ú9§ìÎ9[+œ¹˜~|ejxÌ?ðצ÷«ŒõW¾œ7;n²¹¡à‰Ëi8TQÚß·r³Ðç$œ_ÜòTG”û®6ëãŸø°Çý~@¿Ø؏·ñäö¶fdKª€œë’&žIÌTÑáu૬Œlmí"Út
•#9êô@¾²ñ-ÛVL‹B=7è"Œ
"&¥~’§_6±‘*Åcå)zõ=Kà቎JG¨||‚“ƒW~¨Üfôƒ]~½Ø—jlÿnπ/™·9/HU1¾—l-\H’óNÌ/%83:1\bƒ{Q…ǽòc®R“ÔHÀžŸ“ƒ¾Ì£Àò2cb
·´þ‚—(Y¡¨f5XZŠJ¸ôúW»†¤Öò5°ÇqFäü‘ø—ä)Ì¢QÅnû‰yŽã^²ð“Gÿ›Ù÷o̽9¿GûŠ.	5]öðtÈ|¶#RÄ7XÓ94œÛaÙ0^|f'[dŸöï¯'ÔjL”®ÊD‹&7T3ÑqìYnÄîlÂLšÌáæRWqªÿÏ|‡ÄöÝÎî·Z
>¬Rqž›K±âd72<{*»n½ð|CiÎI­®ÆWôƒ[SÃËÅD˹¶TCóKi™Ìо¡ÐOFDMœ‹
ØUæ¢ðíÒZ
µc̝†D·«Œw͵µÛÝpÁ‡/{}҇7תEuN<Ò'Ü<ŸÏo®ù¥‘Öv6*Q‰·&cȒ‰õ„U¶ËÆъwìô럊àÄûžDïdð}~’P™"ní½"\,\	ù)ýtbmh¼.nµ`ÚÉ.‚Vʒé“r(Mɕ¡wÚ\iÛp륷O8À71ÛÇґg®,-–ÿŸÐ_%=ÀÞ횰VÍöÀ1¤páu 0qòüµ#‹JpŃVNPØYGˆÐ÷¶vš{ÑÚÞö&_ßâþ’ð1ߣåétk펇A[ßmßø§w6îGªÓ—äpg洔
¾Î’˜õ­áž]z6„b¿j*È®,˜sôØ:
â¥ÇG0»P©0-?Ã"1Ãh{1HžWÿú@ßzŠtõ(/:A–u.H¸”t÷ÕºÝYßÝ%e}O|õ$D¢™
ùç$—²µ»Ãd3éŠðÂ"ç¹gŸÖÁ²s¢Rē5
Ž+_ñ$@}›*A¯ÖE²(¥˜ñëß÷Պ¶Õìt̬»ë]ÐbÚ›©@8SÉ;€Ê{¨Ô$ÚKÓhFDb¥mfí3Ÿîü˜ËQÃÊ2ôê§øZàÏÿ\o€NÜ¡»„¾saæÿ>ۜ>9 ÕQêNZgŠ
úõ]ÁZ:§î˜/³Ütéüé¡:+.,¬´%ªÙE„šZÅå–5s@ÄÊê5rO~=¸mñ¢SM÷in)¿»Mj§»ÓÊ8±ãóŸÎ=	ø_‰þݏ…°d¤údÏgþWú¯
ÅéllQ´Agcû[NsÞ³S¼«ÏÀ½Yšî£ ¶yÛníÆîYÉ7U!,)µ5w`¨ÐD¶*nAÓõžÎ›,· G¬ç™ÍÕÌPÃ÷äª{,KÕ°Ea~ï/þ;AÀsŸ.“Œþú0ó,.äŸ6ÿ,lqs}‹—­³sïecTIcþ{Å¥^YñžS̕¼¬÷W­>Rg0p–‚"¥¬-ûbpÐÖæ‘Ý#Í­”|›Ñ_fɌºœ²v¢!êz0šÛ%
¿ÆßbAÿBÿZï%ðÛØӋÝõ¸ӋîÆú —9¾‚ §½¦¿ÈDúT‰ä‚$½	2fØË7ïÿðöý«#f}ÑKéBï_Õª)ež<„>¬ñèI2â¬ÕªÐ>×\DïÇ$¢f£Ñ‡ ï7†Œþaþõ¡dé_¼VrøÐaŸøñ[)QvIÖ¤Ö$¤6?fƒ
aº_€sê°i r–„y³ZãIúŘ«„=ö%c7`1ͪNí™}cû
=»Î<]ìÕÚ·l¡ü“½Ÿp}®:3ô¤wŽ"7¦éÈqü$Cå'z†Ë†çžÎØVè¡-…æ÷ØO.Ý4(h6Ãi7/Í…HŠ-¬Tgî[äÆp
“Ù%ÖÝݹÃÄIÅðIÕ,®ҖãIB¿êÇüF~‘‘Y'ú”¿+a†­ÓÜuøC°Âòo·´ÖŒúC°¤Ò.X‹OTÙÔV«­zÑ\O‰”ÿE¤"œ¼?ñR{ˆÞ1?š³{þÑ“¯ß½:upvðòàôh•
€›¬Xlî­ßa+8ŠùB6äØn²ùVl 5ÿL‰Ó®og’$-èÍ-ºvÇ·¦1îÍ2.Þì]Pú-„w×÷êGv/èÓQDí”Π»ÿSÎÛΖ0ÔÁ²[ÌL¯Áܞ8Ý0͑Syžý‚Ý_õ/ «?'‡Ðy6NFˆ>§ñ¹{¿d7G_á±J¿$”ºòÜò§ÈW¼b¨›¤"é¿ö¨á‘wD½&5ÿµ¶‚{¼k{P¼HL#\	Þë†ØžÚÐO/ZW(XålÐç¹×lrÃ5»¢•o¹Ìö[w]ç;¬ÍÚÝÞðÖô
l‹…öº"f^‡ÐA‚gpsZÞU{법ßü)Á9¸ªkŽƒÿÛôb{ºUÿ,§¢n¥éšà!gá«ËîÛÜþž;ÈKã6pk‹2\;[ÊÏþ%ÀV°¬d²Äh4LÓL6ë.!—1ÑAÎðÞ½WÚ=ß÷(‹-ƯãW¹„õ2ïô竦Ö`ÌÐú°1µ^ø´h…Ÿ°ù1R%Ø~È®œº¿šág<y—?bnÑëä]º¶Š«%Ôp^nK¼y¹ÃúbòbµÒ%ŽÔ©y®…¨”›;›—ÛíöåúÅæ^¼L°®×Ç…ÒkÅf¢œÍß$úl~†¢QÜgFýȏ5;¤Ÿ )ÚõÖ¦`È錝w’äÉôT&Dz™™Ý9‡¯zf–~%IU°ÀLb£ïí¢¬hý´iÆå€ÕNh“óBÎÛ4ZWs(¥4Á'*à½
h
Xp–c›Bq)ęaµ“Ø~Š½²#Ôø±=ÚÏšv}Ô¿,ǜ”{¾ë'î/<æ|SNŠ3|ø2E2EŠ
IþÎHaÃõ½]À]ïh^FÜg¶f¶gd°i
Xø%¡XDO.f—‚+†2jl˜nFiÒH݋L݁ŸÞ´àé‚‘·A÷{fäfÝáÈɸ+.|u…ÍàºÉÒ1•x7,….|œóyî0
{…àr‹Ì2‡>½ö\zk5ß?‰oî2‘œýœVÌ£–ÎÌëõ£ý7þÃ÷oߟ½Z†¯î
çYë¼&Š„·¾³µ‘l´Û½þæzÿb	Îêw2‡µúÍæ§B(¼‚ŽQÍ!Žò³ûý²ûºÈZï˜ÇÞ»
ŽOî(¾ÑƒïY(gýKh[Ä+¶>‰{ 74ÿʦaù¹ 9­€)ºèJë ×ú‰9à„9@Vøs9sÂý4YXƔPDj™Õ&ïMgs—˒³ÒœÏÂ"ô:3gaBÁ„.©™ÃH²aRç3'yu­0Ñw‰ ÷ÂOïmQI‡ñ,¿žó¶4—ymIÆÂÖΝvKê6p쇽8œ¥M@÷¨ðܝ("Ó»Nú3”ð1©vcSã©8eÛvå ìÔß8Ä»]¢µx–nߌt‘Å9'¾Ù ÔgœLrX¨L$yi?œŸž½;„šóæýO?½	è–MiçÈî>7ÓüÅn+/øö6/øÎúݼì	aÌEVN­w‡T¯q¥¦©¹šw]ê¬õÃ{þj»憕á¼Ëd²”9¸Ånȍ­=Áb98“ˆBâÿä†|EZ=Z°
Œd ù‰
ޙPÖÊ4†.¨¼°‡ª¸^÷#{ ˜àò€›©Ú Å-=ÉE:Þ)Œò—æd³i–É69­6kö2Žw.×{íöz²‘Ä—K]³¶‹y—¬mD*Áöz‡|ü§ùi0ãÉ/ÏXèàrC´
ØfIUÐӄòD”«ýÀÀg>
YôËuç†ç°/ÿúj„ž Y’sé„$?ÏfÓñlzÞsŽj
*%ÉÉR—ù¹VÑ죪þFó¶åFgè]G
ÌË»e
æÒªOͱå.úϖØYŽj­ßX}®âSg½×/Û퍭­~§›,±¯¶‡9ÛjÛЮ’a¨»%‚SIFé!»½Rzùmª¥v*TX˜[ÈH`3¨©e{#pÞ²¶Âl¨ªÓäŠ
â
‰šþ±Ï¥.P+³•|…±ÎEÛ4ƒ•ˆÍ4¥l Ddi?÷Ó¦Ù"t®’?Â*d¾Å\Ö¯äJ#Ð2àºWÊ‰cTà\»×‹ÍÚ°Š‚ËV¯‘ZêM£*©”Û÷3Ž;`‰Ï7·ÉùÍÄÐÀEºì
¾±Ã	ç;{|kTyWd¨[O"S(ˆûÄËù,Z
3ÍZׄ¿À‘¬j®nCW‡tÛº)V–Ú‰žK1ⶬî1ê¤2¸ÀÑÉä}ÜFðÚæöf³Û½ã"b-Jc5<{ i
¿>jýJB4$ŒÒh¡¶’-û‘É”ˆ¯B½`öä(GCÁlΜ’öyhæ®FÁÁˆTŽÆ™‘ëo˜,ÝÀxôÙ-´F>X+äG­È[Q)ü®/ý®Í{ë:­€‹F‹òš¶nî(ªÕr"ªK×;7K‡8ŸŒ ñÈ®éïÖ(Á†žµí+œ®¶³Á©ôz~(”ߐÚ&B
]֚½~å¼ÄÕüŽ«’ãÔPFÍöüÂß«ko¿ó/\qXޕÃ#ñ’f_ãõՆ€-Ùº*PÖÊÂFê-q©èy!z؈ú:ýÕ ÂbÒ@áMÒ··
qµ)giɥ짓é-WWÔbôš¥`c=	}—MŠWáàßÄ›’)¬ª”¢ª(v–ˆOšÍË_õØFîÛ5í‹öV4ÉZ­8®iË©
—0«rE¦Þ5.1T&åt®øÎÆŶÐ¥¾H^"I0æR–Um`ú=óŠ":o’׶Q¡eã.=YñšúÎ>[b&ôÂÚAù_½¤òóèoåcéɁáÞ¢Bwö]ëۘf0xÀzÝB?^µ[?Bº˜²¥Òm¤Ue
Ìe๩Á[;ƒ&—5˜r½S["Œ>8¢µ»ŽD¯¬x0k²Œ2[~‡M+vÎQøî¢ü%~«ô­Òìµø°oþüv0qî¤8{2C™¿;IÓmò'ÓMŠX¬ ¢E”'F4¦ˆk*?zqeæ؂Ò(Û«„L¹ÒÙÞÙÒnëîZ¦Þ^ÑJŸFåγêùò
Ø¡®µõfw½p²¶ðæ·9•E67,‹`>VYé	ÌdY„0c±ŽÃbŠ }f£ÒÙ
ª|AüŸ¡Ÿ!Hbzl¨à1ò°z39¬´öff;†+ üHR{e1Ôç˜d_qJŽOZ
½âø²ië6™r¥±|!Þf#(Ð95ÖìœQ‰ªPéVÛZ'Pœp¦›õgä%º™dÀà“áê°ÅZe¯SëmÊî߁Æû[å‹7XÄÛ ð_±w6ýúøóÛ#®ÿ•_àMB$¢Zfö{¾rÂݦ[³Âv±/wÀ£K^Ò¶ÜB#è7åü;=Š7ÖÊÐ\W:ExwŪ-¥5¢§ëd06B ;öDí¬ï!ékgs£|)T	£”gæðŽfB£ó3?hܯõFô²$x„ïi0šBvÕ§OÖ|¯œH±Cv¾æUEëª0WÔûÜ[+¬”i¡òå OÅ+8I´kIArv:{\ŽH¬â‹v/´4Š­H4t
Q•Už»¯árî;o^Å^×Âf\¼Ën¢Ëv¹0‹¬Ý•«”„'>²:òûÄ6Ñ¢mì)lð’4_+€ö
+\P§»ÍQI$>–ÛRèð¨•!—ížÓ
[[ÁBXÛÙ[’Œ¬·¸'×Ï` âW„Ê2Çaí°¢¿ý-2ÔÞKÊÐü,6¸V^Ùΐ­Àü6¥pvv֛Ê£ßnvö–˜/DÂýN©²9á\øV)R
[Ëە­}S«d…r·(@·XeºiA3³éŒ,ÕÌuˆ\à|aM>X«ŒÿgFªŸŒhŸ©àÓ: âöӄÒd|9ˆ’qÁFÁg)wùvÔcÆ8¼ukƹ°ñóèí­²†©
;¸]^Ó«æ¿ÓI/N³¢óò|Kð¹æ}-Ç/u¯—½OœN°N÷öÚ®9ÀN¤]’

 È#ÿÃ́Po«øh5úéèìôìäãáYÃqE@UÈÜÂÛ¿Ì—¸ú‰ö›•1zráך2uWɲúU=7½õôüŽë‚[ÅSäãÇBÕpq¥TÐܜæ¿ÎZª®¤Ë¢¸B’Ÿ2Z™¸Vy¼çŒ¯F¸»Ña|Ým©Û|7f¤Šæ]]ÓÑ!J•‰~#ç¼ú¶†:ûVµnï=9ŽŠ˜A7›¾‰nTX}d—?ÈY¶§Ÿô zs‘ÇP¥’B›ª(/َ"iQÝ%ÜÝä±çéÕ(°\•™!P)ÊÓ à°Õ(žM3³ÔQï¶7 º‡°•ôE·ºÓ hÕÈÃMx‘èꆻñÈ/÷†žä‰{¾Ì¸¹·Åƒ"BjwšYL®EŸçnø+²6ܤ½ä÷6®­ºnwgV‹‰-óŠ;º«E ¬&ä'ŽFåSåä˜eݟƒø¯·‹\ ÜFÜ [ÉÞz·Ûi·w“˝õ­eR>ƒ^ºB¥¹¨HßØû{ǑÍu{·5þO‰²±dë{tµø?áib¼TÃ
[:ôòhÔTe‹×΁朒¾dX
¯sG,öqæ¶è
Ø«sÏIi­ÃðoÙÃá*
°›<:pqÈSsÅËQiI“·órJ(õ›Qgú0‰	,ÛvœCDQœa€6»x…ó?Iø–ª6Xmå8?0-ynŸ²É/ÉäÃ$Ãâ5à"ˆÞdWç®+@&pB/ž£ä	­å.ùÄ;»Ræìžkù¨žKš´^qºŠª»ø›÷Áë8¢JîÚð]uï5½×*a½V €FŠùŠ*ÎØÁ“ò¼[ï¡FåÑG¡±.µÑ7¡#>à€8<+­˜Ç(é³'/ú]<Ä9 $ӄT?§ŒíZxªq¶Öî?©æá ª|ÇSiɛ$K¤k¯^|™…_C_èJ™;ØGÁhKhãáâ9ºoú?Ûù9ã'Eœ–”«0ÈØ/ÈuNzæhÂÒ!õo¯ðìœ_z±´b]¤+áü(íu·»éq¢vœ,ڛ?šŸN}Æ[ÍW{Žk
¦¡ô~vò%ÌÉR.“-j0ÎàIN¹íC£DX#Š5&ˆ5¨IIMŠ2,ÂuÞÈþ¤,ˆìþaD½Ç4ãùÐ6Q™ð-boúŸ$]em
)ÊÙååh6ô°n~å~€
eåÔ¯¸Ê±˜Zw7|QÑ{¶[®Ô¥Q`zãéDãÁåŸ1׌·z˜¸êÞërDr6L²Él}äøj`¹ò4T	4¢í›Ów1]+<®Âã³7Çò8¬>hQ„$x{c‰·×=JgD¢>¢ä·pzË#M®2ÓÏK)«†Ód(ãHÍ_YPƲXŠ¢ŽÂy}‡ëIß_Uúί{^±ÜÜw´¢Š«³)¯Ì£@‘Ϻ]‚¨í (³·’€.š¥¨‹¥DóOŸû®ÃDd	—)p\¿,A¡*ÁoSÀA3tý¢^•j¨#’s;Ên4S,¾o¯_R/Æ™ŽP‹“®•ÇÍzÝ(¡ölBykú*iF-D/ÚÜ\ßÜؽh·×÷v“í‹9zQUe­¨ª‹àdŠÇŠF?êÇF¤9’¨wãßgÉ䖌µOþ¢•

Z8FÂgß¾:?=zstxöÌ¥œ´˜ÙóïÑë÷'ÑǯΎžžþ|prÄ©%Èh»…Œ|xv”[O̐ÀÀ9Lj­Ô˟þpô¾S_ډtéǚãôÙɵ^Œ$³°lk¶°ä9…É¿‘j{++u퍔ðVaÆ°*ŽBFØÙ±…¯ÒéóÖR«ûk`Ãñâ8n¾)Íq7ÚHšÜ¡©zŽ¿ÒB‰KûÎý”—œmÊÀ³OJÎé$ºÏÑ0K²xÞ$?r=»4ÿ[D›¯&†µ‰£<úÄŝ%zd1'S¤pæ	oH„øCõýÐSᵝ½
Ém½Ë"û¡á³¥ ˜3ÎW%ÑøÉûOçoNþpnւW♋·>¾ùxzüÇʇ´rϪ»”gš¶BùU2pԛ×æš	B¶H¥ÐK²ÒQ)A¾f½+ÚKÁJŸÛ Ú4z	OG£>-þÃpÒO°›¨ßŒŽä'Ü/Ó(ù})uwI’lJ:(†•2r¦Ó…}•É²º7oˆÕˆ¯
#àx‰zÌ]¥Ì"°0;A"<2·äߍØ×À¬É‡×_Æáß<¿ËO‰O$ï2^ûz³h0—Æ>¤e`r6ѹ.#h¹\%ây0¢×pp7t8Î
[‘;aVöÞ½Hj…Ór£ˆ²;Ɠ4› ŸÕÃõð>¢1Æl°Øâ¤äÝíNyeyÅå-‡Ò
ñ²l¶Êé*hb‡UÊR©xä§pÕ;C˜'ßdѲHÆ)™2ppÃGû ÄlÈEfV)1<…¥Û·u™v{›,Óím­Ëe7#j¦rWƒ,ûœÛ§rÈP<Dձ̾„K¬ÓŒµß;¥—ÅÌNKòuˆ,þØצ•a“D'´tX_`1ÈÚ¦­™ÿR
)¹í×U¬[qêȲ1ES@  ,9¤ÈÞ58­ÉœRÝVvC!Ž aæåTíšV"Oö»ñÆFÏȓ»—Ý‹N§³„<YègŽLYhÉJX¥…×ðç]ÄLúYÅî?i4 P}È(_p5"/³àòC£O¥½ú‰Ù/ñmSÃc-/eÓo?ØNÏ¡Þà”6Yº˜)ücEÉØ¥Ì%ÉuJ	~uMéZeǤÊÁ§=ïf­ð@|¡ªó?$·LwÂ;äÊ.wæ	µ-ד'™ÔÏwQ'NŠ™7µš®tFÞ%rUŠÏFùl%Ž9kf‘+s3oa‘À·š¢¨À_fi2µh9nRz´æ"I$€îï™úè.úú(ûû6ðÚ&.št“ªH‡¬eF8ëùSÜép¨–ÙPé¹0 ÎÎæÆÅ.ò/;[›;s€xÊ=”YO¹
YÓ×»œÅÊšŸÎÑDt…Ã
‚VÇ)ø
I^Ù3/ü,:&&çy‡0¥Ã÷þãüôðàÍÁÉùëã£7¯²í¶*žÁ“é‘v¯ü<7rþèjzM;S~lw¾ê! ’þ«ìfäì’?uIp6 šúKü斤ðsŒ-ü%yÈ3¨“òúòßz](b“$fê&£þœyÔì7дìÎ^ÜßÙi·;[½ØÐõ"rº¨£ç ÑÿÇŲ	AþŠEçôÂ{k²já÷	ë;|ÿöƒáÖs7Œ[ÌݳŠ&…m«hQµsl¤dú]ßeú]/C5ë
,qÀí
~/®@Í)þí'_ý¼p¢²¹<摱{¬Bávÿòr¯ßn÷:;—[›sŒŒ¥êHØk™Ñ$äO°Ó"¤ØÓéÄüã
¯fÁj(u$ÀŸNŽÏ„NÏþãÃQã1à'ŽßýtøæàãéÑc!#¯U%5óó—ïß¿©ÜL~|ôîãÛÂF²Ìc:õ7·Ô¡ÛX
<ëv·¹8zWð!éV/EñRª[
#}AøªZŠÇïÎ
Dý÷\ƒò³°ç(?LVðÎ#mï¹Ðöî^¿¹Ým·w⸷·>7£ÜCqûm( ˆA363ã
ÂÕö“£ƒWç†VޜVŠô¼b—è÷ÚM¢§wÙ£bwÞ-Ëz‘5LÿšLžÂ6øÖß+íT}CÅjìí\ÆÛív·×½ÜÙìÖoٜ®Ê{7§1%^#C¸ƒ:¡ôçÿ'…ÍÙL&ÿmTPBÉû@Æý	Ì'“,£‰(F#è ð
üÿÞ¿;?9þéç³BÐå‡I’s!#說9k2™(5eÏØ7²KØ^ĺ|_þ‘b\h<Nâ	ý̦Ñl0 ‡~Žz_R…#Z‘³mGFcÿ1òl˜Pfš9F·˜pgôåeܐ¹f˜Ä#À‡ÝÞķϊ™l¤ÁQµîX‚ÈғÊÀ®’*§%…;ŒF*‚Q}JL¥v ªý~5ŠN³&)yä€ñØoìŠâz·5iy9Ù Ëcýl
Qžލ›Ì4­èÍõ­$éRÀÄalVõ2žD³1Žl<¬5îhOaµWh½\;y€Üz.8’Q6»B=sC—8&¸0̎M˜²w·R@—¤ë•GÓυ¦_|óÁhÃõs¸„žsF’KÂHɵpXrùõÑÁÙG’;ÏÎO?~øðþäìè•-™b!‘ëü†Bñ”b:HÙË·˜|¯®ZÕyÑ7žš-×ð×oðaõ“äÿ-h½ÈoGçX¿k¸ž»¥œ£·X»Ë RuÍTü»ÜÙÞØì´Û›{{;Kó[×ÑBnëšE’wimKLùì‚|qçÒLéñ§Av¢'WæÏfDž»è	QS]]ÐÌñBO‘Sv¿äo>¾”՛ÅnÊôC$$ŽÔ~‘v‹quWôRÁWô%hdºî'±as”ñCæ`p	„Q±J,‘Í[¹u™’[;1´Fý°‡™Ñ[û±\‡žÆPüëÅ/–þtdæ‘N^\qÇ
xßüiø.	GÅM&12s}±?„WÜÃV›¦Äì÷[,8w1âý–[י{©YlW’°Û¡Ô(ýÐÃ'Ù®Çúµ¶à,ðs9áh$£ÿMáâvÖoÐ6°˜c\
`æíÒRÓê5äºð½&‘'È;¥N*–yaWƒ^rÐÜôS€ý™›×M„ÈèÕ67"×Lóԛªø;Þ)CéS%›¤ÏDññÝñûwOè}trj^zzôùðèÃÙÃ/‰»~K78’½a¼ÜúÓë_’Ûœe*³J,þ©¸D¥æ½ØrHG¹ø®wT“ÿ|(EþZ}ÚÓ¹‡=î÷Ë'Ôȏœ™sS<ñé~a—‘‚OŽ0t³þ·,{Ȏv‡9ý‰
ìpD86ãʀ\­Lƒ›\ÍþVÆE"§©+Ðù¼ƒ8TjÔzs\Úâ	ß[—ìºÜ‹cì2¥œë‡ªuÍiúŸ€W|J~4çâât›k^+a‘€à6’]”TšÂ+j;©ŠÁªë*Ü0€À识n!*ç¤\šUÇCÃzŒ’~Iû3äg‘kïðìøU.]¤ã׎"_¡|.
8Že³)ƒyϏîõ|vy™öRœ#•°¡Í ºÍ.òi:±{‡ä“hläºÙØÜӞ@ªs}›µŽ­s³ôž	\hq„ÆçÙbˆ^ÙfôÊðüi~ªR[îÕIµBSÁª%©êLÔ\ùñ[À°«®oǟTJ—€Rþó.«æ¡•ø—s8M¤mP^±‹J¾ö’±ÀYQù϶邻¢*¦ý™;¤Sú=ä®:.°£^ñ›CF ì{f†4¢lÂ#ªTâi|¢^–ZרéòŽ†,ш(ì\ëÇq`m’7pÄDOV•Ç‘þ6IØóç3	º34žC7e“c¿øÏ»lÊ
~ÕP<¸†&½’ ÂÀˆ0L§„hp;šâRéc6"&çJ&vGÝú©˜ò€."„\
THqÊÕ^…í©”±fâÀ¶·WˆÿBðn†=dÃD9‡~Šâ%…ë£~˜G`lªÀ¿ýÕÑ@E'1¢òygë¼Ç»-<­µï„ó¾ÅN]jAê9ƒzàcþ—ü4ãÏC][kðµõ«õ¥ä¤g
¥–ø
¼å¬‘$€I_.è¢">!¨˜óƒ ¬-­K¥UñæðôÜìzP±Üp*¤;?†a©¡ÖöTˆ˜Ó™¶\Øß²sµM¿I¤Eô}ÿq3
¶Bc&ì(ت,„Æÿði-Í?ÄTAÞCݨ5u°æñ46rÜí_˕ŠÅ´qqÙ߈/öÚí͸·ÕÙX¯7m”:(›4JMĝ³%î	ç¦4_p÷r$ê5>  • ºR+‹j/£-°>4tµ]šÖ3dŽg‚Lê{‰§ÖT=Ò3*$„öV)*0ò^Ä`ʨUžE¢YpÑú‡áƗ°‚MÁÝ«¬ä†×vg«¹±…Å忘iì§ò+®Á†Ø…þ2¹UQØüÕÐe2}?N8A6_¾4Û\Íò·Q,ê•øÁÓ-õŸ÷Ô/Ýõ	ß°7—"'5ü#—êÕñéÙñ;Ӛ•¼ßt*¿å-)&ÿ4+óÓÉû¢—ÿñ÷X™Êoy+cd+sî'ìࢿÁÊÜgY~>øãñ»ŸŠ‹òÍW¤â3ÁzäWWÿP_]M’+\,ßä7%‘Úï…ËòÉ\ÃÙÍkøÊÿ‘«sCÃø;-MõÇx]Ì
in[äxœ³ë"¾‚SÛhÝX}€GãE¿ý¢™µ¬Ńͱå HɁ>ó›.ç]‡ýêÉMg*‹ÕÛ&I"*¶«5;ZY‡ìMFÿVåsô%|IþèÃÿ{ïޞƑ,ÿ?E¯öbd
f†‹ÀŽ7–°­7²¤•pœü²yx¤Y#†e@²6Çßý­K÷Lϕ
IŽœÈçl$AwuwuuuUu]èm
«U ýMç$ôLœ‘Çâû´™,:Ǫ̈èöŒJ¡§õ‘š9ØH6xæªßóxR^ùð†it)8Å*.ü…F27À_Òâî詁’è;XÉÇ8Nx7r0+•]zùú#¾{êú$R•ßJ)²‘ú34¾¯rLt•Cž>}ròBç}¨×)HAýrÇ;ÿHS^åeò	“érý¦ŽöQë¼=ê÷:¯»þ›TÏø/´XDœui<GÂGçoy%
	%òãىv
<†RûðLä"è‰atbÃaÿ÷Jtöe´/®¦¯ôL[	‡ôºÀ£^ÿëC÷ôçi…r.òå˜=1®áŽýçjäW³¹;³Î­…4'
}»cõ\ô,—ä!Ւ+¥z”ü£"Ð:d³“Ë~%øH4E´	Ž„;
P*ÇÀ݇Š¨Ña+¶É.ε¡;½²§h׺Kcœø>MÝë‰=:Çǁ¡“Rã„SÖkPpy´v¥ÛînëîY+\<%ޑi²ïbÎWÿs,«wi©
兔'Æø•zöóQ¯óSŸZmù‰VÝ¥œD{f1V«EÇd®ÑêÇåÒÍ°µä Úè]qqT&¶`ôa¸™ë9ئ¨íc·™ŒÂþ[d
m…Uå‡ÝnP[õË=ðÊM¸eÚ¦âª×|<fž‘ßçhé)Qƒ‰ó)g¢—9$¶Âébnéf´r¬Pº)B!àe\þ'ІåÑ¡fŠ]sñë[Ï“ɦÃËI÷ÒF7Sä–M¿âz1c‹mSe4¢ë½
j°°dFâ±TÛKèR÷g†2ëF½d¢ $¹Ãíãý	ü¦ßMNïFƒ–ôÍØ»sÀû¾ª}óáh¯wpüÀ°ªT¶{Ĭ>Ľa÷ÇÎá‡îÙCÂ-ÏèÞð€¿7œî©”)¡–øxÐ{Çí=’kx»F®ÿ˜Ç,½Î‘ƒüó^ðù"È豎|ýáh¿ûæ਻/e¹¸ˆíK²2¨)V²±%5:=~¯Œµq);Ԕí\9”O³þ†ÁÂb×FÛüEn&§J‘?ïv3Itàjƒ	²ŽÞû€žV±´QÿR«
ªú[éÙô‡&ÆHk¡HPH”
‚6#AqìxÂÈÂzUÄÿ®·06É¿½mhã”CK²íö¶þöè:µ/M‘ß
)mÈn葖´<H²pðE\T©Q<õ‹k•¤7ݍ»D®ót
ŠÁ'›á[²šª„cé4)o†LÐBsDW¹—0ÚÓÉDØÐt9þ…¦¿#y*ÛÒ;'søÖ|‰yÁ0ºrÔ(J³%Z29òy2õ)–Õ²½Å땠x՛®W	zúë%çéôі‡2à†ҏŽ?vzøàq¶Ó§±MP^…¬ÈÊÑc4ÆÓÈX¬Ú¡qfn9"plp9rmŠý
à’Êk—“Š${è_Wþë}°¸Î”R

Ý%úPGOùB±Û®#¥$wtÐ×.»¡ø9
Á„Ü„P1Ùxº#	¦¶>‡Ü|J"C]мK”æZBÞMÁDÿñJ›67uWmÎÁ?7Àè`ïÙȎè"¼ˆœõ†™I#
k–„Š~Qa\EPÁ”nùÜH‰à$Šzsò=Ÿ_‰	ºíNGÅÐçè곝‰$}cÎçÖeå&Ùo†¿SeÏíæжG•Jk׶Yi@½S½rä÷îR78Þ¥.·kUK†ÓG¿M)sþ&ïähŒyö[þ›F^:þV{)…—ixëz§”¿~¥m\ÈSMƒëoàßêêÓ¿ý
³Ðª7©üø‹Zl›®9úÅlþ¾Ë}Ó9<Ë^¯ôiÛd¹õÿDøŐ§Eqr}|îlџº×“gñ›œÌ:‹ÞI^t=sa½ðÚêÓØÚv’Ö&¥µ¸ïàš«ƒ
$[rtA/2Š_‡åyPô îö—ÜJ厭aÛ®TFfÓ4²˜L
œv“Ò’*½¶¨ÔtKñx|·œÂbG•‹&V¹EIÀ$Z‚ð±AÉV&þÄ|©F­^jkÙU®°Œ®Cq¬ç}ká^:Ã>E÷ÏÞ¾ûp¢¹næéñáìÔ\³K¯{ú>T–
®Ü=÷¸¾¢ ˜¡ƒ;‰—#ö+–Q¬5{-ªÖg,DÁ¢É*öP¶¯Pކ°’ë§`©ˆé‚«ñ&TOá¯ßûUD`>û¬¼ËÑÕIÀB”×J‰¯,z·Üøu‹·õ™`i
è‡kuÈT¯
*Œn4dBtê…ö(P,Ñ	àêº?B OT
vkt©9%ãdkTߞ᧨àÆk¨à7z=ÓP	•àKUD¥prŽkÿ³ÿºKe¸	:UäF¿Ž`N~Ëê.eLJŸM¦Û‘Û§²»ýk* âçÝ@ošïh€Œç¥ühÏ©>ÂÏø
`ÞT8Ò/h*R¿ë_û…áöł)X¿
;ŸrM%þ\üÕ ¯F”˜ÿå¬÷?1äp‡>)(>tï“3s4—i™d±MåCì˂|iˆ@•6´.ñxã̽WΧZGÆn\~•Úú¥ªNÚA…H![¯f¦½–ñ¹Jqªpþ=íHdT-.Dâ³Ö±¬“~øܪ²$Q	z²x¼¼¢ÍÔòceHTXÒޅKŠC•ãaSt¬YÈwû™#sU(M¨¼˜šoñDVÎrv\L™WƒYU±4ýTv¡Ò‚¿£ü§.Ǝ\á{ÐOX”òp½Ys´W•ÉòDžËؓÅéQ{
P+Ædܨò}0ÇΦ`°Äq­ŒŒg9ãcÂ/5PŠVí¯sÔI®Êä0C<#ª<wôã—p¯ÈìæÉC&(Òª­CîfúéV¥*–pÚÜ}h^9a¦î9yٟ;°G¬éS¶Ygqæ׽ѐǽõD#Á°¹ÑŠ¦®,C¼S¹Õ©£†D$Ãá°ÄÁŠìÔl‰ÆIÛ£ÀJ:Â.áá°îKø»’Åè(ɆêU.H֐ÅJҘô,¦'Øl†üMç›
ۉpNM(è2\~V±Q.=«’|#—ÇRIÿÄOíuB(dßhªWÏ´‰g]\ÎÊÿÝy¥ð¢WêD0¼|^? dɵ¦cÿȇª¢Mn !߄d€¤|É­¬EöʯeªWi—‚¿_ÞTï)é^ ×lç|êrJÙZ”‰‡ì¿–Åo0I•E#+»äB†æ­×MÂ?¡"7t
sQ¼]jÅ×C˜Û)D存¶Ž»©†pôÚ7_…=•/ù
zÒpÁ(Ř½ÉdÜj™üÝ+Ù´OÉ2úôëh@ß!yp[J!ͺÉeü¤$d9;®e‡ÅFŠ(¬[óóa	S^ÏA_ýòë¶?E´8Ž(*Ӛ¡WÜÜA»‚u	L‰Ârñ8Êéú²µ/'„‹ƒ² O pp⃋£è§ç‘êYTnµd`,¾(ŽKŠlÀ b Ü$¤å!ƒ¦ä²Ù{´œàϳż8;WƒPí[zGŠv
Ëↅڇ„ïd*wòìò†g!,Ë,,ØÅð…Ü€ "ÉÉÙ¶Ú4if³.›Õ³›¬g˜–‘tEÀ
;GK“ªT~à2‚/0'×HËj…å¹u„ö¨<Çnœ¿­3?/'–çajÿ9çeè{˜¨*Móݖ¤o6r±XM¸¾ÆjÇ8Y·
m'Éå¬ýy…«n«¨û4ŽŸÒ/ä_$¢·”‘ÿ¢Ï
YÎoIñZ’÷:¢wNÙ»EaãAŸÖݱ@	Œ^o°gš\D¶x4•÷H|À¤8#ÇÛ¹ÒR]u¶Øh¾¢ø}m™U#÷eY™÷TSKÚêç;Ê,Ïò•ÖL%Âï6ÚõV¥2nÖMÓJ7†¥Š[ÃR›R–/Šnh4Bùz©.²lþ#U·?íu‹§TÄf0‘jÿ<Tm‚C<ú~ªõ'I°z~Ð̇ý¢ž)ŒKEP ƒÚ%i£m¿‡o¿(%€ZlüüÏbJ1ØH¾Ö˸²¥nþ0ÌÑ!žQuç÷.9'©ˆ€•å„
6Æá7ªŒÃ/€‚
{\Yó©λ¦’IÈ
äWcgnŸœ"/
ù<
äNWØÌ+)ké®o-½-@!žHWñø‰WV÷¶§T’WêfA>Á>á'ï@aÈC,1
XzÚµ^}ʏX¦÷dŠnæ‚#6{òpXO™´[¹Ñ'Á›[
#õ5Þ®2Åá$¥à™8XèlShɹx¦`~œ·TŸü`€’LE‹T:Ðvê1hßÊóX/!U	b¡dk‚/Û؇‡ÕS;jS~]#†Æ ¸ ʨq­ÆšLQ×’ï)n&Þ8„։îBLý™ú©¼üýw¼`ë(°‚SŽúÕ(Ûåâþ”«Vî¡ÕqŒ¶ákóQq”{PãÓ>•ew}\¶¾‡k_É°9Šï2¶¤—LFÿ¤à’µˆÿ`ÄÀùÜY”[m£ž]tÎ&K¹[}°­À?¥¥Ik£öxæ0ý§5Rf(™ Åï:‚ïèdÊÄI5¾äOÜr|{?…u€;!gŠoø“„ìcI
:WŽ}]ÂÉÒé‡Ì’0'«¬JÇ~ œåÖÏ=–­³&@¡ïùöSZyZ"ŸdÇ"¾çÎì£4¬z•_iøgnœ‘«7Ctìў˱yRVωKÊûL—ÄDwF”xÈWsD¢ÏÊ*þ6Ò¯Gf¼	ŽÐ Äç†}êåޘü³ÛIÊÚpŽBÑ‚V˜ý
yð­…MY_}˜ÉMÔ|÷ÂO x%q|ÌB÷F^ȌPt»
lI†É,ùKnÂjÏ-ê¡üIR^Æ}V1JÁ#¯öin*ðĝ‡ƒ!æÃXEš­e à$4ÔêBø‹ˆ„ûžòÅreOnšÎ!EÏnàÂĽ»ÓéùQ6“•….ÈKëÆÏc™»NÈ»×>GÂÂTÚHMe&'
³?äžY;ðÚ+ÌB¦ns•peÁo/ÅÌMÊ"¯×º¿æ¡ý9‘=Cï]ú½µðË^¡HÒ<‹k²îüeÔ1ØÍ:òʌ½ÎòDÈð
Èòôb²¡H¶¿dF²ýÆ8K6¢Û*Ó#_3!¨Lô];šêKÜâË0¶§EVIcxù¶«-ó&¬¦	©U¥¿nƒ´`ëü&̚ȃCA[Ö?OâÅ<Fp!¾Â hØitÉý{Ñ_À#Õh9µÆc.Á
\Qóf–
ù´5khÛQ¿lrÚôû‰NÕ
¸Žáª™»—üºSNÁ AžŒÑTœlç;Myà¬<SˆAÿdxɟJâÿƒÍê~žÍ·}ßqõ	®ó?hô?€­æn/¹Ð|êÌþƒùúæç¹ÎOy. ;yf²ú­žHn,3
å±­Ó=Ÿ:ÿ2¥‹
	ø¥±K7½y YçöóÉåùü9Jø1«[Bipk·Æê٨Tê­fc0¥ܒ`ÄmmI­8™>¹áƒ|`NæîÑ÷Îò.öА˝œïa•¤^ç-\óÐa,,Àê¸EÍÄÇ܋¡,*$-l‚K9kä,ÞÒó5V£%­Ë
z~bå0E	‘Yv†	ŒA^x¼–Švíì»8Ë÷ØyO6(âßïw	¦Q¡¿MÐMÝ`wDuùWN«Ìåùï—ýî›Î‡Ã^Ÿ t{ïŽ÷Ew?ˆÖ“Öò$àÏ_hø_Å?h¯zýã£"Oa›_•´úd;ä·B¨Gk%”¢Ü†’æ 1-ùáN
øó&X•ÒûŸIG‰œä9ƒ‹šÌBÙ4ª5“„Zbŝj¥bÙM«UË°§ZA­zS*˜ÔjslŽúE%öƒƒfÏ©j<î‰"‹ãå¢H‚Þ•#³®ÆK㉧¸ÂwÝÎIïÃÉa·ÚÝëõîïw;û/|yì/Š´)¡oŒÏỄJÁX—8(œÚ!R%Xë…c
{‘s’äþÁQNëÛÓîÙً1¯ƒ£³îi/</‘9/g!•ŒCwö|¹p&Îâ&F¼á/ÕcÆ`·Öj´*Ãj¶G̼ž‘îqB4 aÅäZï¦tÜãlÖ>O'7Rî
,âg!ó]³˜,]ï‘ì0«§h¡R
²„â$i¥®ª2µÙ]dP•ÀBxBÀÞ9/=
½=?£F:Uå¾TMÅ^/’Bê.Ýá/&‰yœàTâ°g'"/ab1LÉf*Œ&…~M°÷§0)¸ÔÀ60	½¨dQ$Ž?*¨m(Cɪ·ÅDZð"Ãnoç+Mÿà…sÞzé·ñs§t MÚ
Äq•í¸XŒ„eÎ8”Y¢ËðS3$¯ZCÐHK©'6ιÈl€‘dÉ)0ý`uàæY~‰‘	9œ<Yƒ%¶¾ÿþû¬®_%я€OÞ¡mIO£Ñ¬Ù~¨l‚¤OيÇÓôxšîø4¥J#(xÏ­ÑâùÜé/æÎù¹=×Miåë~µq³fT*­öNlF	Ë48qA%­%±…6'hË×ôӃþ›ì›>½I{ÜxݵŸaOÈø„µðË(hcù3ñÝSïµo~ GqSŘ}êËʈòØ™†^ˆIq“ÁÚ\{…K?ºË9{!,­	¿E	›ß8ð¡
ß=Ò»;‰Tc-ÕËƘ'‡N–¼hFÏ}×tgªaõq	ŹÃõøø+ô´Õ×#ŸâjmñG+?Â¥­ìÿ{Ö=õ®Kg‚Qðj_‹68ÛÄñÑáÏâ»Ù'ڌŠïº€‚Ù'k±00Ï¿tŽöE¥Rù5@&G³gúœJü/Œþã7⳶*àŒžr,Ðßt_>‹2\®´Ã¯¥ØsèÎç¶7s§ô‚Œ$·\À­Ãô†M4¼áÔM
þ©›õµˆ¾P T{6zßnÁú¶^ŸºÎÈûÅù½>õq!ÒúY&ë0à4sñÔc°—Ä–F¶ˆ-VÃVw	#QkF"9™Û3Dž<,·ç?òH©û¿ôû+
ÌZRŸ‹
|[Š”§X7L¦ÚÇ–¤á¨ÎULÉ ôO>õߣÏPÑײù,hj7Ÿ¬Ò#Ig‘ô‰NÄøù¥gc’àzn4¸*¦ŠÈÛh?ò’÷ìOÞÍ‘w³ÑôÑ	&;\ôGö$™AÈEÇëOÝ~PónËRŽÂð"®^¦_ãoâêŒ_Œã´‹Q»NS.\ܗ]fÛ»fÀv6Ýîbìg5Jåã0ú›A7
1ßX
às.™Ìç6ì'áN=‰Ý©I\h·N¢änøý±)¤r£L~$9ÒF<é\)_ºÎÔj£oíVã(^ÎFër¦Gæ0—ö.§~Ù­ßµÔ£Þ<JórbÓ_Y*sÐF*Ìö°]3êíJÅ®í¶ZY…º’¡dªËZ;R–[-֖ù§Œçââ}®C>²Ç¾+»ZŒlöÒDïBûóB<“¿°ÈEè	‡>ŠÒc‚a${ºVª5Ôýð²2½|9›¥S…~Éò¯µO-Rí%k²ð¬.,Œ„Q67éq yQÈfAY¶/T«”a€~1[w‚4U=põÛւHé$¥””gea‚æwíÎGEÓ[ºÕ-”´|rÚíõ~>8Úïõúg½ý’ˆR•ÎE¥1Ïpl:Ûl4<ÿ©5•å1Ë¢—g‚}/ÿ´Ö,ö·T«å:»‡¹„­’kË=Ì&f&Í»[w=©ˆ…5ÝKX€Ÿ¦Q&÷K)úˆÑÊttc·—¼·à¦ú»§åG.ã.쾃Ð+}^LÌU/Ÿ¥ÕùgŸŸíU·Ð8†¤M藔k(ÚHÞC¦ÝÜÝmڕŠ5®Õ†Öª{(&í"Š5$+"åK>¹z¨ñpº˜P¾¨ä$Rwž(Ê»ñP7X™EŠ£]«œS¸YݕÖO)ƒ½ktˆuBÔ'Ò÷ˆ£½e.Ü!dòÓÁ¾Œa’þìb†á‘SéҌ9}u›NÆtÁõ“TªÚ²çÌ^Ù×ð×ؙØSʵó‰$gâðԟ0n{ç.À‰†C™B0ڔ°g2çRÂ
¨Á Hå0ÎøŸî^3áP±^þZT·9ÆؔšÙݬ˜j×>egK,¼qÖýׇîÑ^w[|ÿ„c}(Øì€ÝÙÃ㼐-“ÚƒYá8ë”è -¦!XdûxÞöÃr;Ê£¬Òsjg©(¼œA„1©¶¢˜ˆ6î̬¡]"ßrY=¡	JmÐîîoUü²5™H&®ËÂ^á6zZ"9ÜLeczå“)#ÏÀ»Oê×Ç.ªxæ’ø‡ïØâ°wú“XõWàa!í@Ö$:ª†Äúšur[¬5&§îR8M ®'Êi,Ž­mâ <IÁŒ›U|¤ÖL®©uŠü²{l’©_|Ëԕ`ùj^…€“›ãÁXl
Üô¶(dp¾„-w§˜”I7ìÃÒj;ˆó"_h@Àp‚d©	Òð;$
ßQÐÄty9P6w<ƬèT~Ƈîµ<dèpåw9¢Xs'Bàd©7Åǁ¹/ìK}ÊE»r^)‰ãƒýmUHoà,.­Ö¯cŁhÂ>µ)\¢Öl6e៵w4¸ô(1ÀÓ:ŠNÉ¿`Êiô¬é
fDRþ5Mð,àój(\=7HkgæRûW-ùt0ºxFd‚Øóðéß,õ¯´,sô1\PI¹æ(ÑÜ{–z#…?´à?/|¾õ¯%樲?;”j	' ¿n°Ö\öH¢1fµ¢Åpé¼ÊŸX×Uö½ºp†îì&¥‹Êœn«$¾¡nð9óB¤B“ëzc(0³¸,CÑñc¬¦.b6CNšÚbæªÛĸ@‹åÈHIœ­]Ì}ÄÙn”j­$â̦²™Á8\Ҍó;k4Ò´~äåŒiç»Vð™a¹SX&|*t['_#g9¾:&ͱ}hWœ°\¬–Á­ömoHÓjQøVtˆ¿Ó7œ@Å¡Ýål‚ŽŠ‡4 ùP`0ú
sj
¥hаö˜Óý"âp°b$¸·ùmjî^ÅÒ×O=LÁ-QÃ`Ô?Qœ¤HE^ۜaÜ£Ti”–Ê¼G¯å‡cÁd¾—>“´Xµ¸²p9NÿÃÔùïÒÆL*$¾…¿ìj—ŒLiè³>ٌ³ÒTÝ	UՔ·•ODZH°Ä
Úö‹\kM8â»È<ÍûtìAƒ=Ÿí,žR”p×øäòEKe2¤4X²°‰ª²4Šl‘Àqè_Ú£|§étB(Xå–ÒMq´3ÊÉj™5ðRYSˆaø
W1k‘­ÂpÏl)‚Š0ª2õ5|Ñ"oöÝ:üblÂ}žc<ð5Ûl-üV½)Ê{YÞÒJä^’ùóõ¹oô[åŒLI=·¸‡B_qêùäëâUÀñ\¾¹¾Ö|j¹ãüÙðdƒKᣭGðéÁ;çÎԚP¦/2< *ðd`]oM¬NEAž‡²wø’–jw–NV/B­ýâvL3ø®à;tF)f…HiUhÔÍvÛ4+•ÝFµ>†‹j…U!
%ͨmÇé[ OïàºãÎù{4ùes)ù(o÷Qa˜âÝj]ûT:36eÄhv’é0þ¤PŠå<eH²X୓ß_êxk\ZÞ'ñQÄàƒþûã»ûâÿ(¡pF<Ý}ªŠSNÑU
ÈP.¸ôȉíî™4“`"YjjÎaCñ~‰M*cš<ðÞñû×Ç{ §?ñã—QM=µ­	íãòïå¡ÜVÍ"[Ù@Òl}hÙãö°RŽk­¦ÝÈE³
D&ÁªFìÏ\ãwøÉ©7}œ
³ñƎ흁–™D¯t6QüéMþRña+¨‚øcÛ¿ç|¥5ŠáŸÞw~êýØ9,#£B¬‚óÕ³Y(à+x•HЪïE=²'ø\¯8°{dQȁ‡A&‡”,?>Äv"È´Yꄝµþ³þû‡½UÈ=ÆTýu"Dþ…Ï@ ÿðH6ÄH0’.ü%r¼Øƃ0TbÍx^ðBæ
ª,´, \.—’xXw¾)àÓÆK<Îó%«Éë_ú9lòµoÁ²‚½¶å,n
xxž$?öAÊʋEêtf/ށ
BŽW”‡“`)~ÌT¹ÑvÉl“E³T7îåì¼5ƒ’Å¾?èaAR¾Ê¹ö“[cizՏl,îʧhÖk8ü^ÆÕç[]pNåâ°f‘2ŸJ‹“¦Ö&ÓÖdâ^sj
Q%øžóü$vˆîSÂmð¶“xúó2˜\ì%zºcyŸW³ˆH€q0=™»ç¨U¬5ø¾3B
ÌY¤'b¤Å(ïBV³ŸÍ!%ðžu첐¥íØF(ÊìŸÄ”cwzœ~rÈ7¥ü½wŠ•e¬T»PO›[èÎ!ï…
n…ypÕªÒm÷>îò[è7ېp n4‰ç|Ôx;büm}<±É%éÅM%$nqxŠQ¿'$Êë'×´ýûUºÅd©¦VÒ"›0B§V%ì®ír9”zµžªT¹×:Å£N‘%Ô߃Àþ ”?€NQ7Z%Ӏ£ßhÊw »>ú߸Jñ¨9<xÍá·4^®l·<%ñO½äM`ecÉôÙøgß2ÇÈã=ô ÔÌ
·	˜DXÕ:l|]KêýåQÏyØzέ©*
´°šªˆ/×9áS½ÝùžîA$KÈY“M±zÞï§çÕ©HØN£ÚJSQn}OÿáÕ¼z“t冑ª+ßòL=d-¯i6IËk¶ŒR-…¥ð5ž†
Ÿ»¡3TuqîL±óG}oݼ¶y*£‡ é‰lU/sÞxÝ/eõ¿ÛSÚ|Â
ÊK”ë~gj÷“EBӐGH—Cªe00vWAK"U=ôÇ'³Ø¥Ùl6ÈÏqs¾ÞÏûf4Ú4ÆoD¾Ïg¨˜¡HŠÓ%U5ÊCû;I'ýµ
½#,s-"OŒ"‘||%?ür÷ÚüOBßœ«Š-é^¡ë)órÊw;Å,ßL_‚÷)=$±³09”×½ÊYjÂNâv%V~豨ªNmÏæJ‹r"Ñy`¿ „À_íéÈ'’_ä„æÕ)wîèD$\ÑÛãÑ`´ÎU»ÖN‚¸æ	&±§m’õh·ÝNµm¢ê݊<@ãQ
GùX“v«TM®e˜i–MÄâ?¼
i× #\ˬÞÚ”Í(¿B ¬J»ÈjL@	°š4߁}g¾¸ÉoVûcº¬0"ý	ý}¿=ƒJ«f–jpÜÛ
³TOak÷oÆ òèuüGóØÜ똹§¢âò?åÂ$ò&—üÖÿødÿ§qM&ÄÄ&sh"œ]£e“ÌX«‘‰Bj5U­Ùärúë5­]®-^5Rõšõeø‡¤×øõJ}¦ÝàWr£Ú6Jf
2Þÿ¸·÷¨Ï<ê3SŸ¹LŽÁ­~ގz@æxÍNS¢r>_?ªY±‹¬Ý¦â¤;†Qo¥Æz®Í…6çAp7‡•è}÷5®¿èÈß°r³ðUaZi<d÷ʖçBqÍ
qõ0õ­5ž5SÔÏC›q¢_‰‚&gëÃä ßë8ìãÁY:òE~jTèKól_`<ay°^Ì%êL±Z-HA©Æ_Rô
™,·
'¤%ÞÿSVe‰ÚŒLcbP>—o¾[ôjg~‘ß;=×&{òy¸Ö|'u	"åíôØÛ+²’@r«²ˆFµf”Œ–Õ­Öð—;!©€¯PgsÎ7ª¶åÓÛò)n_¤æý„2
ÿP¢t^¾ì•<wL2V©TFù„3
–S8eæ|#,4/„ðZB@"ܓ	(›‹˜?7ç¬2®¸Üª¥)ì?ZÃåò26BÄ/Ž'#Û£"Ô¥0÷»5«,öËuôØÛ*­kÌJî)Ê`”k•’ˆNÖy#<ëÒ˜B\-89^ž\í_Þ‘šÑ¸ûýË¿qº+„?éû_W¦—fAü/œõ­}yÈ·¹p>&J.Ÿ`º%ÎßkËìhŽ'&ÎfÌĬ¸ǍÝR¯ÓšÙ.µë¿ß)Ñ´Ë=·s&¼½C]ê®ï¬­®¦zVÒ@\ZÖ¯+«-þVRÅÉwˆyµ¥ZYeZ?P:þ2ýßô©OãCTEáâ"«$ÝÑ#`§|¿•Xºðe‹ŠäÓÔ½æ´Ú~'V[Õ
aÝ
dü
­vÈÏ°†€2µ¯`H˜ð’&ÂVªAÅ
¸dõ&~–ù¢ô`üï­Ñ±sØØYŒÆÅNãüÞ|ËY¤æz‘×à[øuûzn–ÕãŽÌùM½ù,½Œ"·q Ÿ| ,"ßS1‰p>l¢–!閤œøî(»\Æìöt¬hüýng_PeÀMì´»×=êþÜǶ/3íKv:¢äiÏù Yîђ•0MX'v@™yÜi±è¯ŸäÀ)~?ˆÚëVѺ†¡øzNæöÐYDZz¹dÛ	<Óo᚞‹.¾$ÛØt"—M©¥j¨˜
ý˜ÍÓ¡…«}°ؾ@ܳº:1%»"0Þy`H*)û×¾|‹Øêföü”?¼i®AÁÃ]›.„=u—ç|Ay.¨˜6^Ò–Ж“‘<Ҟm÷—v1Á#b®–ê`eÊ°LºÔæö¥{…ÕW$rR6çîÍx¿Ÿ•(›»–W3×ó]DâŒ73²ä´²ä3³ø²¹2h±îd’_ø¨©©Ù6לîæÀˆu΋nJá¥+lA&» ¨I(+I’Œ°Y郒ï”óþÕw)©y}7f:<ðΖs{r³½×Ý=Y÷ã`,ËSà…·â½ÔñD«C’ÂC)¬ÊóZ¨ÑW„8t>ÙrÕcG›X,Ï-ĉ¤…¤i É€øëïÒ샟Þwñf§âjºL.°dh€Ô8waú•
#~æz\Njá22þJaœí­bGª £onӆÁ‚ށ…‡ÜËRÂe8WÈP4³M‰üAʘ`¹ƒ"ñÙÜÀvßp϶æC45ɹ¶'­¼J²
‚|¤»
cYãÕßd/é½é3ìߧòÞ) â^zLácߝÄñPbEUnŠêaX#-Ëó–—6oo®”Ó*Áh°3X½µáa·=ɓOàih£R$H§Õ«:~Tiö’™[%Tšá¶J+èp,*³àƒ3}ŽõÊÜéb«±VäÏ þꖪ¤d»5n՚•JµeÙ¦9HH¤Ÿ––Q?GkÊ
jRuIüÁo—–ƒå|ðìžK²&#ü~õ˯DBˆ=†‚åï*¤Íž¸fšÝT\Æ 3ÚÍÕ¸çð͸Ø/nZÄ\¨ýÛ?%R€Ï:°QW6PÇ!þ¾ü÷tk»”w ÙÕaá5Ï`¾&¯
¶“o0êºÞ@ð×þë
C`ÏA!`,&Ñ!a%Á¿¿{:¡Å«)ô=®°¥{ïLËå%Šî–cF
Ø=C„ƒÃPÿþÓó¿ÿÄӎ
òâÅç‰{ú#zÒZIò¯5ªÕa}X©4
$üa*ù§Â‰‘~jK
à¢"Œð_Êþèa»!?[í~v<¼º;pÅ}Á×K¯ˆ_#õÖçÎÂî^Î7?¿Ml²ô¬sÛÿTMªif‹ãÃýîYo‡~çm·×EÁ¬ªhn{‚UNŸdIòd¥ti;Àò
3Çsy@LŸ«;R•Èc*)†ºÁ‡z©RüêÒﰃU¥jf¡ ‘nçkN–PÏc.SȽ] ¥WšY¿Ü–}–$ðáŸ`ËzGÍã§C÷üÌ>?rÕwô‡ú×I…õ€”g‹9²d†šíÜwæø—ƏüïXîؒ“·'Þ»_åÖ®U
wŒÝF©V[jR/¨¾óÓ˧/Øü®áNåd›¢;[@—’øÏ2(+NÂˆ%øø¿ÿSëÁz\Oÿ]}ª½$µ.Fš‹ü#¡ôT½
H‡¿ÂX2
o
7%LÆß½þ['ÀAV5—¸d°(_Ÿ ‡\ªËü2VøÍ¿
"ð“{2û÷
ºŽzM¸J
@¬yX4ԟ_‚µ?kâ/TÒ£*ìËN;ÂðwÀÔËbX5rÐ\ÛÓG-|é;U2-˜Ëá7ئ–}óßÅü®Eøˆ˜
Â塲/ê:ˆƒÅòå6{’H£buÝ-àúŸ‰l5B	y'È°°ožh`û<G÷›QûúûÈ¿Ý韚|)y.
©aKÜÊì:ã8ÆÁeÀÛp[íà»®™‡Ë2䌩ýyqÌ,ˆ}àTêï¬*õ÷[X„	
;ËŒ	ô
/ޏ؁LB×ˈÑ«o¢2qéâù(‰ÿ ñ°¾iëÕ'KÀiZÚZíp ü¡-!9——öÈ¡ÂÏ˅{E†24(_Ï­?"¼$‹
=ÔÖÇLdè3Ð!Êžà[Ãs‚úŽ«j×0£0g÷W±þ/ó/dÿµðws}è/ôÞçáÍI,Rx/e,
Zoš˜òS–»´=O‚ü÷SJbOÄz‘ˆGu[\S<$,å‘€²ÜD“´SnTædQ/@!¤cR@üŸE*œk¡¾ö%’»«m4IÚnV•Žy2'@ú–RuåsÜj{ôÇÑ3ªQߖžùÞúLŠ!	Ðxx>ENR2E/­ÏìE`ŸS™qöo !ÄxâZT«íÚÎthËgZϺxx…TÇË	r]vW–­v[FëÕ¤ó˜¦W…æ/D™lMݓã½w<YdÈDDü°gîð×A
€GÖK7‡rŠ€»e@«²“;ODïð ôæà°[:ë¾U/¥Æý±sÈ~ǺºMòÙÔ¾M9@9<À%ӂþ„,	a'
Â/%¾r͆P’"(ù… 4䎕lDl2¦N]‰>ui_¸×ÂæšÐ6:¸	1DOHó€¤íä
\¬LŸ„„cёÇâø͛³no5Ú\º5$”˜åÈv²ÙÏ-ªuýüá²r!í)ßJKG³YµZz¥Ò¶Ø˜qKGZÿÀ‘ւz\Õ¥DTPQ®[ÜÌì‘=F…g9\ˆ×ËɧzÅ@ƍZ°xù8º@P:Q†z|¸taã‰Z-ÿ]–ïj{º¼Ä±åú«ðóV•ôºŸa	0U L`gÝÃî^O¼9>?tgï:§]–¶ü?Ø7§ë‘Ô:¥é‡“ýN¯[¢$þÝcñY,ÎßPmò¡;Y^N½Xö½ˆÃÅI+Ø!¸qˆ<8?ÓƗÈ<_„ÿé{ÀxÈr:ôe€6^نÿ=âh@Ë)Ó9è*wŽ·)I0U‰K{qᎤW~+V£S¾´0Á¡±ññ®wö¡j{p|¨oŸOx¼zuI,ìKº€@mr”*
ÒYŸh+	oƗ¬8ɤäÏÔS²>Üp¡R¹EL_Ïxº}öÑÒT9#ùîÂ3Ñ~I¨2u¯-g¡´·Íäc=Ù$Ž;I™VîLgkhg 1²z¼$‚ Œç¶ý?[b0×KÏ4 ñ̀¸¢;(õb‘ÜàRÊ:"6&íOm{äÉñ×Yº	ë‡nÑÔ碧·çºËrfhõœKœ”Ü*r|ZµEÑmÖAð«ßªÃ²pTƒüvŒ†ÌW á¢QôÔž,æ(00èáĶ¦!ÈÓHâ~>p	²‚ÄïÅ3 ØåkٗÐö,¦òÕ8Œk~Š8Ňx{ÄÒqÖ¤ä6fϪ?¦1bJýZ¤n+ÿðZù’÷x¥ðÇpºX±™ø—€²îžöù”ŽûkäZò—Cªõ]]öoÊ8{+E
 ©TAƒ¾“bÆÀlµmČö¸6l4wW‹Ü;]Èàï‰AŸ£lø“¬àêP-"†ÕEFÏäï:g?vN?ì÷Þ
ÕÏÕjÕÄËõÂò@œ;èáQ¾vF‹a-sg°„#ãm“È…Óý©×==êJ8u‡wԚp½ùÑj@ AâÞ”–‚bX8ø=\”á{BîŸeø}°-h·è<qe9ßý,š\@V8{wJþî姑ëÈ
e$&éÓŸ¢ª÷.çh„EˆáHbè^\¼Æâ]i
ݟöyÔ¿š­D3mørI]ûÁ2Z! ± žœ±rgÄ^„6lj/رŒR˜Š6Ò\×Ãq0ñùþº—†¿ÊG†6ïí¤íñý8
‘e‘ë
Y9JäÇ@¾éÚ
w"ÐÐëƒÞÙê9é¾#ÿVWT2ÉlÇöóà(p—£9ÃQgzø*g$È1ÞWú²PO3ÔS¾F<ד Äñ»@€

M¬£Uç´V£TklÀ:
þ?®Ùçsø\xËÙÃ"b|ücw_ƒßû *ÌóGøN¡ïÎ^¯ÿ¾sö¯7oº´&bþÎÄYܔé¦Æx8gá%œòH÷7+»ûºV'pÑI¾èTì
½‘hi|°3º¯l#]:d
'Id5RרÝÚ¶'žE½lP×Îð‚Û‘Ié~ÊŒ@)
ÑTè`œŸ~úIùp]ۂÆß[ù[Üf)îW%½Ðaºß³v 8G€„Ag©¨ýý$äl3þǨ^Ø¢e‚
…ÓŽqFW:«¥ðu<ꢘp0Âa¾ë˜ÐãÞbª‡ÏB¶¥/’À‡‹à
O]hpX_7ó6‹…£N¯wPeu÷ͤJPëˆ
ÉüÄҋ;.HO»â<¸ãj­j•¼ú—\ÐÀHnš
+ÈÈÔú§Ý‘kW?£çq¢t„õsð€º,õgõiÇÏmÌ
\©ø—GüZ?îɑ‰SÕcãAƒ²3Ö	¥O~ª„¾–ê}
„
ÿÒa™N,Ããôh:3Âö$„¼\%Ú¿»º@2´ö²é€ôöÞ±¤Š°Nk~#Æ덯#1ZÎÑ4	·ñ…øh!^E€Fí¥ÇEa›õjɬoÂÁÑÝn3‡®3´+’­+òÒy%Š(
ÃéaƜêHÇ\òÏT?q’¾¸q—$UÌ­k>Ö$ÆÁòz.ü
t†6gòUtFø“OˆJA0—ÎùZ90mn{î䊽¯u8ó؝åL	í…,
#	³õc{³]\¸À¸Fc[ŸàLbˆ O/s䩍’;ì-.	•ç×:õ ň‚zž—0yg¡˜5‘óÀfšpÖFžŸ³Ùs4Z‰¶ªÈlù/EŸ2õÑY;ˆU핧­ßaÕÁ
°-¾gvœgÅwɋH«$ORj¹’W5ˆ’̃
¤J‚êTÛôœV—!±ó9yšÂ…Nj}æ&{‡ÝÎѐœÞ#c¯&¶úñàìà5ò<d˜‰-øµž³	œF5X·ÖŠP-¹/´jV5æԁËöšžèmÿ<Ña”®á|êxé5òVm6åÛpIJýyB[ÀáMùJÚ\Ð>-
AózJÙ™œÂ×?X“Q~	
¢… ­ˆ;Ruø]©z³µ
¤@<Æ}ÇyÎ×8‘¤Ï®hý*@øP†²ãÌeFú“ý~çðPm	]YòkÎåY£z}m¶±îãÎn­Qj'㌁4h±Ý-}Kiž¾'ô¡oxp43ÑôÔ¾†Ñ¸¾•ù‰*ÂCåÃ8P¾ÿ°Ÿ>ê­vAö†Ùõ! J¡1–Ž,3ù ÆkcÐæ¨ûQЅí£þ‚ž£}ù¦Žxs|xxüñLtz¢ß¿g½Ó{=¥pí6̒®®í¦0O=3}§‚çRß3çöñùÈY(²ÉÌ#ÝJb0ù4u·ÅŽð 4Ðìaè\H2"Š,jê{º@~:|wæç¬Ò&µkêfR“°¡£žÔ$bŽiEÚ$
«¹çŠzRþ‹ò/ŠÆç'lz5ÓÈ"ˆÇï³”Tu":ñbÙЊHTÊ7=\ÞVH(@¥ê3C(KJ…?ûŽ×¿DA€O	F¢}¯7a[M”ZHÛlc`*šÃz±ÌÒ¶ê¢,ãë+¡ófe4¦.4‰Ê^A’éUhSÖh—³­}rӗ¡AÃ5n+å1'! \mM}‰òʞ{üÜ…(DäeÐ‰ä¿ ›¢/cœ^¢|V%^Ld‰Ov¾$©Ë.aÉ))˜RR1¶”(yώ3-Ӄ˜r¼È8Fò錙Þ.ç”kÁgL_$à4éý)¿·bý—±cØîÉiÒ†¹¶ô@8úðþu÷ôLòodß½w]bááÀ3L9oèKß
îUÒß‚]G}'‡¼€ùù.­;(®±Í09ÃXš6+.­™­2ö\Þ®Q­¢{l«Ñ
=ŽÑ£[D¬éÐ>Œ¼^¥¼/úBÁûp\ ßÕ5©¿öž”Ý”ìîÉAOš´Îþû§ÐÆ~6DKvð
=¸>s<z1žGã]b-3ý,o
üÍH¼9­&ÊíízMzÊET·¼Zë`´z™ƒÏ§Ë˒`ÝÆö†¼1ø¿±- ~ãÒ£J¢Èñ7¿þáxÓåî
Ò¹”hr¢!H<‰b“ßÀܹ‡–6én3$f­¿[gØQ“iK{ló•d54íDĕC¹xДÑïNÉQˆ}vhòjðÜó£;´›†ßGß¿>žéb*Òé9˜÷ïûl$Bø]ý˜é Ò^4µòYÓ6«ÝÚ¨R1[ƒV»½úYS‘ú¶©7â‡vd%ð_£!]¨þ*{ˆ-مbÉ.¶z|ãSÄù1zïŠÅµ’»¤SZ~0m~Å,¬·üÌ5‡íb“®2=¡ˆDŠJ9bО}Ξܔ	10Ø9§„-QGŽ9ž»—ÏTŽZŠÝK—]mž…bˆƒSd‡juKŽ¶5¶CJzËX|¡ÛººJ²Ä¹käýRT¿üåU¬·¥¢kšÉÚæȬ.\µý÷h<å«·ÿúÛ7põ
­„6ï»x/mŒf’'\€eÍ'®¸åQ àÖ6ÙÛԆÝå\¶Àý‡³É¦;brØz†üÞJS[)ä´v4Û~é¿ø°o+Ð@æ:äRfB:b•œg¡Lv!=’'}œrÀãw®|îÐ}þ3\°‰´FrfaÜÄLnâ{®q«št±óeeå¥gÓñÂEOá­OöÍVØQ/XY— ¹úC•Îx=I"ój Ði’—uÒ篣Íu½˜´ï7~o£àÉ‘é#Ò&ƒ-xj2_¢@h‚·µOÍþZî€0sÇöÈFëHI’iˆf«Í§[–rHS¬çêœñ’ì9Ê ãóÔCÿlRt£¤—+"³{#5‹ªxÙ]Ò¢ó9lÑ)«Õ)`ÎS£ùo]ÜÝ¡eN¹ˆ¥
úübüÊ#þØ9=è Ùç°{ô¶÷NtNO;?û/!G™=Š¶}¼GjÖ¿¼9ìþ„–¥>Áî3?úõ¥Ô	¢
)ï)‹ð>ì=j$t1>
¡D+Œi
QÅljÙaõ¸f²àû(ê;¯ýÎccˆ7¢¾R𙩹<¦€ë~žÁ©.†ÈŒ}ûbÐ4	,sng@bÀ#Üi|’¥@fŽuÁg2ï IPޓɐ´¢¹z:k pÅ`)c‚{¤"´ø3?B^—¨ó.Ʀu‚
õ’ùð3{‘n¥5øh9Ùh˜=w:r8."O_‘2ؙ½à¼#ÌÔP™þÖÖ1Åí¼ÕÛóìí`ւePMQ»Ô)7gߝÄü†5€~–Ø FØa“>3C^·„¬Î¢{ŒMú~ã(±Èf0Òd‘x;~6+uÐAÛxiE
ñ^#;˜:É#¼v] ï¹5˞ÈÞIËU.–‹‘{=µÚ	µ
íÖ¡s!.ÃA}íҙ^jÜ£{ƒ/Æ÷¡ ùÂÊx$ŽÄs¼¾''¨Ô½Bh¯žù
–1!zS?‹ajæ…UMKñ–8¨·´À¥>‹E´ékÝó£ßR±­óÖ?‘qöڝkmv5͘Š}Ø`b„±Þ~•ºEZ½ÉcH{Wò8@7¡aÆQM‚]̆Q—@¥<Œ(SÛ­ðÌù”šÙ…åÙ}™¦&áúhU6šdsÖÁžA?4fp«š)&ö4‡ebn_cbz~O±M„šHë„1nŽ¬¦Q©´V½fµVZ'Â@Ríáf¤ë²Žö‚÷)7×¢»ôOtl럋}îLÙ°*\õìk´>)Ÿöh €–ê0ò
[’ò£1„¼8@Kí_[ÅtÙI—EÞÌÿGL¯í¢{:ŠÎ[[J"±pÙ²Ě$tÒc9€d{Z¼‘мwPuéI[\*e
Ÿ°0ü”¯>1ÊJj¢Üù›ÍF«eV*†Q«ZÃz:e%‰SVb3
Öæè{ü/Q|?2éjwÿ./G££ö^§×Ag»§gÇGý£ã‚Y5ÌjÓØÕ^nS[ÁÉÄIxW¢™M,ÏKE`Ð@¢oܪ
íVµR±j¦ÙثѧHGžÖˆ$Œ]rN‘¾)rµEÕ¨d˜ö¶xýÃAÿõñqï¬wÚ9¡¿N?ö~>éöö‹­·8Û{×}ßé¿ïìûN /¥üü5L!㊸?/¬Ñ6ežì¼}Û=
9•p_o9 ¹$÷Ùs-“ÔÄö’Þ™
ÌxîþÏFUš€ §,œnO|Ǿdâ¢䔊AŸ$øXÊ,/Ï÷½Pg„ùÏWôw%pû÷¥Ìœ~ëfÂý«3FÎè“^çTw6
øÑ%p'œ/.ØPZüLáìŒqÜë¾@“žg«V8'|MŸ¡=wJv';´†6™NnžÂÄF}\€ô2T.”¡q·Í¼ûɄL<dÌwÇ0ægØÊ®þRÐe¾ÎÍ}è.§d;
LD Û‰÷;ggÒ{ôìàÿuÅ¿•k
æÇk¦ï/A§’¬‡Ç•P$dÀÈz…B>8X-(‚Þ”6“ÃÌT€«<;))g ûµ]߯±9Šg¡1^&ÛÊDÄøÈZ,<¿³¹°É¤¯5SugºFDòÂ\CÐÆXÑěYChgf4Ãu¤š,%³K¯ F;ì7–	©hì«`Ö²*^U0ë
}:ƒ•5ÇÚYÃ	ⱙф“xá͈µ’$I°Ò[Éá²õ2©Ø
mÔ±&” 
øŠ§g™óµMš­Q31¶æîèõ9%¨·_ˆ­Ú3d;t
HÓ;rL<Tø搖8‡¤tX+²Ï¥nx%0e³(
\ÓÞÉÛ£³±kˆª8yû
ÚT#ÿŒMÌÄ\Ôðý‰ÿW}|tì«”ñB¾ÚÜÕ^²‹4ˆ£k>¹)‰-ƒ@Dƒ¢ÝGòÕå^q`$`AìwÏöN‹[[hSJ½-G÷ƒ>Ô+g`òŒ]¸÷17Zu£!g0›»C…óÖjœ›»«éî^ÇÛlµ
ßòJ‘Ã×îo¹ØZs½ø¼Kcàü2™:ƒj"µ†aÛ¥¡Q©Ô[vÍ4šù´H¶Þà7£œgjðß$¯öÀz•ð±
½ä—´Ï€AP¼yX=%ˆô~*-ê‹þœ aÄu±hd-†I 8K¬–…‹+¬Âú˜´ÒÁ§õ9ÊéY3' X,
Ї—V¤ì	h½EÁÏxVÀª"%¦Cþ}9Ã6H´¥êQ&%OØW5ƒ,:ÚHBµ›M³5®T†µê°Þ6rš%“Ò´v!R‹jª( MSª*}Ú=ìô@a©!ÀÈ[aE„SéâC(€ŸNÐzÃ.É<ÚÒ-I•õ*–WSWPÃmº0ôêr%q^8ç˜u
¹Fc‡Ü³4ZؗôE‰ë˜Wkݝ¤´¤”ª´ÚØUSY#KZ ÊI²¸,J<¶€ }.Cü9܁K†T8wšÕt•Æ?=¾”¨>yÉ¢(º‡9Êö?EQGƍj
3ʸú£:¡†c˜	
P¨A‚º ¾Ç_XJP‚ôF£UHTüFötèbt¥íRÎÂÌûll„·¬éø¤ ßé
ƒsPhg·ô!£×uô–
!#»)k3ú%µò5#ÃÈn¨¼¦¹†êH‚œBF°¢×Š!%‹îÑÞñþÁÑ[±u¸×ß;>ÞÕÝâ?qmt±¥‰¤£ÙT"Mš(së!¢ƒˆ³wR|ñϾïçTðHÀQøéÉfûf&FNÉ%ά눿W†fÛÞ50=]ÛŒÌFBŠt™×lC­6%¥Ÿ$ñ$ྲྀkH’B؝@Á’$ïƒa
º+ÿêKˆW S^䪧ÏrF®6YÞ“G}rõË5²¸¢OLTq¶€&~3[%£Zõ’Ù„ÿÿ‚º%ùô—–5¡tîŒJjؒ{=µçðÁhàŒ ¥”€cÈ	r2aaqí–é--T?j+™ìk-CIð瘠אSÎUy‘aøÈ0[
ˆZ¸ã£€€¥âÿÐM1´Üä)¤.{G_¶jM!6>g$u‡„¥7jJñrê©Ýç¼?JÑV]2핳
n
üÿÚVòLƒåE†Y½Ÿçèè6²§gìH¯aXÞÙ¿e‚¢­Ì‡(vì÷žKI;Îb
Tc`ZV¥b[F½9hgð†8ˆæoÄyΑ7Ôªñ0à‚ŽwÁOvÞµ5+âS2lÚñdD“Bþy¬ôˆ
ô%O
}‹ÐúnÙþà¦/-m¡¤ôIî™[ âzê=3,òõ«g|¯ü¦ôþò½òPbÀô@ÎÛ;üpÖëžöß¡,µzs9ŸyúÞªï•bX5«=U·n4,Ëʱµ>„Œõې²Qã´aø³Ý\h*ãÇÐ8ŠìÞKȌ'ß÷GîÅe䃆üBÙÂoõ\ŒSõr¢AË£å+–¤½úìeÚ÷Ê%âV‘èøÁéË¢+}’þ<Êâ/“,BÇ>ÔjŸ‘ÀDŸú¾ L¶åX
>X]Ýpõö¤&<¿²K<¤´éá4¨¡‘•-±ÐÛÜeô?
OŠt©6ѕJâtDrÓ'¥=(·“zR0ÊÏ{n¶‡ô[ì¤Ä¾—'Ųjm£Ù®T»ƒf­9N?)qñ“oC:zµ†…ùGÜ Ô%-ƒBúŸº×ï­ù'Q~RU
xÆ÷.ÑÚ-ß(ý‹"ˆ)xΩs‡k	Ò&š¨W÷üå‡îÏ¿&÷‡¹àèâ#¦M¹ø´¨b8ßm	ƒ†céxŸËXgáÔ#TøÎâœ)¹Å'–2Š/”¹mkx!¦î´Ìa´>»Q
ý—X «hÚ3|êµÚY ¯ACIÎêi¯ë©tYCkŠÁ×ÎùTæT8ÅÐÌ»u2±¦úFöÂr&ìkÏ1‘—®·"P§Ç,<SaØ锳d®?ræpéOnü|Šù!B2)÷ÿH ¤jê,?ÇJlMnA[¹¬ 3š(nÆ×ÁT9=Î{ʶL܇ÂxÅ'۞QÝL'Àæܽ¾„…QÁUÊ/‹-ÞȆY¡å0ŽéÐk±|C¢H	zéG:±½þœ1w§º3¸#ÿŒcgò(§½þùËc¯$M{Q‡“¦~ÅÁLí)§ž×v%H˜-ãÑ)(7”„mñád<&F–ZÕ*
ç¨#ƒIë
$—nT
Â<Ó¶vǃQFœ`ˆ46j$«ÈíR¹ÐöJOÃÎpB™»ÙLGU)õ
>ßÂ1u&ö¹ä~ñ {‡ý½ã£#`j…BÑøî;ÃØFê &¡Ì¡G}ìszðö]ï¬`˜4š!f S¡¢éHœÏ±aŽŽU¯*½õJOy|ٔ\µR©$“ÎÜþ'¿	ä©tpéÀ((\hÒ¬€dfŽ~Ê¿Ò[».­“ÄÞ¿ûžQ îS¹¿áâxÊ6Yùçñt0B†*öÎzG°’ã#ݳ
úŸÚÃåÓ`P÷½wâ´»÷áôìàGÎãÍì!¥­‹td~‡g¯×}©òÌr.¥çC2Q<p‚«¥å€¶~lu¶
oÆ`·b3Øɂ°?ñ%À"
KTFo¸°ñwŽx¢I·-¡ïQÜ1ñãîçÙü©L·Ëöh4­¶Äþ4“Þ½öíqwb_bä“üU“ŒqÈ\GîQ™Rºå¸Ž¤×IùA„p"‰
!

žº“Øـ3¶€`îaÁ«£ƒCqiƒ˜,¶ðÁ@Iô^@¢ÅV¥à—¹†[‰³<ê×Ö)&Âúњ3s†ë©ø‘Øsð£tmC¦Ù&‰óÃ÷,­Î%.F>8Ž(q6¸A­É‡.uSø/zšLÅrúߥ5¡'HäI„!¯²Í|>TJMøû³Åœ^'8œƒ0ç#*w,L?ˆO	XšªmÍf4ìIØ;ÃSOÙzP´>Šþ-¥ÄPµg_&E
ô	”?
ŽZÄÜ =ë¼PÀ¦X‘Å?ÁnóH;‡ÁÆk§x@z†œ/1ÔTû¥‚Ëò3½ÔEÖð‰LV‹N„ñ€k—ñÓX¹Î$¯°£ãƒž*GÈiJBxRÇZM“C[»¦Œµ‰`÷#\ÒîµB®/xJ‰SG%wqÎ15ãl¹Ø@äÌÓ?‡´I·FEÉxäŽgO©‡ÆXÏ 
ÔW/ú‰y)ã×/·âK`EåЄõ!k€S‚G²ÌI aË
±RyÎí©ŸÌÜ;ÁªèÜD³ê‡óóxn¬óœó†dB”œÑ¯té]Ø£}¬SþŠifÁ÷æùÒñ°<pnGW§Ä¥¬Ä‡’ögXÀÐA­½î ãY~õäùLì+{èL<·Dxô;K,ìÉ3ËØÓ½ çÎøò’šŽ\ªd„¡‰½'mS¥è›åNm©gh„¨mÚ­6Œ}ÐôMÛ|ÃVtÓ6Ý0Ú´7Œ@é~Ôʳu‰*G³‰]Pw(æèŠB,oNéžùmžÜۈ‘àN˜ùpcÙ*Øižÿ-0”÷–¼(æ:ʾ—Ü<„£Œ'©M°j†Z|¯Â0m«Õ¬U*C{×2ÚJ­Lƒª”imTÂCTÊèGüê!c£~Ûô0çT¶IláSljt`·á—ñQŽžR_Þ»©‹RÀ
–S¶brs'Æ®P°±b%Ä*Ü%êó°4	À™«)Õ0‘¥¤	“¹‡gœä	dä„ EBt¯¬	Ú´þµDÎM¯%”Ñ‹M,À°p+ìž[zþ
¡P=¸±½=,9GóÄD™–_m,<!€ÍX.Ž·_Êô³–E‘’e:= {Ø)œì¿ïœþÐ÷åÇ=w€7?Õé ù\ø0ú½1åÔýsôäm-„ºÉ܋á>á¹úÝBS¥ŽécvßtO»G{ªc|K"öŽO~–S›]€Ö0¤œ¡;»QF6Y}7ÄZzÌiwùù©´ÀŸ”NùanѶÀ@þß½aiÉ+n	NaOO·¯›j™>,oh]Õ÷^
윰CZï„íÄ¡F1†WÙÚ+…S_[AvC‹V!W%XCٚÌ'nQtƜ\+
VòWCÄÅbšdmۈ´ÐAÁV8ÞvÅW'8¬cÂ\YC•ÇL|ŽÅ€_‰þ¤l©Þ	¿3À‡$DTÒïgÖxž“>ÿ¿¸+jôke3Æ
³
·óhh¶ÆîÎ1ñË9քžö[ô´ß¢ØÒP¢Ù®¯,}ojͼwQ¤”œÏ\onÛñ`qr>³'öp!µÑ"	žâÙç7ѧ¸uAk\$"êµWa±ìËv~i¿Ai¿@èÒ"š3„º•0"¯ÿ£ÎáÏÿ¯»âõæz‹óy‚@|¡ªÖÌjm`W*ãš]·ìaÆ^]v9ø’ž›
‹?ÂuÁdž@úq²ÐK€…žßÚjRü	s¾Ñ¯ÛS¶Õû¯îuϊð…Šù£c¬½)«¾Ò.wjc9mæ0r„Ѳ<á;zÞ\%GÓzŇX1=Nˆgœš`~
•K“ÝhÕܤ›„6¼¼2ÉW‰f.•™ÔÇ‚Ö¹ýoôØ®‡¿Tžæ¸:¶`çG­ú0ËÓ#Ò=¾û‘\¼Ž8þIß\V?‰Èÿð€xÑ'}üð=ÕÅDԄÿ$3r‘\p¸~Y¾´žòᅊqZçï,ïb˜‡Ö£×y˝Öy4a;K£&±çNÇ Œ.ŠØçýñ~—ç%úی̹3$Ö%™jŸ¤L€2|ø)¥Ù½Ãö00ÿŠ	¦’ÀráL¼çƒ¥t:ýè×*UEµY«WAk·ë»õV†C@œbMøÆ$/Oúَ%}=w¦Ö|nݐ¿‡þVœ·ý7Žö0Ô ß9}{†Ƨ3N‚Á^‹—ÏUJpSuLIïS >/§uõ¡&z &Aç<{ÒÇÌ{>²gÀÅíéð&eºß¿ä	¯Ø{¡R¶¾‘;^o6Û£üaØÆhåŽsß´Íæo¹80osµž’Œ„9t–÷ã 棾Ÿ÷O	€XўýUœŽoáÆ渆	=3aF|ù.rŒéôà'}kӃ…n–…×øè:Ãȧ
Ær6zÅw=?‰$׺™úI¹Š
eŠAP¸¥"Xú|ÌíñS*Ï—Œíœ³î¥Ç€`x4ͽNa	¬±++Ó?¦‚ƒ˜Ð±
l˝QF—9ç¶Ç¿_ª
âò|þÔ#
ºáT¾ù0FN—R‡$^çð§|7)Q}”yëø$@ÙÒiO~­<§ƒa{8²¬æ0Ës* ƒ
UÛ´Ä6)ތ´òL‘!\)$äá§qÿB¥ãfiàOê—Ù'y(|ùdNžàѸ²÷	ð2tòM¨¬e‰H4 ´Ê_'Bع)»‘c+/*ok dÅwó€@@Dê¯ %õzÆ7wîE¿Àhég#Óiì†6ݯ~y
—Óèޚ¨Oäµ<¼°æ˜&Šr$”¤e¨kJv4Ï°>çWƼ˲TŐ;òa{¾ÿ¾#t>Båúº>
z&9¸ú™Ù£Î¦2’ž£=¥I$«žæ‰ª=µÑeªpؗàpœðI¦¤2qØàŽ¡f.¦vÚSüՋs̨ÿÜñ\^Ísû3è×Û/!Z:™ÛWî'»‚>nƒõû<AäSfW–aSå•J«Õ¨6
æ,p_=Gz‰¬7"YµT…+®dîRV¤TGGá	ãMM%±y¨ø™i†/—¬y¼ž
ø3–ð¿9üd<c(<~šCìbÏ°ÅqÖù±{r|pÔã—þçËêYy캨xPYÄWÂšÌ_ˆÓãÃÃ׏{ÇzçÉeÇy&ޜ¿'¡¼ÓÐáiÿXñÿáªúùÓmøBpùKæW€©O ÷^˜j?þH{ñuŸ´óï…9D€{q‡ a{r흉¯s.¾2¥~{çBíÅW8佸³sAû0ùƒíEv~¿£²r/èLÌï˜GåÁ¸øîÚrhb•JåŸùvñ;t‚Æ,
T!óŸßê
º53Ó7íΘÙã¦eŽvk®§6íN¹Þ7·iß {¤
›ÿΛæpÝ&}šõFŠ÷ŠuáEUæ•ëøÊL:ÖîùxçùÒëò‹‰t.»LàêK½ÏϚ}¶¼|¸›–²߈©%ß^ÐáI²È§ƒ²þ¥|G¬$	áëåϊ‰øõògÄDòõòÍa⏽¨MK¿^ƦýY®ڇØóp®ôoÿUEߋÍ_¤ûæ&oÒÜ+ß«tcÜ·•–c†Þ¥[ïÒëžÚßýæދÇwé{ÙùÇwépߥ£”ú흋Çwé;íñ]z]ì<@‘ÿñ]:„³o‹™=¾Kƒ\ïñ]úeïÒêåíñ]úñ]úñ]únìùܝcÌ¶ññ/D÷ôôøô…ÀÒ»“g °ç ø¶I#N¦6t§*¹çAh6ƒÇÇîom/»»»ó`âOùØýxg=¾ ?Ƚx|A/è#9G™ž§ËžueÏå<oè©ýr½¢
ÛjXk¿¢§ª½£ßAx7ñŽ+ÄéH#aËÀWæW³¥ÍƒÉö.'±á#‚œHŠ¥-ù5ÿë˜ØrR€oQþ³SÀmö9K~À<À|$L&`~½YlüH9ØæãÉιyë?”˜÷ù¼•M·‘6“~rË>ƒú®=®7îBö‰J>•7¿cÑ'Á‡ð
YYIÍ"P¾®ûàݟµ/ ‡Ì¨Ö߉G©ñnٟRÌ£í=ä-»Í¶Ü%«|[f&_S¿Ó–Ýfc¾Îíö;oYÈ·4²m¿Ó%œ‡Bò›âïՓë>IdµÍ6á¤=¹éa±æÛïDneü©Œeë0ë±;Í¡«ÄÚK…Ĭۣ]sT©TÛFs¼›É7?ÄÕÚK¼¥}Å
é»%*J(YÎF1{û@¼Oßٓ‰+>ºóÉè)å@M&[¬å0ð>aˆðÉY~úÖ\üØ9üÐ=Å:æ/¯1r"GÈ;ij36]:Ê>R—ˆËs¸ðÀ“µ¶…lkD
rїÞZRW­Ù2jc£Ri¶-³]O¨P^.Ú
õàÄõ¥U.5ŸºB$½žáð#•éH¡‚ž’%ªáÛ05
/œÉȧ'£$Œí—~ÛàíH–—ǝ±–Ÿqo€Ÿ*€±² š5å2ÊÑӟÏ0JyÔ=Fyò«ìÙÿϧè0V3ñj*Ü.}m¼æZs9ïDðZνzm„(
˱gø¥=Ã+zÕ|rÓÌNÞFV–@¨4*Xkoy™¾Î=ïíÚÈMú+÷–	:ÇÞæ ©ÜT¼·9½D(!}oé̦žÛµøO:x<·_ñܪ½M>·÷µ·çök[ÚWGs‚Úho×8S9¨ ŲΗcŒt9&Õ$àua9ßL´¹RÆF-»a7*•ºaµŒÖh#qÙ\_^œgÐÅ˜wK»mM`^¢écö5!uϝ˜€UC||×=…öÙQ*‘'•Ód‰¥Aãâo&¢÷rw‰ˆ ¸9׎š«¡ÍµCs54š7Ö[œ‘) 72Œ!úr\i¦lšÎø2†÷0pÍ^ÑEMð+îaù+ïaù®7lçnt
%L1ñZMÁÆæ>Ï
åp·¯G¹73MVY“Ì\´ ŽS-”㻳s»¼ÖË£[^w»Ê_y»ÖåÞ÷¶]Iü<×ù’lvû2©KDô_ÿú[ó@>ޗù6dõ¦Ý—÷¸‡÷åýݗI›û<§Ý—÷O›2൯¦çù÷aâwÇb§9sÓekã–`Sùà«QÉï/U=Ž‘jé	SÂ]ÿ
XsNJH1ÿä&¤_€uYHNGˆ_5ìî|­s–dñJ²Ì¬Íµ9ç]™ÊúƚÆ2î ^—«Ãú°Ý®Tj-s·Vomf.“ ×3˜ÉNd2k—ڦ؁­]Ýd–—~P®Œ·]¥`…ã	™3¶„;|iMGžpΧî܉åtáL„=a%[½×çøhoûÖô‡”°móvqۏV¼G­$cŠ_èmƒFŠ}´
~ë¶Áü‡sðž_ϝ…
g -ØÓ!V·.]X¢&6xÇG‰á.$†G;æ£Äp¿ãuô´Ž~µ;ëÑæúhsý¸Û£%×XÛ¶¹¾©òkqj;β”¯im¿•i}3ûðºÎ”kÔð4v}Ð^;GÂpzòjãÖÉ74	Ïï³s¿æ@_ÝÃß
=¹q‘?oEâCNìºʖwÈsí¹¯Šõ÷=Õ½Ùóáº$½©r§\û«	-k=f˜ø¾Úö¬ßÛîç7»=ºLùp·çvÏû_
·Ùö®
Í}]a>Δ­áíyäL›æîö|Kœ)ÙRõïدÌʾ1ÒO6ô<ÜíùæHÿÑ貖Ñe]Ÿ¼KÞÐÚmÔL³R5ë-{C—¼M<òt‡<£Ô48éËîcҗô瑄`é¸}~È
ïÀö'~üÞ
÷i~L|óL ‘bz»›“ð˜M珗•ã^j.­÷lø˜¢ç‘ìÃaóþ<r˜µ9̟:™Pœí¹á]lAúþ&åã[+¤k:
¬áШ֬ݑy€¸@s÷ÖŽ:[Á™Óž·óÐõÚ·]Ò­•ç@¯Í%s¾ö&«â÷Š‚u֛rɯBÁ]¼ÛçÆ_‚º¹
þÖÂÊý	WÙxÿ*ÂÕF®îyîQXɲi~å´ùÀÉêÐ&T}?Üæ~Rԋ{ހÇ°J\¿_¶²ÎV%#rÕñ¹cü­'’Rõ5g
#æ©—Ô%—`jX£a­_7q@M6­ß¾4ÜH“Kƒû,Rù¢“öšµZÊ|-Š¯öKг„/]ÛI¥ê¶F¼D
‡ŒwW€>³°€Ù­Á–¸r; ™ŒA=ˆ*6Ex £8@[ƒ¾åŒúcøxkÍ«}¤É¥k£`Ýõæ¿Öä[@SXoFÄ¢¯„Cgzüb¤ÏI³ûdßh£U¢ÄjηØ;žtöõ{_“Nçô	ÕN’¯ÌQ@­ŠF点œF­ÖzÔ¢ó
®Õ¡¢„Û"45Ù§àwÀGîk"ež˜¼‹r\”ɝr]•ÃºYo5ׯ¤š2¤nȹ}(Ç6þgÈ
Ifãzƒâu÷íÁ‘88;>ìôŽÄa÷Çî¡8ížt;½ÎëÃ.üÚÙˆFõhÆK(õò«n‚™*.Ä°^
&˜<q¨“Ϊ†uïu×YÉäkz\§íýüqï7ÝûyPC-{÷ï¥Àtþ­&G³?Í9×<ÔTn“ÖãÏxú}’øSÿ¯I¿+SØH,ùëʞ{ÖdMÉ(Ô/ŸpÔ²ÛÕfóVÂQxT=Öµu×ò‘â™æèOpH¾ruâƒAü’ŽL5¿í!A›[u4üßúÞðÂ-’‰2ÞNRy³ÙVÇf¥²Û4Ãn®t6N€”zڒsq½TÚ¯sµRìóB„ªš>	>TOÄ	™ê36´<›XÓò—œLþ4®›$}ãLõ¥4ý‘@ك/g‹Œ¯Ê¦úRú
”aÛçö•ûÉοwø¹=¯W Q5“;×n[í‘U©ƒa³]äß9Ðêó›â¾5šõRSìàr
Ÿ/§}{Ðø™×3Úäc%Jò”$ˆ’8C:öŒŠí'¢P(@Û
ðoÀÑК‚=¹[,§äS
qpƒÃLñø°2ž»—Â]\ØsÕ_ñȊüàù“ø9O–ÞEÑ[Œ€ã¢“
~6›ÃtÆø!7%±•eú÷tk›y ãógbϚ퉀…:ÏÀö%J74©Å…ã©ÉTp«ä=N….€Ä}Éê‘ï.kV-«:Ì{—eŽ§Ýb56‰ÿU|¼°§Â‹%00@ˆµ–;
Ÿò¡
ïm‰‰¿#2¥»
ñ.H²”GÓ¦fÒJ3¼°œéKød	äd)Î+; (
ăèlîmßuG
Ìi'ڂ‹·B÷«
Ó~²óۓ!öà*À|-"O/QÁú¤ç“Óƒ÷ÓŸñŽ)ÁçtŸàØs›$Z²c!€èóÍl¶°­ùȽžÊQ÷OO‚1U#IRbË3¶ä,…ßäÝ,¾Èë¾õ¶àc½¦¶þå¿L'¡]á¯Â,·tožv<þ¡ôcßpámñEü	»“ÔaB3Y%Šj³byŠÈªÍÌU›ëŽeFÆÊwJyÿʓšÞ+×imŽª#«Y]ï´fŒ©ŸØº<±1^N?9ö\àaCŒ»ãäKpÕù Q	I
‰/|D4±¾üŠÇ$ñœÅ¬IžÞÕ,ël2ò‘5ŸSóèy
†\§!í8d..>sb®53a~úJVXcôðªyz¼B†“§£ì2_»£ÑÜ`H3i̍9Å&|"?—°ÚõÖh·uk.ã
Sñˆ1bîN&xS,¸B-á-º,]öËÙùÜÁ…kÑEË7ü„Ç]z“„uaÃMM·°¼µ=¸š'xoã7•G6³ŠÍDM™³Ü‚SÈc7ÙàÀGÎû_×ëieÿ[0§Cê=µ!s÷”}æ¹&+‹£wåñžy'«÷ŒM6GOÙg”c™æ**J2½çªe&õÌ·Ìpϔefô”=’Wë)GÛC«z¦c(½ç*%õÌEzÇJê(»da	˜W>
 TzÕÍk,ow«56F³R±í±m´vWZwÒÀ­âP¨›h˜ÞáðA„—ádIR’)ÿb:’Ÿ
ºD”„“zÉö
®Ó+ À”^f¨sl†åbŒÌ\½’1˜Ø)XUæüÔëÍ/­Wæü´ùåJ6÷Œqð\¢ìcn
Nì´rƒóõù;¥np¸SÞ
Î×+s~y78±×ª
Î×)eƒý™%ìsú{¥Êuù:%#0Ü)¶ªìù©æF.®è”ïnJpØZuC¥tÉ¥šÖm«aå~:ÍP·^µ¤fz0×¾qXڝKšŽPóœ*¾bàšKjêÂ]/l´SÐ$·…³(!4ì‡Þ~sṗöÀ݈Å3ɗáF˜`€&ŒÓÖ"d.±–«ÔÛs6d*ؙâ'¥,ÞdŽ¶èÉWšÞJÂÓÇê½ê¯dw{ô=½åíÙ%ä·tÂQ£¤©{¤§K†m©£¶”ö¹ò©:nüŽ½Në¦mojÍ`WkÛ©…BK¹»•Ãj-Õà`I!í8É$Ÿöà­÷me›
S¤û3àF—£>™ÿ“ÕøÁ¯“w‚ÇS©<AÈÓ9U
Lë,9ã†C‡zÏ7籁ßÇ:l6Ü+ßSÁ°9lUs{ð®Sg¶æããÞ#|`<0W%ñÆ0yÎ?$?>ðÿc´2€šM

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-27 12:40  Kevin Grittner <Kevin.Grittner@wicourts.gov>
  0 siblings, 2 replies; 74+ messages in thread

From: Kevin Grittner @ 2012-06-27 12:40 UTC (permalink / raw)
  To: alvherre@commandprompt.com; +Cc: pgsql-hackers

Alvaro Herrera  wrote:
 
> here's fklocks v14, which also merges to new master as there were
> several other conflicts. It passes make installcheck-world now.
 
Recent commits broke it again, so here's a rebased v15.  (No changes
other than attempting to merge your work with the pg_controldata and
pg_resetxlog changes and wrapping that FIXME in a comment.)
 
Using that patch, pg_upgrade completes, but pg_dumpall fails:
 

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    delete_old_cluster.sh
+ pg_ctl start -l
/home/kevin/pg/master/contrib/pg_upgrade/log/postmaster2.log -w
waiting for server to start.... done
server started
+ pg_dumpall
pg_dump: Dumping the contents of table "hslot" failed: PQgetResult()
failed.
pg_dump: Error message from server: ERROR:  MultiXactId 115 does no
longer exist -- apparent wraparound
pg_dump: The command was: COPY public.hslot (slotname, hubname,
slotno, slotlink) TO stdout;
pg_dumpall: pg_dump failed on database "regression", exiting
+ pg_dumpall2_status=1
+ pg_ctl -m fast stop
waiting for server to shut down.... done
server stopped
+ [ -n 1 ]
+ echo pg_dumpall of post-upgrade database cluster failed
pg_dumpall of post-upgrade database cluster failed
+ exit 1
make[2]: *** [check] Error 1
make[2]: Leaving directory `/home/kevin/pg/master/contrib/pg_upgrade'
make[1]: *** [check-pg_upgrade-recurse] Error 2
make[1]: Leaving directory `/home/kevin/pg/master/contrib'
make: *** [check-world-contrib-recurse] Error 2


Did I merge it wrong?

-Kevin

Attachments:

  fklocks-15.patch.gz (application/octet-stream, 89.1K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-27 15:27  Alvaro Herrera <alvherre@commandprompt.com>
  parent: Kevin Grittner <Kevin.Grittner@wicourts.gov>
  1 sibling, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-06-27 15:27 UTC (permalink / raw)
  To: Kevin Grittner <kevin.grittner@wicourts.gov>; +Cc: pgsql-hackers


Excerpts from Kevin Grittner's message of mié jun 27 08:40:58 -0400 2012:
> Alvaro Herrera  wrote:
>  
> > here's fklocks v14, which also merges to new master as there were
> > several other conflicts. It passes make installcheck-world now.
>  
> Recent commits broke it again, so here's a rebased v15.  (No changes
> other than attempting to merge your work with the pg_controldata and
> pg_resetxlog changes and wrapping that FIXME in a comment.)

Oooh, so sorry -- I was supposed to have git-stashed that before
producing the patch.  This change cannot have caused the pg_dumpall
problem below though, because it only touched the multixact cache code.

> Using that patch, pg_upgrade completes, but pg_dumpall fails:

Hmm, something changed enough that requires more than just a code merge.
I'll look into it.

Thanks for the merge.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-29 23:17  Alvaro Herrera <alvherre@commandprompt.com>
  parent: Kevin Grittner <Kevin.Grittner@wicourts.gov>
  1 sibling, 3 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-06-29 23:17 UTC (permalink / raw)
  To: Kevin Grittner <kevin.grittner@wicourts.gov>; +Cc: pgsql-hackers


Excerpts from Kevin Grittner's message of mié jun 27 08:40:58 -0400 2012:
> Alvaro Herrera  wrote:
>  
> > here's fklocks v14, which also merges to new master as there were
> > several other conflicts. It passes make installcheck-world now.
>  
> Recent commits broke it again, so here's a rebased v15.  (No changes
> other than attempting to merge your work with the pg_controldata and
> pg_resetxlog changes and wrapping that FIXME in a comment.)

Here's v16, merged to latest stuff, before attempting to fix this:

> Using that patch, pg_upgrade completes, but pg_dumpall fails:

> + pg_ctl start -l
> /home/kevin/pg/master/contrib/pg_upgrade/log/postmaster2.log -w
> waiting for server to start.... done
> server started
> + pg_dumpall
> pg_dump: Dumping the contents of table "hslot" failed: PQgetResult()
> failed.
> pg_dump: Error message from server: ERROR:  MultiXactId 115 does no
> longer exist -- apparent wraparound

I was only testing migrating from an old version into patched, not
same-version upgrades.

I think I see what's happening here.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-06-29 23:26  Alvaro Herrera <alvherre@commandprompt.com>
  parent: Alvaro Herrera <alvherre@commandprompt.com>
  2 siblings, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-06-29 23:26 UTC (permalink / raw)
  To: Kevin Grittner <kevin.grittner@wicourts.gov>; +Cc: pgsql-hackers

Excerpts from Alvaro Herrera's message of vie jun 29 19:17:02 -0400 2012:
> Excerpts from Kevin Grittner's message of mié jun 27 08:40:58 -0400 2012:
> > Alvaro Herrera  wrote:
> >  
> > > here's fklocks v14, which also merges to new master as there were
> > > several other conflicts. It passes make installcheck-world now.
> >  
> > Recent commits broke it again, so here's a rebased v15.  (No changes
> > other than attempting to merge your work with the pg_controldata and
> > pg_resetxlog changes and wrapping that FIXME in a comment.)
> 
> Here's v16, merged to latest stuff,

Really attached now.

BTW you can get this on github:
https://github.com/alvherre/postgres/tree/fklocks

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachments:

  fklocks-16.patch.gz (application/x-gzip, 88.7K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-07-05 17:02  Alvaro Herrera <alvherre@commandprompt.com>
  parent: Alvaro Herrera <alvherre@commandprompt.com>
  2 siblings, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-07-05 17:02 UTC (permalink / raw)
  To: Kevin Grittner <kevin.grittner@wicourts.gov>; +Cc: pgsql-hackers


Excerpts from Alvaro Herrera's message of vie jun 29 19:17:02 -0400 2012:

> I was only testing migrating from an old version into patched, not
> same-version upgrades.
> 
> I think I see what's happening here.

Okay, I have pushed the fix to github -- as I suspected, code-wise the
fix was simple.  I will post an updated consolidated patch later today.

make check of pg_upgrade now passes for me.

It would be nice that "make installcheck" would notify me that some
modules' tests are being skipped ...

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-07-05 22:44  Alvaro Herrera <alvherre@commandprompt.com>
  parent: Alvaro Herrera <alvherre@commandprompt.com>
  2 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-07-05 22:44 UTC (permalink / raw)
  To: Kevin Grittner <kevin.grittner@wicourts.gov>; +Cc: pgsql-hackers


Updated patch attached.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachments:

  fklocks-17.patch.gz (application/x-gzip, 88.2K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-08-17 20:23  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@commandprompt.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-08-17 20:23 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Kevin Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers

Excerpts from Alvaro Herrera's message of jue jul 05 18:44:11 -0400 2012:
> 
> Updated patch attached.
> 

Patch rebased to latest sources.  This is also on Github:
https://github.com/alvherre/postgres/tree/fklocks


-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachments:

  fklocks-18.patch.gz (application/x-gzip, 91.8K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-08-22 21:31  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 2 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-08-22 21:31 UTC (permalink / raw)
  To: pgsql-hackers


Patch v19 contains some tweaks.  Most notably,

1. if an Xid requests a lock A, and then a lock B which is stronger than
A, then record only lock B and forget lock A.  This is important for
performance, because EvalPlanQual obtains ForUpdate locks on the tuples
that it chases on an update chain.  If EPQ was called by an update or
delete, previously a MultiXact was being created.

In a stock pgbench run this was causing lots of multis to be created,
even when there are no FKs.

This was most likely involved in the 9% performance decrease that was
previously reported.

2. Save a few TransactionIdIsInProgress calls in MultiXactIdWait.  We
were calling it to determine how many transactions were still running,
but not all callers were interested in that info.  XidIsInProgress is
not particularly cheap, so it seems good to skip it if possible.  I
didn't try to measure the difference, however.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachments:

  fklocks-19.patch.gz (application/x-gzip, 89.3K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-08-25 01:51  Robert Haas <robertmhaas@gmail.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 0 replies; 74+ messages in thread

From: Robert Haas @ 2012-08-25 01:51 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers

On Wed, Aug 22, 2012 at 5:31 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Patch v19 contains some tweaks.  Most notably,
>
> 1. if an Xid requests a lock A, and then a lock B which is stronger than
> A, then record only lock B and forget lock A.  This is important for
> performance, because EvalPlanQual obtains ForUpdate locks on the tuples
> that it chases on an update chain.  If EPQ was called by an update or
> delete, previously a MultiXact was being created.
>
> In a stock pgbench run this was causing lots of multis to be created,
> even when there are no FKs.
>
> This was most likely involved in the 9% performance decrease that was
> previously reported.

Ah-ha!  Neat.  I'll try to find some time to re-benchmark this during
the next CF, unless you did that already.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-08-27 19:28  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-08-27 19:28 UTC (permalink / raw)
  To: pgsql-hackers

Excerpts from Alvaro Herrera's message of mié ago 22 17:31:28 -0400 2012:
> 
> Patch v19 contains some tweaks.  Most notably,

v20 is merged to latest master; the only change other than automatic
merge is to update for pg_upgrade API fixes.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachments:

  fklocks-20.patch.gz (application/x-gzip, 89.3K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-08-31 04:59  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 2 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-08-31 04:59 UTC (permalink / raw)
  To: pgsql-hackers

v21 is merged to latest master.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachments:

  fklocks-21.patch.gz (application/x-gzip, 93.1K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-11 15:36  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 1 reply; 74+ messages in thread

From: Andres Freund @ 2012-10-11 15:36 UTC (permalink / raw)
  To: pgsql-hackers; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>

On Friday, August 31, 2012 06:59:51 AM Alvaro Herrera wrote:
> v21 is merged to latest master.
Ok, I am starting to look at this.

(working with a git merge of alvherre/fklocks into todays master)

In a very first pass as somebody who hasn't followed the discussions in the 
past I took notice of the following things:

* compiles and survives make check
* README.tuplock jumps in quite fast without any introduction

* the reasons for the redesign aren't really included in the patch but just in 
the - very nice - pgcon paper.

* "This is a bit of a performance regression, but since we expect FOR SHARE 
locks to be seldom used, we don’t feel this is a serious problem." makes me a 
bit uneasy, will look at performance separately

* Should RelationGetIndexattrBitmap check whether a unique index is referenced 
from a pg_constraint row? Currently we pay part of the overhead independent 
from the existance of foreign keys.

* mode == LockTupleKeyShare, == LockTupleShare, == LockTupleUpdate in 
heap_lock_tuple's BeingUpdated branch look like they should be an if/else if

* I don't really like HEAP_UPDATE_KEY_REVOKED as a name, what about 
HEAP_KEYS_UPDATED (akin to HEAP_HOT_UPDATED)

* how can we get infomask2 & HEAP_UPDATE_KEY_REVOKED && infomask & 
HEAP_XMAX_LOCK_ONLY?

* heap_lock_tuple with mode == LockTupleKeyShare && nowait looks like it would 
wait anyway in heap_lock_updated_tuple_rec

* rename HeapSatisfiesHOTUpdate, adjust comments?

* I wonder whether HeapSatisfiesHOTUpdate could be made to compute the result 
for key_attrs and hot_attrs at the same time, often enough they will do the 
same thing on the same column

* you didn't start it but I find that all those l$i jump labels make the code 
harder to follow

* shouldn't XmaxGetUpdateXid be rather called MultiXactIdGetUpdateXid or such? 

*
		/*
		 * If the existing lock mode is identical to or weaker than the new
		 * one, we can act as though there is no existing lock and have the
		 * upper block handle this.
		 */
"block"?

* I am not yet sure whether the (xmax == add_to_xmax) optimization in 
compute_new_xmax_infomask is actually safe

* ConditionalMultiXactIdWait and MultiXactIdWait should probably rely on a 
common implementation

* I am not that convinced that moving the waiting functions away from 
multixact.c is a good idea, but I guess the required knowledge about lockmodes 
makes it hard not to do so

* Haven't looked yet, but I have a slightly uneasy feeling about Hot Standby 
interactions. Did you look at that?

* Hm?
HeapTupleSatisfiesVacuum
#if 0
				ResetMultiHintBit(tuple, buffer, xmax, true);
#endif

This obviously is not a real review, but just learning what the problem & patch 
actually try to do. This is quite a bit to take in ;). I will let it sink in 
ant try to have a look at the architecture and performance next.


Greetings,

Andres

.oO(and people call catalog timetravel complicated)

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-11 16:10  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-10-11 16:10 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>

Andres Freund wrote:
> On Friday, August 31, 2012 06:59:51 AM Alvaro Herrera wrote:
> > v21 is merged to latest master.
> Ok, I am starting to look at this.
> 
> (working with a git merge of alvherre/fklocks into todays master)
> 
> In a very first pass as somebody who hasn't followed the discussions in the 
> past I took notice of the following things:
> 
> * compiles and survives make check

Please verify src/test/isolation's make installcheck as well.

> * README.tuplock jumps in quite fast without any introduction

Hmm .. I'll give that a second look.  Maybe some material from the pgcon
paper should be added as introduction.

> * "This is a bit of a performance regression, but since we expect FOR SHARE 
> locks to be seldom used, we don’t feel this is a serious problem." makes me a 
> bit uneasy, will look at performance separately

Thanks.  Keep in mind though that the bits we really want good
performance for is FOR KEY SHARE, which is going to be used in foreign
keys.  FOR SHARE is staying just for hypothetical backwards
compatibility.  I just found that people is using it, see for example
http://stackoverflow.com/a/3243083

> * Should RelationGetIndexattrBitmap check whether a unique index is referenced 
> from a pg_constraint row? Currently we pay part of the overhead independent 
> from the existance of foreign keys.

Noah also suggested something more or less in the along the same lines.
My answer is that I don't want to do it currently; maybe we can improve
on what indexes we use later, but since this can be seen as a modularity
violation, I prefer to keep it as simple as possible.

> * mode == LockTupleKeyShare, == LockTupleShare, == LockTupleUpdate in 
> heap_lock_tuple's BeingUpdated branch look like they should be an if/else if

Hm, will look at that.

> * I don't really like HEAP_UPDATE_KEY_REVOKED as a name, what about 
> HEAP_KEYS_UPDATED (akin to HEAP_HOT_UPDATED)

Thanks.

> * how can we get infomask2 & HEAP_UPDATE_KEY_REVOKED && infomask & 
> HEAP_XMAX_LOCK_ONLY?

SELECT FOR KEY UPDATE?  This didn't exist initially, but previous
reviewers (Noah) felt that it made sense to have it for consistency.  It
makes the lock conflict table make more sense, anyway.

> * heap_lock_tuple with mode == LockTupleKeyShare && nowait looks like it would 
> wait anyway in heap_lock_updated_tuple_rec

Oops.

> * rename HeapSatisfiesHOTUpdate, adjust comments?

Yeah.

> * I wonder whether HeapSatisfiesHOTUpdate could be made to compute the result 
> for key_attrs and hot_attrs at the same time, often enough they will do the 
> same thing on the same column

Hmm, I will look at that.

> * you didn't start it but I find that all those l$i jump labels make the code 
> harder to follow

You mean you suggest to have them renamed?  That can be arranged.

> * shouldn't XmaxGetUpdateXid be rather called MultiXactIdGetUpdateXid or such? 

Yes.

> 		/*
> 		 * If the existing lock mode is identical to or weaker than the new
> 		 * one, we can act as though there is no existing lock and have the
> 		 * upper block handle this.
> 		 */
> "block"?

Yeah, as in "the if {} block above".  Since this is not clear maybe it
needs rewording.

> * I am not yet sure whether the (xmax == add_to_xmax) optimization in 
> compute_new_xmax_infomask is actually safe

Will think about it and add a/some comment(s).

> * ConditionalMultiXactIdWait and MultiXactIdWait should probably rely on a 
> common implementation

Will look at that.

> * I am not that convinced that moving the waiting functions away from 
> multixact.c is a good idea, but I guess the required knowledge about lockmodes 
> makes it hard not to do so

Yeah.  The line between multixact.c and heapam.c is a zigzag currently,
I think.  Maybe it needs to be more clear; I think the multixact modes
really belong into heapam.c, and they are just uint32 to multixact.c.  I
wasn't brave enough to attempt this; maybe I should.

> * Haven't looked yet, but I have a slightly uneasy feeling about Hot Standby 
> interactions. Did you look at that?
> 
> * Hm?
> HeapTupleSatisfiesVacuum
> #if 0
> 				ResetMultiHintBit(tuple, buffer, xmax, true);
> #endif

Yeah.  I had a couple of ResetMultiHintBit calls sprinkled in some of
the tqual routines, with the idea that if they saw multis that were no
longer live they could be removed, and replaced by just the remaining
updater.  However, this doesn't really work because it's not safe to
change the Xmax when not holding exclusive lock, and the tqual routines
don't know that.  So we're stuck with keeping the multi in there, even
when we know they are no longer interesting.  This is a bit sad, because
it would be a performance benefit to remove them; but it's not strictly
necessary for correctness, so we can leave the optimization for a later
phase.  I let those #ifdefed out calls in place so that it's easy to see
where the reset needs to happen.


> This obviously is not a real review, but just learning what the problem & patch 
> actually try to do. This is quite a bit to take in ;). I will let it sink in 
> ant try to have a look at the architecture and performance next.

Well, the patch is large and complex so any review is obviously going to
take a long time.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-12 21:09  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-10-12 21:09 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers

Alvaro Herrera wrote:
> Andres Freund wrote:

> > * heap_lock_tuple with mode == LockTupleKeyShare && nowait looks like it would 
> > wait anyway in heap_lock_updated_tuple_rec
> 
> Oops.

I took a stab at fixing this.  However, it is not easy.  First you need
a way to reproduce the problem, which involves setting breakpoints in
GDB.  (Since a REPEATABLE READ transaction will fail to follow an update
chain due to "tuple concurrently updated", you need to use a READ
COMMITTED transaction; but obviously the timing to insert the bunch of
updates in the middle is really short.  Hence I inserted a breakpoint at
the end of GetSnapshotData, had a SELECT FOR KEY SHARE NOWAIT get stuck
in it, and then launched a couple of updates in another session).  I was
able to reproduce the undesirable wait.

I quickly patched heap_lock_updated_tuple to pass down the nowait flag,
but this is actually not reached, because the update chain is first
followed by EvalPlanQual in ExecLockRows, and not by
heap_lock_updated_tuple directly.  And EPQ does not have the nowait
behavior.  So it still blocks.

Maybe what we need to do is prevent ExecLockRows from following the
update chain altogether -- after all, if heap_lock_tuple is going to do
it by itself maybe it's wholly redundant.

Not really sure what's the best way to approach this.  At this stage I'm
inclined to ignore the problem, unless some EPQ expert shows up and
tells me that (1) it's okay to patch EPQ in that way, or (2) we should
hack ExecLockRows (and remove EPQ?).


I pushed (to github) patches for a couple of other issues you raised.
Some others still need a bit more of my attention.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-18 19:58  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 2 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-10-18 19:58 UTC (permalink / raw)
  To: pgsql-hackers

Here is version 22 of this patch.  This version contains fixes to issues
reported by Andres, as well as a rebase to latest master.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachments:

  fklocks-22.patch.gz (application/octet-stream, 95.1K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-19 15:40  Noah Misch <noah@leadboat.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 0 replies; 74+ messages in thread

From: Noah Misch @ 2012-10-19 15:40 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers

On Thu, Oct 18, 2012 at 04:58:20PM -0300, Alvaro Herrera wrote:
> Here is version 22 of this patch.  This version contains fixes to issues
> reported by Andres, as well as a rebase to latest master.

I scanned this for obvious signs of work left to do.  It contains numerous XXX
and FIXME comments.  Many highlight micro-optimization opportunities and the
like; those can stay.  Others preclude commit, either highlighting an unsolved
problem or wrongly highlighting a non-problem:

> + 	/*
> + 	 * XXX we do not lock this tuple here; the theory is that it's sufficient
> + 	 * with the buffer lock we're about to grab.  Any other code must be able
> + 	 * to cope with tuple lock specifics changing while they don't hold buffer
> + 	 * lock anyway.
> + 	 */

>    * so they will be uninteresting by the time our next transaction starts.
>    * (XXX not clear that this is correct --- other members of the MultiXact
>    * could hang around longer than we did.  However, it's not clear what a
> !  * better policy for flushing old cache entries would be.)  FIXME actually
> !  * this is plain wrong now that multixact's may contain update Xids.

> ! 	nmembers = GetMultiXactIdMembers(multi, &members, true);
> ! 	/*
> ! 	 * XXX we don't have the infomask to run the required consistency check
> ! 	 * here; the required notational overhead seems excessive.
> ! 	 */

>   		/* We assume the cache entries are sorted */
> ! 		/* XXX we assume the unused bits in "status" are zeroed */
> ! 		if (memcmp(members, entry->members, nmembers * sizeof(MultiXactMember)) == 0)

> !  * XXX do we have any issues with needing to checkpoint here?
>    */
> ! static void
> ! TruncateMultiXact(void)
>   {

> + 	/* FIXME what should we initialize this to? */
> + 	newFrozenMulti = ReadNextMultiXactId();

> + 	 * FIXME -- the XMAX_IS_MULTI test is a bit wrong .. it's possible to
> + 	 * have tuples with that bit set that are dead.  However, if that's
> + 	 * changed, the RawXmax() call below should probably be researched as well.
>   	 */
>   	if (tuple->t_infomask &
> ! 		(HEAP_XMAX_INVALID | HEAP_XMAX_LOCK_ONLY | HEAP_XMAX_IS_MULTI))
>   		return false;




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-26 22:06  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 2 replies; 74+ messages in thread

From: Andres Freund @ 2012-10-26 22:06 UTC (permalink / raw)
  To: pgsql-hackers; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>

On Thursday, October 18, 2012 09:58:20 PM Alvaro Herrera wrote:
> Here is version 22 of this patch.  This version contains fixes to issues
> reported by Andres, as well as a rebase to latest master.

Ok, I now that pgconf.eu has ended I am starting to do a real review:

* Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2 and earlier 
you could be sure that if you FOR UPDATE'ed a row you could delete it. Unless 
I miss something now this will not block somebody else acquiring a FOR KEY 
SHARE lock, so this guarantee is gone.
This seems likely to introduce subtle problems in user applications.

I propose renaming FOR UPDATE => FOR NO KEY UPDATE, FOR KEY UPDATE => FOR 
UPDATE or similar (or PREVENT KEY UPDATE?). That keeps the old meaning of FOR 
UPDATE.

You write "SELECT FOR UPDATE is a standards-compliant exclusive lock". I 
didn't really find all that much about the semantics of FOR UPDATE on cursors 
in the standard other than "The operations of update and delete are permitted 
for updatable cursors, subject to constraining Access Rules.". 

* I would welcome adding some explanatory comments about the point of 
TupleLockExtraInfo and MultiXactStatusLock at the respective definition.

* Why do we have the HEAP_XMAX_IS_MULTI && HEAP_XMAX_LOCK_ONLY case?

* I think some of the longer comments could use the attention of a native 
speaker, unfortunately thats not me.

* I am still uncomfortable with the FOR SHARE deoptimization. I have seen 
people lock larger parts of their table to make some READ COMMITTED things 
actually safe.
Is there any problem retaining the non XMAX_IS_MULTI behaviour except space in 
infomask? That seems solveable by something like

#define HEAP_XMAX_SHR_LOCK     0x0010
#define HEAP_XMAX_EXCL_LOCK		0x0040
#define HEAP_XMAX_KEYSHR_LOCK   (HEAP_XMAX_SHR_LOCK  | HEAP_XMAX_EXCL_LOCK)

and somewhat more complex expressions when testing the locks ((infomask & 
HEAP_XMAX_KEYSHR_LOCK ) == HEAP_XMAX_KEYSHR_LOCK, etc).

* In heap_lock_tuple's  XMAX_IS_MULTI case

			for (i = 0; i < nmembers; i++)
			{
				if (TransactionIdIsCurrentTransactionId(members[i].xid))
				{
					LockTupleMode	membermode;

					membermode = 
TUPLOCK_from_mxstatus(members[i].status);

					if (membermode > mode)
					{
						if (have_tuple_lock)
							UnlockTupleTuplock(relation, tid, mode);

						pfree(members);
						return HeapTupleMayBeUpdated;
					}
				}
			}

why is it membermode > mode and not membermode >= mode?

* Is the case of a a non-key-update followed by a key-update actually handled 
when doing a heap_lock_tuple with mode = LockTupleKeyShare and follow_updates 
= false? I don't really see how, so it seems to deserve at least a comment.

But then I don't yet understand why follow_update makes sense.

* In heap_lock_tuple with mode == LockTupleUpdate && infomask & 
HEAP_XMAX_IS_MULTI, were leaking members when doing goto l3. Probably not 
relevant, but given the code tries to be careful everywhere else...
We might also leak in the members == 0 case there, not sure yet.

Ok, this is at about 35% of the diff in my second pass, but I just arrived back 
in Berlin, and this seems useful enough on its own...

Andres
-- 
Andres Freund		http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-28 22:47  Simon Riggs <simon@2ndQuadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  1 sibling, 1 reply; 74+ messages in thread

From: Simon Riggs @ 2012-10-28 22:47 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>

On 27 October 2012 00:06, Andres Freund <andres@2ndquadrant.com> wrote:
> On Thursday, October 18, 2012 09:58:20 PM Alvaro Herrera wrote:
>> Here is version 22 of this patch.  This version contains fixes to issues
>> reported by Andres, as well as a rebase to latest master.
>
> Ok, I now that pgconf.eu has ended I am starting to do a real review:
>
> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2 and earlier
> you could be sure that if you FOR UPDATE'ed a row you could delete it. Unless
> I miss something now this will not block somebody else acquiring a FOR KEY
> SHARE lock, so this guarantee is gone.

Yes, that is exactly the point of this.

> This seems likely to introduce subtle problems in user applications.

Yes, it could. So we need some good docs on explaining this.

Which applications use FOR UPDATE?
Any analysis of particular situations would be very helpful in doing
the correct thing here.

I think introducing FOR DELETE would be much clearer as an addition/
synonym for FOR KEY UPDATE.


> I propose renaming FOR UPDATE => FOR NO KEY UPDATE, FOR KEY UPDATE => FOR
> UPDATE or similar (or PREVENT KEY UPDATE?). That keeps the old meaning of FOR
> UPDATE.

Which is essentially unwinding the feature, to some extent.

Does FOR UPDATE throw an error if the user later issues an UPDATE of
the PK or a DELETE? That sequence of actions would cause lock
escalation in the application, which could also lead to
deadlock/contention.

This sounds like we need a GUC or table-level default to control
whether FOR UPDATE means FOR UPDATE or FOR DELETE

More thought/input required on this point, it seems important.


> You write "SELECT FOR UPDATE is a standards-compliant exclusive lock". I
> didn't really find all that much about the semantics of FOR UPDATE on cursors
> in the standard other than "The operations of update and delete are permitted
> for updatable cursors, subject to constraining Access Rules.".

> * I think some of the longer comments could use the attention of a native
> speaker, unfortunately thats not me.



-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-29 11:27  Andres Freund <andres@2ndquadrant.com>
  parent: Simon Riggs <simon@2ndQuadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Andres Freund @ 2012-10-29 11:27 UTC (permalink / raw)
  To: Simon Riggs <simon@2ndquadrant.com>; +Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>

On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote:
> On 27 October 2012 00:06, Andres Freund <andres@2ndquadrant.com> wrote:
> > On Thursday, October 18, 2012 09:58:20 PM Alvaro Herrera wrote:
> >> Here is version 22 of this patch.  This version contains fixes to issues
> >> reported by Andres, as well as a rebase to latest master.
> > 
> > Ok, I now that pgconf.eu has ended I am starting to do a real review:
> > 
> > * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2 and
> > earlier you could be sure that if you FOR UPDATE'ed a row you could
> > delete it. Unless I miss something now this will not block somebody else
> > acquiring a FOR KEY SHARE lock, so this guarantee is gone.
> 
> Yes, that is exactly the point of this.

Yes, sure. The point is the introduction of a weaker lock level which can be 
used by the ri triggers. I don't see any imperative that the semantics of the 
old lock level need to be redefined. That just seems dangerous to me.

We need to take care to reduce the complications of upgrades not introduce 
changes that require complex code reviews.

> > This seems likely to introduce subtle problems in user applications.
> 
> Yes, it could. So we need some good docs on explaining this.
> 
> Which applications use FOR UPDATE?

Any that want to protect themselves against deadlocks and/or visibility 
problems due to READ COMMITTED. Thats quite a bunch.

> Any analysis of particular situations would be very helpful in doing
> the correct thing here.

Usual things include

* avoiding problems due to lock upgrades in combination with foreign keys (as 
far as I can see some of those still persist).
* prevent rows being deleted by other transactions
* prepare for updating if computation of the new values take some time
* guarantee order of locking to make sure rows are DELETE/UPDATEed in the same 
order (still no ORDER BY in UPDATE/DELETE)
...

> I think introducing FOR DELETE would be much clearer as an addition/
> synonym for FOR KEY UPDATE.

Hm. Not really convinced. For me that seems to just make the overall situation 
even more complex.

> > I propose renaming FOR UPDATE => FOR NO KEY UPDATE, FOR KEY UPDATE => FOR
> > UPDATE or similar (or PREVENT KEY UPDATE?). That keeps the old meaning of
> > FOR UPDATE.
> 
> Which is essentially unwinding the feature, to some extent.

Why? The overall features available are just the same? The only thing is that 
existing semantics aren't changed.

> Does FOR UPDATE throw an error if the user later issues an UPDATE of
> the PK or a DELETE? That sequence of actions would cause lock
> escalation in the application, which could also lead to
> deadlock/contention.

Unless I miss something it precisely does *not* result in lock escalation with 
the 9.2 semanticsbut it *would* with fklocks applied. Thats exactly my point.

> This sounds like we need a GUC or table-level default to control
> whether FOR UPDATE means FOR UPDATE or FOR DELETE

I don't like adding a new guc for something that should be solveable with some 
creative naming. If a new user doesn't get a bit more concurrency due to 
manually issued 9.2 FOR UPDATE implicitly being converted into a FOR NO KEY 
UPDATE its not too bad. The code needs to be checked whether thats valid 
anyway. The reverse is not true...

> More thought/input required on this point, it seems important.

Yep, more input welcome.

Greetings,

Andres
-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-29 12:08  Simon Riggs <simon@2ndQuadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 0 replies; 74+ messages in thread

From: Simon Riggs @ 2012-10-29 12:08 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>

On 29 October 2012 12:27, Andres Freund <andres@2ndquadrant.com> wrote:

>> This sounds like we need a GUC or table-level default to control
>> whether FOR UPDATE means FOR UPDATE or FOR DELETE
>
> I don't like adding a new guc for something that should be solveable with some
> creative naming. If a new user doesn't get a bit more concurrency due to
> manually issued 9.2 FOR UPDATE implicitly being converted into a FOR NO KEY
> UPDATE its not too bad. The code needs to be checked whether thats valid
> anyway. The reverse is not true...

The main point here is that introducing new non-optional behaviour is
a compatibility problem and we shouldn't rush that.

If we decide to change FOR UPDATE to mean FOR NO KEY UPDATE that needs
separate consideration and shouldn't happen until sometime after the
feature goes in (months, or perhaps releases).

We're introducing a new feature that will allow us to avoid lock
problems, by taking the current FOR UPDATE behaviour and splitting it
into two options: one weaker and one stronger. We need explicit names
for both of those options. The most obvious naming is
FOR [[NO] KEY] UPDATE

Don't much like that, but its pretty unambiguous and fairly neat.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-29 12:18  Kevin Grittner <kgrittn@mail.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Kevin Grittner @ 2012-10-29 12:18 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; Simon Riggs <simon@2ndquadrant.com>; +Cc: pgsql-hackers@postgresql.org,"Alvaro Herrera" <alvherre@2ndquadrant.com>

Andres Freund wrote:
> On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote:
>> Andres Freund <andres@2ndquadrant.com> wrote:

>>> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2
>>> and earlier you could be sure that if you FOR UPDATE'ed a row you
>>> could delete it. Unless I miss something now this will not block
>>> somebody else acquiring a FOR KEY SHARE lock, so this guarantee
>>> is gone.
>> 
>> Yes, that is exactly the point of this.
> 
> The point is the introduction of a weaker lock level which can be 
> used by the ri triggers. I don't see any imperative that the
> semantics of the old lock level need to be redefined. That just
> seems dangerous to me.

I agree with Andres here -- the new lock level is needed within RI
triggers, and we might as well expose it for application programmer
use (with proper documentations), but there's no reason to break
existing application code by making the semantics of SELECT FOR
UPDATE less strict than they were before. Let's keep that term
meaning exactly the same thing if we can, and use new names for the
new levels.

We already present a barrier to people migrating from Oracle because
SELECT FOR UPDATE in PostgreSQL is weaker than it is in Oracle (where
it is just as strong as if an actual UPDATE were done -- write
conflicts and all); let's not increase the barrier by making SELECT
FOR UPDATE even weaker.

-Kevin




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-31 19:35  Noah Misch <noah@leadboat.com>
  parent: Kevin Grittner <kgrittn@mail.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Noah Misch @ 2012-10-31 19:35 UTC (permalink / raw)
  To: Kevin Grittner <kgrittn@mail.com>; +Cc: Andres Freund <andres@2ndquadrant.com>; Simon Riggs <simon@2ndquadrant.com>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>

On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote:
> Andres Freund wrote:
> > On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote:
> >> Andres Freund <andres@2ndquadrant.com> wrote:
> 
> >>> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2
> >>> and earlier you could be sure that if you FOR UPDATE'ed a row you
> >>> could delete it. Unless I miss something now this will not block
> >>> somebody else acquiring a FOR KEY SHARE lock, so this guarantee
> >>> is gone.
> >> 
> >> Yes, that is exactly the point of this.
> > 
> > The point is the introduction of a weaker lock level which can be 
> > used by the ri triggers. I don't see any imperative that the
> > semantics of the old lock level need to be redefined. That just
> > seems dangerous to me.
> 
> I agree with Andres here -- the new lock level is needed within RI
> triggers, and we might as well expose it for application programmer
> use (with proper documentations), but there's no reason to break
> existing application code by making the semantics of SELECT FOR
> UPDATE less strict than they were before. Let's keep that term
> meaning exactly the same thing if we can, and use new names for the
> new levels.

+1.  I had not considered this angle during previous reviews, but I agree with
Andres's position.  Since this patch does not strengthen the strongest tuple
lock relative to its PostgreSQL 9.2 counterpart, that lock type should
continue to use the syntax "FOR UPDATE".  It will come to mean "the lock type
sufficient for all possible UPDATEs of the row".




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-31 20:02  Simon Riggs <simon@2ndQuadrant.com>
  parent: Noah Misch <noah@leadboat.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Simon Riggs @ 2012-10-31 20:02 UTC (permalink / raw)
  To: Noah Misch <noah@leadboat.com>; +Cc: Kevin Grittner <kgrittn@mail.com>; Andres Freund <andres@2ndquadrant.com>; pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>

On 31 October 2012 19:35, Noah Misch <noah@leadboat.com> wrote:
> On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote:
>> Andres Freund wrote:
>> > On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote:
>> >> Andres Freund <andres@2ndquadrant.com> wrote:
>>
>> >>> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2
>> >>> and earlier you could be sure that if you FOR UPDATE'ed a row you
>> >>> could delete it. Unless I miss something now this will not block
>> >>> somebody else acquiring a FOR KEY SHARE lock, so this guarantee
>> >>> is gone.
>> >>
>> >> Yes, that is exactly the point of this.
>> >
>> > The point is the introduction of a weaker lock level which can be
>> > used by the ri triggers. I don't see any imperative that the
>> > semantics of the old lock level need to be redefined. That just
>> > seems dangerous to me.
>>
>> I agree with Andres here -- the new lock level is needed within RI
>> triggers, and we might as well expose it for application programmer
>> use (with proper documentations), but there's no reason to break
>> existing application code by making the semantics of SELECT FOR
>> UPDATE less strict than they were before. Let's keep that term
>> meaning exactly the same thing if we can, and use new names for the
>> new levels.
>
> +1.  I had not considered this angle during previous reviews, but I agree with
> Andres's position.  Since this patch does not strengthen the strongest tuple
> lock relative to its PostgreSQL 9.2 counterpart, that lock type should
> continue to use the syntax "FOR UPDATE".  It will come to mean "the lock type
> sufficient for all possible UPDATEs of the row".

So we have syntax

FOR NON KEY UPDATE
FOR KEY UPDATE

KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-31 20:22  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Simon Riggs <simon@2ndQuadrant.com>
  0 siblings, 2 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-10-31 20:22 UTC (permalink / raw)
  To: Simon Riggs <simon@2ndQuadrant.com>; +Cc: Noah Misch <noah@leadboat.com>; Kevin Grittner <kgrittn@mail.com>; Andres Freund <andres@2ndquadrant.com>; pgsql-hackers

Simon Riggs wrote:
> On 31 October 2012 19:35, Noah Misch <noah@leadboat.com> wrote:
> > On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote:
> >> Andres Freund wrote:

> >> > The point is the introduction of a weaker lock level which can be
> >> > used by the ri triggers. I don't see any imperative that the
> >> > semantics of the old lock level need to be redefined. That just
> >> > seems dangerous to me.
> >>
> >> I agree with Andres here -- the new lock level is needed within RI
> >> triggers, and we might as well expose it for application programmer
> >> use (with proper documentations), but there's no reason to break
> >> existing application code by making the semantics of SELECT FOR
> >> UPDATE less strict than they were before. Let's keep that term
> >> meaning exactly the same thing if we can, and use new names for the
> >> new levels.
> >
> > +1.  I had not considered this angle during previous reviews, but I agree with
> > Andres's position.  Since this patch does not strengthen the strongest tuple
> > lock relative to its PostgreSQL 9.2 counterpart, that lock type should
> > continue to use the syntax "FOR UPDATE".  It will come to mean "the lock type
> > sufficient for all possible UPDATEs of the row".

Yeah, I agree with this too.

> So we have syntax
> 
> FOR NON KEY UPDATE
> FOR KEY UPDATE
> 
> KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE

Not really sure about the proposed syntax, but yes clearly we need some
other syntax to mean "FOR NON KEY UPDATE".  I would rather keep FOR
UPDATE to mean what I currently call FOR KEY UPDATE.  More proposals for
the other (weaker) lock level welcome (but if you love FOR NON KEY
UPDATE, please chime in too)

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-10-31 21:01  Noah Misch <noah@leadboat.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 2 replies; 74+ messages in thread

From: Noah Misch @ 2012-10-31 21:01 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Simon Riggs <simon@2ndQuadrant.com>; Kevin Grittner <kgrittn@mail.com>; Andres Freund <andres@2ndquadrant.com>; pgsql-hackers

On Wed, Oct 31, 2012 at 05:22:10PM -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On 31 October 2012 19:35, Noah Misch <noah@leadboat.com> wrote:
> > > +1.  I had not considered this angle during previous reviews, but I agree with
> > > Andres's position.  Since this patch does not strengthen the strongest tuple
> > > lock relative to its PostgreSQL 9.2 counterpart, that lock type should
> > > continue to use the syntax "FOR UPDATE".  It will come to mean "the lock type
> > > sufficient for all possible UPDATEs of the row".
> 
> Yeah, I agree with this too.
> 
> > So we have syntax
> > 
> > FOR NON KEY UPDATE
> > FOR KEY UPDATE
> > 
> > KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE
> 
> Not really sure about the proposed syntax, but yes clearly we need some
> other syntax to mean "FOR NON KEY UPDATE".  I would rather keep FOR
> UPDATE to mean what I currently call FOR KEY UPDATE.  More proposals for
> the other (weaker) lock level welcome (but if you love FOR NON KEY
> UPDATE, please chime in too)

Agree on having "FOR UPDATE" without any "FOR KEY UPDATE" synonym.  For the
weaker lock, I mildly preferred the proposal of "FOR NO KEY UPDATE".  NON KEY
captures the idea better in English, but NO is close enough and already part
of the SQL lexicon.




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-05 13:37  Alvaro Herrera <alvherre@alvh.no-ip.org>
  parent: Noah Misch <noah@leadboat.com>
  1 sibling, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-05 13:37 UTC (permalink / raw)
  To: pgsql-hackers

FWIW I have gotten a lot of feedback about this patch, and since I don't
have time right now to produce an updated version, that I'm going to
close this as Returned with Feedback, and submit an updated version to
the upcoming commitfest.

This patch still needs much more review -- for example, as far as I
know, the multixact.c changes have gone largely unreviewed; they have
changed somewhat since Noah reviewed them (back in version 15 or so, I
think).  Of course, to me it all makes sense, but then I'm only its
author.

-- 
Alvaro Herrera                         http://www.flickr.com/photos/alvherre/
"Everybody understands Mickey Mouse. Few understand Hermann Hesse.
Hardly anybody understands Einstein. And nobody understands Emperor Norton."




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-05 13:48  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@alvh.no-ip.org>
  0 siblings, 0 replies; 74+ messages in thread

From: Andres Freund @ 2012-11-05 13:48 UTC (permalink / raw)
  To: pgsql-hackers; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>

On Monday, November 05, 2012 02:37:15 PM Alvaro Herrera wrote:
> FWIW I have gotten a lot of feedback about this patch, and since I don't
> have time right now to produce an updated version, that I'm going to
> close this as Returned with Feedback, and submit an updated version to
> the upcoming commitfest.
> 
> This patch still needs much more review -- for example, as far as I
> know, the multixact.c changes have gone largely unreviewed; they have
> changed somewhat since Noah reviewed them (back in version 15 or so, I
> think).  Of course, to me it all makes sense, but then I'm only its
> author.

There also hasn't been any recent performance testing. I am not sure if I can 
get the time to do so before the next commitfest...

Andres
-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-05 22:22  Dimitri Fontaine <dimitri@2ndQuadrant.fr>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 0 replies; 74+ messages in thread

From: Dimitri Fontaine @ 2012-11-05 22:22 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Simon Riggs <simon@2ndQuadrant.com>; Noah Misch <noah@leadboat.com>; Kevin Grittner <kgrittn@mail.com>; Andres Freund <andres@2ndquadrant.com>; pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> FOR NON KEY UPDATE
>> FOR KEY UPDATE
>> 
>> KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE
>
> Not really sure about the proposed syntax, but yes clearly we need some
> other syntax to mean "FOR NON KEY UPDATE".  I would rather keep FOR
> UPDATE to mean what I currently call FOR KEY UPDATE.  More proposals for
> the other (weaker) lock level welcome (but if you love FOR NON KEY
> UPDATE, please chime in too)

FOR ANY UPDATE, synonym of FOR UPDATE
FOR KEY UPDATE, optimized version, when it applies to your case

I also tend to think that we should better not change the current
meaning of FOR UPDATE and have it default to FOR ANY UPDATE.

Unless it's easy to upgrade from ANY to KEY, and do that automatically
at the right time, but I fear there lie dragons (or something).

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-13 22:07  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Noah Misch <noah@leadboat.com>
  1 sibling, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-13 22:07 UTC (permalink / raw)
  To: Noah Misch <noah@leadboat.com>; +Cc: Simon Riggs <simon@2ndQuadrant.com>; Kevin Grittner <kgrittn@mail.com>; Andres Freund <andres@2ndquadrant.com>; pgsql-hackers

Noah Misch wrote:
> On Wed, Oct 31, 2012 at 05:22:10PM -0300, Alvaro Herrera wrote:

> > Not really sure about the proposed syntax, but yes clearly we need some
> > other syntax to mean "FOR NON KEY UPDATE".  I would rather keep FOR
> > UPDATE to mean what I currently call FOR KEY UPDATE.  More proposals for
> > the other (weaker) lock level welcome (but if you love FOR NON KEY
> > UPDATE, please chime in too)
> 
> Agree on having "FOR UPDATE" without any "FOR KEY UPDATE" synonym.  For the
> weaker lock, I mildly preferred the proposal of "FOR NO KEY UPDATE".  NON KEY
> captures the idea better in English, but NO is close enough and already part
> of the SQL lexicon.

This is the proposal I like best; however there is an asymmetry, because
the locking options now are

FOR KEY SHARE
FOR SHARE
FOR NO KEY UPDATE
FOR UPDATE

I used to have comments such as

/* Currently, SELECT ... FOR [KEY] UPDATE/SHARE requires UPDATE privileges */
#define ACL_SELECT_FOR_UPDATE	ACL_UPDATE

but now they are slightly incorrect because the NO is not illustrated.
I guess I could use SELECT ... FOR [NO KEY] UPDATE/SHARE but this leaves
out the "FOR KEY SHARE" case (and can be thought to introduce a FOR NO
KEY SHARE case).  And getting much more verbose than that is probably
not warranted.  In some places I would like the use a phrase like "the
locking clause", but I'm not sure that it's clear enough.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-14 15:23  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  1 sibling, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-14 15:23 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers

Here's version 23 of this patch, with fixes for the below comments and
a merge to master.

Andres Freund wrote:
> On Thursday, October 18, 2012 09:58:20 PM Alvaro Herrera wrote:
> > Here is version 22 of this patch.  This version contains fixes to issues
> > reported by Andres, as well as a rebase to latest master.
> 
> Ok, I now that pgconf.eu has ended I am starting to do a real review:
> 
> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2 and earlier 
> you could be sure that if you FOR UPDATE'ed a row you could delete it. Unless 
> I miss something now this will not block somebody else acquiring a FOR KEY 
> SHARE lock, so this guarantee is gone.
> This seems likely to introduce subtle problems in user applications.
> 
> I propose renaming FOR UPDATE => FOR NO KEY UPDATE, FOR KEY UPDATE => FOR 
> UPDATE or similar (or PREVENT KEY UPDATE?). That keeps the old meaning of FOR 
> UPDATE.

Okay, in subsequent discussion everyone agreed that this is necessary;
thanks for noticing the problem.  Instead of your suggestion, however, I
used Noah's; luckily I just noticed that it was identical to yours.  So
apparently there is also agreement on this point.  I have updated the
code, comments and docs (and renamed some other stuff to match).

> You write "SELECT FOR UPDATE is a standards-compliant exclusive lock". I 
> didn't really find all that much about the semantics of FOR UPDATE on cursors 
> in the standard other than "The operations of update and delete are permitted 
> for updatable cursors, subject to constraining Access Rules.". 

I don't really know where that comes from, but it's a statement I
grabbed from the docs somewhere.

> * I would welcome adding some explanatory comments about the point of 
> TupleLockExtraInfo and MultiXactStatusLock at the respective definition.

Done.  If that's not enough, I would welcome suggestions or specific
question needing clarification.

> * Why do we have the HEAP_XMAX_IS_MULTI && HEAP_XMAX_LOCK_ONLY case?

For pg_upgrade.  HEAP_XMAX_LOCK_ONLY is the value previously used by
HEAP_XMAX_SHARED_LOCK, so a database containing such values that is
upgraded will contain that bit pattern.

> * I think some of the longer comments could use the attention of a native 
> speaker, unfortunately thats not me.

Sorry about that.

> * I am still uncomfortable with the FOR SHARE deoptimization. I have seen 
> people lock larger parts of their table to make some READ COMMITTED things 
> actually safe.

I haven't changed this yet.  There are bits available in infomask2 that
we could use, if we agree that it is necessary; or, as you say, we could
use two bits to distinguish three different states, but we need to
ensure that pg_upgraded databases will work sanely.

> * In heap_lock_tuple's  XMAX_IS_MULTI case
> 
> [snip]
> 
> why is it membermode > mode and not membermode >= mode?

Uh, that's a bug.  Fixed.  As noticed in the comment above that snippet,
there was a deadlock possible here.  Maybe I should add a test to ensure
this doesn't happen.

> * Is the case of a a non-key-update followed by a key-update actually handled 
> when doing a heap_lock_tuple with mode = LockTupleKeyShare and follow_updates 
> = false? I don't really see how, so it seems to deserve at least a comment.

I wasn't able to figure out what you think is the problem.

> But then I don't yet understand why follow_update makes sense.

Basically heap_lock_tuple can be told by the caller to follow the update
chain to lock subsequent tuples, or not.  Mainly, EvalPlanQual does not
want this to happen, because it does its own update-chain walking.

In all honesty, it is not clear to me that this is the proper solution
to the problem.  Maybe some hacking around ExecLockRows is necessary.

> * In heap_lock_tuple with mode == LockTupleUpdate && infomask & 
> HEAP_XMAX_IS_MULTI, were leaking members when doing goto l3. Probably not 
> relevant, but given the code tries to be careful everywhere else...

Right, plugged.

> We might also leak in the members == 0 case there, not sure yet.

Hm, I don't think GetMultiXactIdMembers really considers the case when 0
members are to be returned.  Maybe that needs some more tweaking.

> Ok, this is at about 35% of the diff in my second pass, but I just arrived back 
> in Berlin, and this seems useful enough on its own...

Many thanks.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachments:

  fklocks-23.patch.gz (application/octet-stream, 95.9K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-14 16:27  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 4 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-14 16:27 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers

Alvaro Herrera wrote:

> > * In heap_lock_tuple's  XMAX_IS_MULTI case
> > 
> > [snip]
> > 
> > why is it membermode > mode and not membermode >= mode?
> 
> Uh, that's a bug.  Fixed.  As noticed in the comment above that snippet,
> there was a deadlock possible here.  Maybe I should add a test to ensure
> this doesn't happen.

Done:
https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770

(I don't think this is worth a v24 submission).

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-16 00:24  Noah Misch <noah@leadboat.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  3 siblings, 1 reply; 74+ messages in thread

From: Noah Misch @ 2012-11-16 00:24 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Andres Freund <andres@2ndquadrant.com>; pgsql-hackers

On Wed, Nov 14, 2012 at 01:27:26PM -0300, Alvaro Herrera wrote:
> https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770
> 
> (I don't think this is worth a v24 submission).

Are you aware of any defects in or unanswered questions of this version that
would stall your commit thereof?




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-16 14:55  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  3 siblings, 0 replies; 74+ messages in thread

From: Andres Freund @ 2012-11-16 14:55 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers

On 2012-11-14 13:27:26 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > > * In heap_lock_tuple's  XMAX_IS_MULTI case
> > >
> > > [snip]
> > >
> > > why is it membermode > mode and not membermode >= mode?
> >
> > Uh, that's a bug.  Fixed.  As noticed in the comment above that snippet,
> > there was a deadlock possible here.  Maybe I should add a test to ensure
> > this doesn't happen.
>
> Done:
> https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770
>
> (I don't think this is worth a v24 submission).

I have started doing some performance testing and I fear I was right in
being suspicious about the performance difference for FOR SHARE locks:

Tested with
pgbench -p 5442 -U andres \
     -c 30  -j 30 \
     -M prepared -f ~/tmp/postgres-fklocks/select-for-share.sql \
     -T 20 postgres

on a pgbench -i -s 10 database, where select-for-share.sql is:

BEGIN;
\set naccounts 1000000
\setrandom aid 1 :naccounts
SELECT abalance FROM pgbench_accounts WHERE aid = :aid FOR SHARE;
\setrandom aid 1 :naccounts
SELECT abalance FROM pgbench_accounts WHERE aid = :aid FOR SHARE;
\setrandom aid 1 :naccounts
SELECT abalance FROM pgbench_accounts WHERE aid = :aid FOR SHARE;
COMMIT;

which very roughly resembles workloads I have seen in reality (locking
some records your rely on while you do some work).

With
52b4729fcfc20f056f17531a6670d8c4b9696c39 (alvherre/fklocks)
vs
273986bf0d39e5166eb15ba42ebff4803e23a688 (latest merged master)

I get
tps = 8986.133496 (excluding connections establishing)
vs
tps = 25307.861193 (excluding connections establishing)

Thats nearly a factor of three which seems to be too big to be
acceptable to me.
So I really think we need to bring FOR SHARE locks back as a flag.

I have done some benchmarking of other cases (plain pgbench, pgbench
with foreign keys, large insertions, large amounts of FOR SHARE locks)
and haven't found anything really outstanding so far.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-16 16:17  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Noah Misch <noah@leadboat.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-16 16:17 UTC (permalink / raw)
  To: Noah Misch <noah@leadboat.com>; +Cc: Andres Freund <andres@2ndquadrant.com>; pgsql-hackers

Noah Misch wrote:
> On Wed, Nov 14, 2012 at 01:27:26PM -0300, Alvaro Herrera wrote:
> > https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770
> > 
> > (I don't think this is worth a v24 submission).
> 
> Are you aware of any defects in or unanswered questions of this version that
> would stall your commit thereof?

Yeah, I am revisiting the list of XXX/FIXME comments you pointed out
previously.

And I would still like someone with EPQ understanding to review the
ExecLockRows / EvalPlanQual / heap_lock_tuple interactions.

Andres is on the verge of convincing me that we need to support
singleton FOR SHARE without multixacts due to performance concerns.  It
would be useful for more people to chime in here: is FOR SHARE an
important case to cater for?  I wonder if using FOR KEY SHARE (keep
performance characteristics, but would need to revise application code)
would satisfy Andres' users, for example.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-16 16:31  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Andres Freund @ 2012-11-16 16:31 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Noah Misch <noah@leadboat.com>; pgsql-hackers

On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
> Noah Misch wrote:
> > On Wed, Nov 14, 2012 at 01:27:26PM -0300, Alvaro Herrera wrote:
> > > https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770
> > >
> > > (I don't think this is worth a v24 submission).
> >
> > Are you aware of any defects in or unanswered questions of this version that
> > would stall your commit thereof?
>
> Yeah, I am revisiting the list of XXX/FIXME comments you pointed out
> previously.
>
> And I would still like someone with EPQ understanding to review the
> ExecLockRows / EvalPlanQual / heap_lock_tuple interactions.

I am in the process of looking at those atm, but we need somebody that
actually understands the intricacies here...

> Andres is on the verge of convincing me that we need to support
> singleton FOR SHARE without multixacts due to performance concerns.

I don't really see any arguments against doing so. We aren't in a that
big shortage of flags and if we need more than available I think we can
free some (e.g. XMAX/XMIN_INVALID).

> It
> would be useful for more people to chime in here: is FOR SHARE an
> important case to cater for?  I wonder if using FOR KEY SHARE (keep
> performance characteristics, but would need to revise application code)
> would satisfy Andres' users, for example.

It definitely wouldn't help in the cases I have seen because the point
is to protect against actual content changes of the rows, not just the
keys.
Note that you actually need to use explicit FOR SHARE/UPDATE for
correctness purposes in many scenarios unless youre running in 9.1+
serializable mode. And that cannot be used in some cases (try queuing
for example) because the rollback rates would be excessive.

Even if applications could be fixed, requiring changes to applications
locking behaviour, which possibly is far from trivial, seems like a too
big upgrade barrier.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-17 03:31  Noah Misch <noah@leadboat.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Noah Misch @ 2012-11-17 03:31 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers

On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
> On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
> > Andres is on the verge of convincing me that we need to support
> > singleton FOR SHARE without multixacts due to performance concerns.
> 
> I don't really see any arguments against doing so. We aren't in a that
> big shortage of flags and if we need more than available I think we can
> free some (e.g. XMAX/XMIN_INVALID).

The patch currently leaves two unallocated bits.  Reclaiming currently-used
bits means a binary compatibility break.  Until we plan out such a thing,
reclaimable bits are not as handy as never-allocated bits.  I don't think we
should lightly expend one of the final two.

> > It
> > would be useful for more people to chime in here: is FOR SHARE an
> > important case to cater for?  I wonder if using FOR KEY SHARE (keep
> > performance characteristics, but would need to revise application code)
> > would satisfy Andres' users, for example.
> 
> It definitely wouldn't help in the cases I have seen because the point
> is to protect against actual content changes of the rows, not just the
> keys.
> Note that you actually need to use explicit FOR SHARE/UPDATE for
> correctness purposes in many scenarios unless youre running in 9.1+
> serializable mode. And that cannot be used in some cases (try queuing
> for example) because the rollback rates would be excessive.

I agree that tripling FOR SHARE cost is risky.  Where is the added cost
concentrated?  Perchance that multiple belies optimization opportunities.

Thanks,
nm




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-17 14:20  Andres Freund <andres@2ndquadrant.com>
  parent: Noah Misch <noah@leadboat.com>
  0 siblings, 2 replies; 74+ messages in thread

From: Andres Freund @ 2012-11-17 14:20 UTC (permalink / raw)
  To: Noah Misch <noah@leadboat.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers

On 2012-11-16 22:31:51 -0500, Noah Misch wrote:
> On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
> > On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
> > > Andres is on the verge of convincing me that we need to support
> > > singleton FOR SHARE without multixacts due to performance concerns.
> >
> > I don't really see any arguments against doing so. We aren't in a that
> > big shortage of flags and if we need more than available I think we can
> > free some (e.g. XMAX/XMIN_INVALID).
>
> The patch currently leaves two unallocated bits.  Reclaiming currently-used
> bits means a binary compatibility break.  Until we plan out such a thing,
> reclaimable bits are not as handy as never-allocated bits.  I don't think we
> should lightly expend one of the final two.

Not sure what you mean with a binary compatibility break?
pg_upgrade'ability?

What I previously suggested somewhere was:

#define HEAP_XMAX_SHR_LOCK    0x0010
#define HEAP_XMAX_EXCL_LOCK   0x0040
#define HEAP_XMAX_KEYSHR_LOCK (HEAP_XMAX_SHR_LOCK|HEAP_XMAX_EXCL_LOCK)
/*
 * Different from _LOCK_BITS because it doesn't include LOCK_ONLY
 */
#define HEAP_LOCK_MASK        (HEAP_XMAX_SHR_LOCK|HEAP_XMAX_EXCL_LOCK)

#define HEAP_XMAX_IS_SHR_LOCKED(tup) \
    (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_SHR_LOCK)
#define HEAP_XMAX_IS_EXCL_LOCKED(tup) \
    (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_EXCL_LOCK)
#define HEAP_XMAX_IS_KEYSHR_LOCKED(tup) \
    (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_KEYSHR_LOCK)

It makes checking for locks sightly more more complicated, but its not
too bad...

> > > It
> > > would be useful for more people to chime in here: is FOR SHARE an
> > > important case to cater for?  I wonder if using FOR KEY SHARE (keep
> > > performance characteristics, but would need to revise application code)
> > > would satisfy Andres' users, for example.
> >
> > It definitely wouldn't help in the cases I have seen because the point
> > is to protect against actual content changes of the rows, not just the
> > keys.
> > Note that you actually need to use explicit FOR SHARE/UPDATE for
> > correctness purposes in many scenarios unless youre running in 9.1+
> > serializable mode. And that cannot be used in some cases (try queuing
> > for example) because the rollback rates would be excessive.
>
> I agree that tripling FOR SHARE cost is risky.  Where is the added cost
> concentrated?  Perchance that multiple belies optimization opportunities.

Good question, let me play a bit.

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-17 14:56  Noah Misch <noah@leadboat.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  1 sibling, 0 replies; 74+ messages in thread

From: Noah Misch @ 2012-11-17 14:56 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers

On Sat, Nov 17, 2012 at 03:20:20PM +0100, Andres Freund wrote:
> On 2012-11-16 22:31:51 -0500, Noah Misch wrote:
> > On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
> > > On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
> > > > Andres is on the verge of convincing me that we need to support
> > > > singleton FOR SHARE without multixacts due to performance concerns.
> > >
> > > I don't really see any arguments against doing so. We aren't in a that
> > > big shortage of flags and if we need more than available I think we can
> > > free some (e.g. XMAX/XMIN_INVALID).
> >
> > The patch currently leaves two unallocated bits.  Reclaiming currently-used
> > bits means a binary compatibility break.  Until we plan out such a thing,
> > reclaimable bits are not as handy as never-allocated bits.  I don't think we
> > should lightly expend one of the final two.
> 
> Not sure what you mean with a binary compatibility break?
> pg_upgrade'ability?

Yes.  If we decide HEAP_XMIN_INVALID isn't helping, we can stop adding it to
tuples anytime.  Old tuples may continue to carry the bit, with no particular
deadline for their demise.  To reuse that bit in the mean time, we'll need to
prove that no tuple writable by PostgreSQL 8.3+ will get an unacceptable
interpretation under the new meaning of the bit.  Alternately, build the
mechanism to prove that all such old bits are gone before using the bit in the
new way.  This keeps HEAP_MOVED_IN and HEAP_MOVED_OFF unavailable today.

> What I previously suggested somewhere was:
> 
> #define HEAP_XMAX_SHR_LOCK    0x0010
> #define HEAP_XMAX_EXCL_LOCK   0x0040
> #define HEAP_XMAX_KEYSHR_LOCK (HEAP_XMAX_SHR_LOCK|HEAP_XMAX_EXCL_LOCK)
> /*
>  * Different from _LOCK_BITS because it doesn't include LOCK_ONLY
>  */
> #define HEAP_LOCK_MASK        (HEAP_XMAX_SHR_LOCK|HEAP_XMAX_EXCL_LOCK)
> 
> #define HEAP_XMAX_IS_SHR_LOCKED(tup) \
>     (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_SHR_LOCK)
> #define HEAP_XMAX_IS_EXCL_LOCKED(tup) \
>     (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_EXCL_LOCK)
> #define HEAP_XMAX_IS_KEYSHR_LOCKED(tup) \
>     (((tup)->t_infomask & HEAP_LOCK_BITS) == HEAP_XMAX_KEYSHR_LOCK)
> 
> It makes checking for locks sightly more more complicated, but its not
> too bad...

Agreed; that seems reasonable.




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-17 16:07  Andres Freund <andres@2ndquadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  1 sibling, 1 reply; 74+ messages in thread

From: Andres Freund @ 2012-11-17 16:07 UTC (permalink / raw)
  To: Noah Misch <noah@leadboat.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers

> > I agree that tripling FOR SHARE cost is risky.  Where is the added cost
> > concentrated?  Perchance that multiple belies optimization opportunities.
>
> Good question, let me play a bit.

Ok, I benchmarked around and from what I see there is no single easy
target.
The biggest culprits I could find are:
1. higher amount of XLogInsert calls per transaction (visible
in pgbench -t instead of -T mode while watching the WAL volume)
2. Memory allocations in GetMultiXactIdMembers
3. Memory allocations in mXactCachePut
 a) cache entry itself
 b) the cache context
4. More lwlocks acquisitions

We can possibly optimize a bit with 2) by using a static buffer for
common member sizes, but thats not going to buy us too much...

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-17 18:25  Noah Misch <noah@leadboat.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 0 replies; 74+ messages in thread

From: Noah Misch @ 2012-11-17 18:25 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; pgsql-hackers

On Sat, Nov 17, 2012 at 05:07:18PM +0100, Andres Freund wrote:
> > > I agree that tripling FOR SHARE cost is risky.  Where is the added cost
> > > concentrated?  Perchance that multiple belies optimization opportunities.
> >
> > Good question, let me play a bit.
> 
> Ok, I benchmarked around and from what I see there is no single easy
> target.
> The biggest culprits I could find are:
> 1. higher amount of XLogInsert calls per transaction (visible
> in pgbench -t instead of -T mode while watching the WAL volume)
> 2. Memory allocations in GetMultiXactIdMembers
> 3. Memory allocations in mXactCachePut
>  a) cache entry itself
>  b) the cache context
> 4. More lwlocks acquisitions
> 
> We can possibly optimize a bit with 2) by using a static buffer for
> common member sizes, but thats not going to buy us too much...

In that case, +1 for your proposal to prop up FOR SHARE.




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-19 11:58  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  3 siblings, 1 reply; 74+ messages in thread

From: Andres Freund @ 2012-11-19 11:58 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers


On 2012-11-14 13:27:26 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > > * In heap_lock_tuple's  XMAX_IS_MULTI case
> > >
> > > [snip]
> > >
> > > why is it membermode > mode and not membermode >= mode?
> >
> > Uh, that's a bug.  Fixed.  As noticed in the comment above that snippet,
> > there was a deadlock possible here.  Maybe I should add a test to ensure
> > this doesn't happen.
>
> Done:
> https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770

Some more review bits, based on ffd6250d1d393f2ecb9bfc55c2c6f715dcece557

- if oldestMultiXactId + db is set and then that database is dropped we seem to
  have a problem because MultiXactAdvanceOldest won't overwrite those
  values. Should probably use SetMultiXactIdLimit directly.

- what stop multixacts only being filled out (i.e RecordNewMultiXact()) *after*
  the XLogInsert() *and* after a MultiXactGetCheckptMulti()? Afaics
  MultiXactGenLock is not hold in CreateMultiXactId(). If we crash in that
  moment we loose the multixact data which now means potential data loss...

- multixact member group data crossing 512 sector boundaries makes me uneasy
  (as its 5 bytes). I don't really see a scenario where its dangerous, but
  ... Does anybody see a problem here?

- there are quite some places that do
	multiStopLimit = multiWrapLimit - 100;
	if (multiStopLimit < FirstMultiXactId)
		multiStopLimit -= FirstMultiXactId;

  perhaps MultiXactIdAdvance and MultiXactIdRetreat macros are in order?

- I find using a default: clause in switches with enum types where everything
  is expected to be handled like the following a bad idea, this way the
  compiler won't warn you if youve missed case's which makes changing/extending code harder:
		switch (rc->strength)
		{
			case LCS_FORNOKEYUPDATE:
				newrc->markType = ROW_MARK_EXCLUSIVE;
				break;
			case LCS_FORSHARE:
				newrc->markType = ROW_MARK_SHARE;
				break;
			case LCS_FORKEYSHARE:
				newrc->markType = ROW_MARK_KEYSHARE;
				break;
			case LCS_FORUPDATE:
				newrc->markType = ROW_MARK_KEYEXCLUSIVE;
				break;
			default:
				elog(ERROR, "unsupported rowmark type %d", rc->strength);
		}
-
#if 0
			/*
			 * The idea here is to remove the IS_MULTI bit, and replace the
			 * xmax with the updater's Xid.  However, we can't really do it:
			 * modifying the Xmax is not allowed under our buffer locking
			 * rules, unless we have an exclusive lock; but we don't know that
			 * we have it.  So the multi needs to remain in place :-(
			 */
			ResetMultiHintBit(tuple, buffer, xmax, true);
#endif

 Three things:
    - HeapTupleSatisfiesUpdate is actually always called exclusively locked ;)
    - Extending something like LWLockHeldByMe to also return the current
      lockmode doesn't sound hard
    - we seem to be using #ifdef NOT_YET for such cases

- Using a separate production for the lockmode seems to be nicer imo, not
  really important though
for_locking_item:
			FOR UPDATE locked_rels_list opt_nowait
...
			| FOR NO KEY UPDATE locked_rels_list opt_nowait
...
			| FOR SHARE locked_rels_list opt_nowait
...
			| FOR KEY SHARE locked_rels_list opt_nowait
		;

- not really padding, MultiXactStatus is 4bytes...
	/*
	 * XXX Note: there's a lot of padding space in MultiXactMember.  We could
	 * find a more compact representation of this Xlog record -- perhaps all the
	 * status flags in one XLogRecData, then all the xids in another one?  Not
	 * clear that it's worth the trouble though.
	 */
- why
#define SizeOfMultiXactCreate (offsetof(xl_multixact_create, nmembers) + sizeof(int32))
and not
#define SizeOfMultiXactCreate offsetof(xl_multixact_create, members)
- starting a critical section in GetNewMultiXactId but not ending it is ugly,
  but not new

Greetings,

Andres

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-19 12:12  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  3 siblings, 0 replies; 74+ messages in thread

From: Andres Freund @ 2012-11-19 12:12 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers

On 2012-11-14 13:27:26 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > > * In heap_lock_tuple's  XMAX_IS_MULTI case
> > >
> > > [snip]
> > >
> > > why is it membermode > mode and not membermode >= mode?
> >
> > Uh, that's a bug.  Fixed.  As noticed in the comment above that snippet,
> > there was a deadlock possible here.  Maybe I should add a test to ensure
> > this doesn't happen.
>
> Done:
> https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770
>
> (I don't think this is worth a v24 submission).

One more observation:
        /*
         * Get and lock the updated version of the row; if fail, return
        NULL.
         */
-       copyTuple = EvalPlanQualFetch(estate, relation, LockTupleExclusive,
+       copyTuple = EvalPlanQualFetch(estate, relation, LockTupleNoKeyExclusive,

That doesn't seem to be correct to me. Why is it ok to acquire a
potentially too low locklevel here?

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-20 20:36  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-20 20:36 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers

Andres Freund wrote:


> - I find using a default: clause in switches with enum types where everything
>   is expected to be handled like the following a bad idea, this way the
>   compiler won't warn you if youve missed case's which makes changing/extending code harder:
> 		switch (rc->strength)
> 		{

I eliminated some of these default clauses, but the compiler is not
happy about not having some of them, so they remain.

> -
> #if 0
> 			/*
> 			 * The idea here is to remove the IS_MULTI bit, and replace the
> 			 * xmax with the updater's Xid.  However, we can't really do it:
> 			 * modifying the Xmax is not allowed under our buffer locking
> 			 * rules, unless we have an exclusive lock; but we don't know that
> 			 * we have it.  So the multi needs to remain in place :-(
> 			 */
> 			ResetMultiHintBit(tuple, buffer, xmax, true);
> #endif
> 
>  Three things:
>     - HeapTupleSatisfiesUpdate is actually always called exclusively locked ;)
>     - Extending something like LWLockHeldByMe to also return the current
>       lockmode doesn't sound hard
>     - we seem to be using #ifdef NOT_YET for such cases

After spending some time trying to make this work usefully, I observed
that it's pointless, at least if we apply it only in
HeapTupleSatisfiesUpdate, because the IS_MULTI bit is going to be
removed by compute_new_xmax_infomask if the multi is gone.  Something
like this would be useful if we could do it in other places; say when
we're merely scanning page without the specific intention of modifying
that particular tuple.  Maybe in heap_prune_page, for example.  ISTM we
can see that as an optimization we can add later.

For the record, the implementation of ResetMultiHintBit looks like this:

/*
 * When a tuple is found to be marked by a MultiXactId, all whose members are
 * completed transactions, the HEAP_XMAX_IS_MULTI bit can be removed.
 * Additionally, at the request of caller, we can set the Xmax to the given
 * Xid, and set HEAP_XMAX_COMMITTED.
 *
 * Note that per buffer access rules, the caller to this function must hold
 * exclusive content lock on the affected buffer.
 */
static inline void
ResetMultiHintBit(HeapTupleHeader tuple, Buffer buffer,
 				  TransactionId xid, bool mark_committed)
{
	Assert(LWLockModeHeld((&BufferDescriptors[buffer])->content_lock ==
						  LW_EXCLUSIVE));
	Assert(tuple->t_infomask & HEAP_XMAX_IS_MULTI);
	Assert(!(tuple->t_infomask & HEAP_XMAX_INVALID));
	Assert(!MultiXactIdIsRunning(HeapTupleHeaderGetRawXmax(tuple)));

	tuple->t_infomask &= ~HEAP_XMAX_BITS;
	HeapTupleHeaderSetXmax(tuple, xid);
	if (!TransactionIdIsValid(xid))
		tuple->t_infomask |= HEAP_XMAX_INVALID;
	/* note that HEAP_KEYS_UPDATED persists, if set */

	if (mark_committed)
		SetHintBits(tuple, buffer, HEAP_XMAX_COMMITTED, xid);
	else
		SetBufferCommitInfoNeedsSave(buffer);
}

(This is removed by commit 52f86f82fb3e01a6ed0b8106bac20f319bb3ad0a in
my github tree, but that commit might be lost in the future, hence this
paste.)


Some of your other observations have been fixed by commits that I have
pushed to my github tree.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-20 21:15  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Andres Freund @ 2012-11-20 21:15 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers

On 2012-11-20 17:36:14 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
>
> > - I find using a default: clause in switches with enum types where everything
> >   is expected to be handled like the following a bad idea, this way the
> >   compiler won't warn you if youve missed case's which makes changing/extending code harder:
> > 		switch (rc->strength)
> > 		{
>
> I eliminated some of these default clauses, but the compiler is not
> happy about not having some of them, so they remain.

You have removed the ones that looked removable to me...

>
> > -
> > #if 0
> > 			/*
> > 			 * The idea here is to remove the IS_MULTI bit, and replace the
> > 			 * xmax with the updater's Xid.  However, we can't really do it:
> > 			 * modifying the Xmax is not allowed under our buffer locking
> > 			 * rules, unless we have an exclusive lock; but we don't know that
> > 			 * we have it.  So the multi needs to remain in place :-(
> > 			 */
> > 			ResetMultiHintBit(tuple, buffer, xmax, true);
> > #endif
> >
> >  Three things:
> >     - HeapTupleSatisfiesUpdate is actually always called exclusively locked ;)
> >     - Extending something like LWLockHeldByMe to also return the current
> >       lockmode doesn't sound hard
> >     - we seem to be using #ifdef NOT_YET for such cases
>
> After spending some time trying to make this work usefully, I observed
> that it's pointless, at least if we apply it only in
> HeapTupleSatisfiesUpdate, because the IS_MULTI bit is going to be
> removed by compute_new_xmax_infomask if the multi is gone.  Something
> like this would be useful if we could do it in other places; say when
> we're merely scanning page without the specific intention of modifying
> that particular tuple.  Maybe in heap_prune_page, for example.  ISTM we
> can see that as an optimization we can add later.

heap_prune_page sounds like a good fit, yes. One other place would be
when following hot chains, but the locking would be far more critical in
that path, so its less likely to be beneficial.
Pushing it off sounds good to me.

> Some of your other observations have been fixed by commits that I have
> pushed to my github tree.

A short repetition of the previous pgbench run of many SELECT FOR
SHARE's:

10s test:
master:  22673 24637 23874 25527
fklocks: 24835 24601 24606 24868

60s test:
master:  32609 33087
fklocks: 33350 33359

Very nice!

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services




^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-26 19:45  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-26 19:45 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers

Here's version 24.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachments:

  fklocks-24.patch.gz (application/octet-stream, 96.5K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-27 15:07  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-27 15:07 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers

Alvaro Herrera wrote:
> Here's version 24.

Old review emails still contains some items that didn't lead to any
changes.  I tried to keep close track of those.  To that list I add a
couple of things of my own.  Here they are, for those following along.
I welcome suggestions.


- Fix the multixact cache in multixact.c -- see mXactCacheEnt.

- ResetHintBitMulti() was removed; need to remove old XMAX_IS_MULTI
  somewhere; perhaps during HOT page pruning?

- EvalPlanQual and ExecLockRows maybe need a different overall locking
  strategy.  Right now follow_updates=false is used to avoid deadlocks.

- Ensure multixact.c behaves sanely on wraparound.

- Is the case of a a non-key-update followed by a key-update actually handled
  when doing a heap_lock_tuple with mode = LockTupleKeyShare and follow_updates
  = false? I don't really see how, so it seems to deserve at least a comment.

- if oldestMultiXactId + db is set and then that database is dropped we seem to
  have a problem because MultiXactAdvanceOldest won't overwrite those
  values. Should probably use SetMultiXactIdLimit directly.

- what stop multixacts only being filled out (i.e RecordNewMultiXact()) *after*
  the XLogInsert() *and* after a MultiXactGetCheckptMulti()? Afaics
  MultiXactGenLock is not hold in CreateMultiXactId(). If we crash in that
  moment we loose the multixact data which now means potential data loss...

- multixact member group data crossing 512 sector boundaries makes me uneasy
  (as its 5 bytes). I don't really see a scenario where its dangerous, but
  ... Does anybody see a problem here?

- there are quite some places that do
	multiStopLimit = multiWrapLimit - 100;
	if (multiStopLimit < FirstMultiXactId)
		multiStopLimit -= FirstMultiXactId;

  perhaps MultiXactIdAdvance and MultiXactIdRetreat macros are in order?

- not really padding, MultiXactStatus is 4bytes...
	/*
	 * XXX Note: there's a lot of padding space in MultiXactMember.  We could
	 * find a more compact representation of this Xlog record -- perhaps all the
	 * status flags in one XLogRecData, then all the xids in another one?  Not
	 * clear that it's worth the trouble though.
	 */

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-28 21:22  Kevin Grittner <kgrittn@mail.com>
  0 siblings, 0 replies; 74+ messages in thread

From: Kevin Grittner @ 2012-11-28 21:22 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; Andres Freund <andres@2ndquadrant.com>; +Cc: pgsql-hackers

Alvaro Herrera wrote:

> Here's version 24.

This no longer applies after the rmgr rm_desc patch.

-Kevin


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-29 15:23  Kevin Grittner <kgrittn@mail.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Kevin Grittner @ 2012-11-29 15:23 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers@postgresql.org,"Andres Freund" <andres@2ndquadrant.com>

Kevin Grittner wrote:
> Alvaro Herrera wrote:
> 
>> Here's version 24.
> 
> This no longer applies after the rmgr rm_desc patch.

I took a shot at merging those so I could review the patch against
HEAD; attached in hopes that it will be useful.

Hopefully this isn't too far off from what .

-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachments:

  fklocks-25.patch.gz (application/x-gzip, 97.1K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-29 16:02  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Kevin Grittner <kgrittn@mail.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-29 16:02 UTC (permalink / raw)
  To: Kevin Grittner <kgrittn@mail.com>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@2ndquadrant.com>

Kevin Grittner wrote:
> Kevin Grittner wrote:
> > Alvaro Herrera wrote:
> > 
> >> Here's version 24.
> > 
> > This no longer applies after the rmgr rm_desc patch.
> 
> I took a shot at merging those so I could review the patch against
> HEAD; attached in hopes that it will be useful.
> 
> Hopefully this isn't too far off from what .

Uh, sorry for remaining silent -- I'm about to post an updated patch,
having just pushed my merge to github.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-11-29 16:16  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 2 replies; 74+ messages in thread

From: Alvaro Herrera @ 2012-11-29 16:16 UTC (permalink / raw)
  To: Kevin Grittner <kgrittn@mail.com>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@2ndquadrant.com>

Alvaro Herrera wrote:
> Kevin Grittner wrote:
> > Kevin Grittner wrote:
> > > Alvaro Herrera wrote:
> > > 
> > >> Here's version 24.
> > > 
> > > This no longer applies after the rmgr rm_desc patch.
> > 
> > I took a shot at merging those so I could review the patch against
> > HEAD; attached in hopes that it will be useful.
> > 
> > Hopefully this isn't too far off from what .
> 
> Uh, sorry for remaining silent -- I'm about to post an updated patch,
> having just pushed my merge to github.

Here it is.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachments:

  fklocks-26.patch.gz (application/octet-stream, 96.8K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-12-22 09:53  Erik Rijkers <er@xs4all.nl>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 2 replies; 74+ messages in thread

From: Erik Rijkers @ 2012-12-22 09:53 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Kevin Grittner <kgrittn@mail.com>; pgsql-hackers@postgresql.org, "Andres Freund" <andres@2ndquadrant.com>

On Thu, November 29, 2012 17:16, Alvaro Herrera wrote:
> Here it is.
>
>   fklocks-26.patch.gz

This applies today after removing, not only the infamous catversion.h chunk, but also a file_fdw
chunk. (It's not really a problem.)

I also wondered if anyone has any perl/python/bash programs handy that uses these new options.  I
can hack something together myself, but I just thought I'd ask.


Thanks,


Erik Rijkers




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-12-22 11:50  Andres Freund <andres@2ndquadrant.com>
  parent: Erik Rijkers <er@xs4all.nl>
  1 sibling, 0 replies; 74+ messages in thread

From: Andres Freund @ 2012-12-22 11:50 UTC (permalink / raw)
  To: Erik Rijkers <er@xs4all.nl>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

On 2012-12-22 10:53:47 +0100, Erik Rijkers wrote:
> On Thu, November 29, 2012 17:16, Alvaro Herrera wrote:
> > Here it is.
> >
> >   fklocks-26.patch.gz
>
> This applies today after removing, not only the infamous catversion.h chunk, but also a file_fdw
> chunk. (It's not really a problem.)
>
> I also wondered if anyone has any perl/python/bash programs handy that uses these new options.  I
> can hack something together myself, but I just thought I'd ask.

I have mostly done code review and some very targeted testing (pgbench,
gdb + psql). So no ready scripts, sorry.
There are imo some unfinished pieces (the whole EPQ integration) that
will require significant retesting once Alvaro has time to work on this
again..

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2012-12-28 20:48  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Erik Rijkers <er@xs4all.nl>
  1 sibling, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2012-12-28 20:48 UTC (permalink / raw)
  To: Erik Rijkers <er@xs4all.nl>; +Cc: Kevin Grittner <kgrittn@mail.com>; pgsql-hackers@postgresql.org, Andres Freund <andres@2ndquadrant.com>

Erik Rijkers wrote:
> On Thu, November 29, 2012 17:16, Alvaro Herrera wrote:
> > Here it is.
> >
> >   fklocks-26.patch.gz
> 
> This applies today after removing, not only the infamous catversion.h chunk, but also a file_fdw
> chunk. (It's not really a problem.)

FWIW, while it's probably not interesting to you, it must be noted that
the catversion.h number to use must match a
contrib/pg_upgrade/pg_upgrade.h symbol.

As far as file_fdw hunks, I only see this one:

inline patch 1: contrib/file_fdw/output/file_fdw.source (+1/-1 lines) download inline-1.patch
--- a/contrib/file_fdw/output/file_fdw.source
+++ b/contrib/file_fdw/output/file_fdw.source
@@ -191,7 +191,7 @@ ERROR:  cannot change foreign table "agg_csv"
 DELETE FROM agg_csv WHERE a = 100;
 ERROR:  cannot change foreign table "agg_csv"
 SELECT * FROM agg_csv FOR UPDATE OF agg_csv;
-ERROR:  SELECT FOR UPDATE/SHARE cannot be used with foreign table "agg_csv"
+ERROR:  SELECT FOR UPDATE/SHARE/KEY UPDATE/KEY SHARE cannot be used with foreign table "agg_csv"
 LINE 1: SELECT * FROM agg_csv FOR UPDATE OF agg_csv;
                                             ^
 -- but this should be ignored

Surely that needs to be patched still?  And this hunk applies without
any trouble, so I don't see why you had to remove it.

Anyway, here's v27, which is the same code merged to latest master.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachments:

  fklocks-27.patch.gz (application/octet-stream, 96.9K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-10 21:00  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 2 replies; 74+ messages in thread

From: Alvaro Herrera @ 2013-01-10 21:00 UTC (permalink / raw)
  To: Erik Rijkers <er@xs4all.nl>; +Cc: Kevin Grittner <kgrittn@mail.com>; pgsql-hackers@postgresql.org, Andres Freund <andres@2ndquadrant.com>

Here's version 28 of this patch.  The only substantive change here from
v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
or LockTupleNoKeyExclusive, depending on whether the key columns are
being modified by the update.  This needs to go through EvalPlanQual, so
that function is now getting the lock mode as a parameter instead of
hardcoded LockTupleExclusive.  (All other users of GetTupleForTrigger
still use LockTupleExclusive, so there's no change for anybody other
than FOR EACH ROW BEFORE UPDATE triggers).

At this point, I think I've done all I wanted to do in connection with
this patch, and I intend to commit.  I think this is a good time to get
it committed, so that people can play with it more extensively and
report any breakage I might have caused before we even get into beta.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachments:

  fklocks-28.patch.gz (application/octet-stream, 99.1K) download

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-10 21:22  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 1 reply; 74+ messages in thread

From: Andres Freund @ 2013-01-10 21:22 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote:
> Here's version 28 of this patch.  The only substantive change here from
> v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
> or LockTupleNoKeyExclusive, depending on whether the key columns are
> being modified by the update.  This needs to go through EvalPlanQual, so
> that function is now getting the lock mode as a parameter instead of
> hardcoded LockTupleExclusive.  (All other users of GetTupleForTrigger
> still use LockTupleExclusive, so there's no change for anybody other
> than FOR EACH ROW BEFORE UPDATE triggers).

Is that enough in case of a originally non-key update in read committed
mode that turns into a key update due to a concurrent key update?

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-11 15:11  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2013-01-11 15:11 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

Andres Freund wrote:
> On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote:
> > Here's version 28 of this patch.  The only substantive change here from
> > v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
> > or LockTupleNoKeyExclusive, depending on whether the key columns are
> > being modified by the update.  This needs to go through EvalPlanQual, so
> > that function is now getting the lock mode as a parameter instead of
> > hardcoded LockTupleExclusive.  (All other users of GetTupleForTrigger
> > still use LockTupleExclusive, so there's no change for anybody other
> > than FOR EACH ROW BEFORE UPDATE triggers).
> 
> Is that enough in case of a originally non-key update in read committed
> mode that turns into a key update due to a concurrent key update?

Hm, let me try to work through your example.  You say that a transaction
T1 does a non-key update, and is working through the BEFORE UPDATE
trigger; then transaction T2 does a key update and changes the key
underneath T1?  So at that point T1 becomes a key update, because it's
now using the original key values which are no longer the key?

I don't think this can really happen, because T2 (which is requesting
TupleLockExclusive) would block on the lock that the trigger is grabbing
(TupleLockNoKeyExclusive) on the tuple.  So T2 would sleep until T1 is
committed.


Now, maybe you meant that the BEFORE UPDATE trigger changes the key
value but the user-supplied UPDATE query does not.  So the trigger turns
the no-key update into a key update.  What would happen here is that
GetTupleForTrigger would acquire TupleLockNoKeyExclusive on the tuple,
and later heap_update would acquire TupleLockExclusive.  So there is
lock escalation happening.  This could cause a deadlock against someone
else grabbing a TupleLockKeyShare on the tuple.  I think the answer is
"don't do that", i.e. don't update the key columns in a BEFORE UPDATE
trigger.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-11 15:19  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Andres Freund @ 2013-01-11 15:19 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

On 2013-01-11 12:11:47 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote:
> > > Here's version 28 of this patch.  The only substantive change here from
> > > v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
> > > or LockTupleNoKeyExclusive, depending on whether the key columns are
> > > being modified by the update.  This needs to go through EvalPlanQual, so
> > > that function is now getting the lock mode as a parameter instead of
> > > hardcoded LockTupleExclusive.  (All other users of GetTupleForTrigger
> > > still use LockTupleExclusive, so there's no change for anybody other
> > > than FOR EACH ROW BEFORE UPDATE triggers).
> >
> > Is that enough in case of a originally non-key update in read committed
> > mode that turns into a key update due to a concurrent key update?
>
> Hm, let me try to work through your example.  You say that a transaction
> T1 does a non-key update, and is working through the BEFORE UPDATE
> trigger; then transaction T2 does a key update and changes the key
> underneath T1?  So at that point T1 becomes a key update, because it's
> now using the original key values which are no longer the key?
>
> I don't think this can really happen, because T2 (which is requesting
> TupleLockExclusive) would block on the lock that the trigger is grabbing
> (TupleLockNoKeyExclusive) on the tuple.  So T2 would sleep until T1 is
> committed.

No, I was thinking about an update without triggers present.

T0: CREATE TABLE tbl(id serial pk, name text unique, data text);
T1: BEGIN; -- read committed
T1: UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; /* key update of row id = 1 */
T2: BEGIN; -- read committed
T2: UPDATE tbl SET name = 'blarg', data = 'blarg' WHERE id = 1; /* no key update, waiting */
T1: COMMIT;
T2: /* UPDATE follows to updated row, due to the changed name its a key update now */

Does that make sense?

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-11 16:10  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 1 reply; 74+ messages in thread

From: Alvaro Herrera @ 2013-01-11 16:10 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

Andres Freund wrote:

> No, I was thinking about an update without triggers present.
> 
> T0: CREATE TABLE tbl(id serial pk, name text unique, data text);
> T1: BEGIN; -- read committed
> T1: UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; /* key update of row id = 1 */
> T2: BEGIN; -- read committed
> T2: UPDATE tbl SET name = 'blarg', data = 'blarg' WHERE id = 1; /* no key update, waiting */
> T1: COMMIT;
> T2: /* UPDATE follows to updated row, due to the changed name its a key update now */
> 
> Does that make sense?

So I guess your question is "is T2 now holding a TupleLockExclusive
lock?"  To answer it, I turned your example into a isolationtester spec:

setup
{
CREATE TABLE tbl(id serial primary key, name text unique, data text);
INSERT INTO tbl VALUES (1, 'blarg', 'no data');
}

teardown
{
DROP TABLE tbl;
}

session "s1"
step "s1b" { BEGIN; }
step "s1u" { UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; }
step "s1c" { COMMIT; }

session "s2"
step "s2b" { BEGIN; }
step "s2u" { UPDATE tbl SET name = 'blarg', data = 'blarg' WHERE id = 1; }
step "s2c" { COMMIT; }

session "s3"
step "s3l" { SELECT * FROM tbl FOR KEY SHARE; }

permutation "s1b" "s1u" "s2b" "s2u" "s1c" "s3l" "s2c"


And the results:
Parsed test spec with 3 sessions

starting permutation: s1b s1u s2b s2u s1c s3l s2c
step s1b: BEGIN;
step s1u: UPDATE tbl SET name = 'foo' WHERE name = 'blarg';
step s2b: BEGIN;
step s2u: UPDATE tbl SET name = 'blarg', data = 'blarg' WHERE id = 1; <waiting ...>
step s1c: COMMIT;
step s2u: <... completed>
step s3l: SELECT * FROM tbl FOR KEY SHARE; <waiting ...>
step s2c: COMMIT;
step s3l: <... completed>
id             name           data           

1              blarg          blarg          


So session 3 is correctly waiting for session 2 to finish before being
ablt to grab its FOR KEY SHARE lock, indicating that session 2 is
holding a FOR UPDATE lock.  Good.

If I change session 1 to update the data column instead of name, session
3 no longer needs to wait for session 2, meaning session 2 now only
grabs a FOR NO KEY UPDATE lock.  Also good.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-11 16:31  Andres Freund <andres@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  0 siblings, 0 replies; 74+ messages in thread

From: Andres Freund @ 2013-01-11 16:31 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

On 2013-01-11 13:10:49 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > No, I was thinking about an update without triggers present.
> >
> > T0: CREATE TABLE tbl(id serial pk, name text unique, data text);
> > T1: BEGIN; -- read committed
> > T1: UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; /* key update of row id = 1 */
> > T2: BEGIN; -- read committed
> > T2: UPDATE tbl SET name = 'blarg', data = 'blarg' WHERE id = 1; /* no key update, waiting */
> > T1: COMMIT;
> > T2: /* UPDATE follows to updated row, due to the changed name its a key update now */
> >
> > Does that make sense?
>
> So I guess your question is "is T2 now holding a TupleLockExclusive
> lock?"  To answer it, I turned your example into a isolationtester spec:

Great! I reread the code and it does make sense the way its implemented
now. I misremembered something...

I vote for adding that spectest including some appropriate permutations.

FWIW: Looks good to me. It could use another pair of eyes, but I guess
that will have to come by being used.

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-18 20:02  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 2 replies; 74+ messages in thread

From: Alvaro Herrera @ 2013-01-18 20:02 UTC (permalink / raw)
  To: Erik Rijkers <er@xs4all.nl>; +Cc: Kevin Grittner <kgrittn@mail.com>; pgsql-hackers@postgresql.org, Andres Freund <andres@2ndquadrant.com>

Alvaro Herrera wrote:
> Here's version 28 of this patch.  The only substantive change here from
> v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
> or LockTupleNoKeyExclusive, depending on whether the key columns are
> being modified by the update.  This needs to go through EvalPlanQual, so
> that function is now getting the lock mode as a parameter instead of
> hardcoded LockTupleExclusive.  (All other users of GetTupleForTrigger
> still use LockTupleExclusive, so there's no change for anybody other
> than FOR EACH ROW BEFORE UPDATE triggers).
> 
> At this point, I think I've done all I wanted to do in connection with
> this patch, and I intend to commit.  I think this is a good time to get
> it committed, so that people can play with it more extensively and
> report any breakage I might have caused before we even get into beta.

While trying this out this morning I noticed a bug in the XLog code:
trying to lock the updated version of a tuple when the page that
contains the updated version requires a backup block, would cause this:

PANIC:  invalid xlog record length 0

The reason is that there is an (unknown to me) rule that there must be
some data not associated with a buffer:

	/*
	 * NOTE: We disallow len == 0 because it provides a useful bit of extra
	 * error checking in ReadRecord.  This means that all callers of
	 * XLogInsert must supply at least some not-in-a-buffer data. [...]
	 */

This seems pretty strange to me.  And having the rule be spelled out
only in a comment within XLogInsert and not at its top, and not nearby
the XLogRecData struct definition either, seems pretty strange to me.
I wonder how come every PG hacker except me knows this.

For the curious, I attach an isolationtester spec file I used to
reproduce the problem (and verify the fix).

To fix the crash I needed to do this:

inline patch 1: src/backend/access/heap/heapam.c (+12/-7 lines) download inline-1.patch
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 99fced1..9762890 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -4838,7 +4838,7 @@ l4:
 		{
 			xl_heap_lock_updated xlrec;
 			XLogRecPtr	recptr;
-			XLogRecData	rdata;
+			XLogRecData	rdata[2];
 			Page		page = BufferGetPage(buf);
 
 			xlrec.target.node = rel->rd_node;
@@ -4846,13 +4846,18 @@ l4:
 			xlrec.xmax = new_xmax;
 			xlrec.infobits_set = compute_infobits(new_infomask, new_infomask2);
 
-			rdata.data = (char *) &xlrec;
-			rdata.len = SizeOfHeapLockUpdated;
-			rdata.buffer = buf;
-			rdata.buffer_std = true;
-			rdata.next = NULL;
+			rdata[0].data = (char *) &xlrec;
+			rdata[0].len = SizeOfHeapLockUpdated;
+			rdata[0].buffer = InvalidBuffer;
+			rdata[0].next = &(rdata[1]);
+
+			rdata[1].data = NULL;
+			rdata[1].len = 0;
+			rdata[1].buffer = buf;
+			rdata[1].buffer_std = true;
+			rdata[1].next = NULL;
 
-			recptr = XLogInsert(RM_HEAP2_ID, XLOG_HEAP2_LOCK_UPDATED, &rdata);
+			recptr = XLogInsert(RM_HEAP2_ID, XLOG_HEAP2_LOCK_UPDATED, rdata);
 
 			PageSetLSN(page, recptr);
 			PageSetTLI(page, ThisTimeLineID);

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachments:

xlog-lock-updated.spec (text/plain, 621B) download
setup
{
  CREATE TABLE foo (
	key		serial PRIMARY KEY,
	value	int
  );

  INSERT INTO foo SELECT value FROM generate_series(1, 226) AS value;
}

teardown
{
  DROP TABLE foo;
}

session "s1"
step "s1b"	{ BEGIN ISOLATION LEVEL REPEATABLE READ; }
step "s1s"	{ SELECT * FROM foo LIMIT 0; }	# obtain snapshot
step "s1l"	{ SELECT * FROM foo WHERE key = 1 FOR KEY SHARE; } # obtain lock
step "s1c"	{ COMMIT; }

session "s2"
step "s2b"  { BEGIN; }
step "s2u"	{ UPDATE foo SET value = 2 WHERE key = 1; }
step "s2c"	{ COMMIT; }

session "s3"
step "s3ck" { CHECKPOINT; }

permutation "s1b" "s1s" "s2b" "s2u" "s3ck" "s1l" "s1c" "s2c"

^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-18 20:24  Simon Riggs <simon@2ndQuadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 0 replies; 74+ messages in thread

From: Simon Riggs @ 2013-01-18 20:24 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@2ndquadrant.com>

On 18 January 2013 20:02, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> XLOG_HEAP2_LOCK_UPDATED

Every xlog record needs to know where to put the block.

Compare with XLOG_HEAP_LOCK

xlrec.target.node = relation->rd_node;

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-18 20:37  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 1 reply; 74+ messages in thread

From: Tom Lane @ 2013-01-18 20:37 UTC (permalink / raw)
  To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers@postgresql.org, Andres Freund <andres@2ndquadrant.com>

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> The reason is that there is an (unknown to me) rule that there must be
> some data not associated with a buffer:

> 	/*
> 	 * NOTE: We disallow len == 0 because it provides a useful bit of extra
> 	 * error checking in ReadRecord.  This means that all callers of
> 	 * XLogInsert must supply at least some not-in-a-buffer data. [...]
> 	 */

> This seems pretty strange to me.  And having the rule be spelled out
> only in a comment within XLogInsert and not at its top, and not nearby
> the XLogRecData struct definition either, seems pretty strange to me.
> I wonder how come every PG hacker except me knows this.

I doubt it ever came up before.  What use is logging only the content of
a buffer page?  Surely you'd need to know, for example, which relation
and page number it is from.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-18 20:46  Andres Freund <andres@2ndquadrant.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 1 reply; 74+ messages in thread

From: Andres Freund @ 2013-01-18 20:46 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > The reason is that there is an (unknown to me) rule that there must be
> > some data not associated with a buffer:
> 
> > 	/*
> > 	 * NOTE: We disallow len == 0 because it provides a useful bit of extra
> > 	 * error checking in ReadRecord.  This means that all callers of
> > 	 * XLogInsert must supply at least some not-in-a-buffer data. [...]
> > 	 */
> 
> > This seems pretty strange to me.  And having the rule be spelled out
> > only in a comment within XLogInsert and not at its top, and not nearby
> > the XLogRecData struct definition either, seems pretty strange to me.
> > I wonder how come every PG hacker except me knows this.
> 
> I doubt it ever came up before.  What use is logging only the content of
> a buffer page?  Surely you'd need to know, for example, which relation
> and page number it is from.

It only got to be a length of 0 because the the data got removed due to
a logged full page write. And the backup block contains the data about
which blocks it is logging in itself.
I wonder if the check shouldn't just check write_len instead, directly
below the loop that ads backup blocks.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-18 21:01  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Andres Freund <andres@2ndquadrant.com>
  0 siblings, 2 replies; 74+ messages in thread

From: Tom Lane @ 2013-01-18 21:01 UTC (permalink / raw)
  To: Andres Freund <andres@2ndquadrant.com>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
>> I doubt it ever came up before.  What use is logging only the content of
>> a buffer page?  Surely you'd need to know, for example, which relation
>> and page number it is from.

> It only got to be a length of 0 because the the data got removed due to
> a logged full page write. And the backup block contains the data about
> which blocks it is logging in itself.

And if the full-page-image case *hadn't* been invoked, what then?  I
still don't see a very good argument for xlog records with no fixed
data.

> I wonder if the check shouldn't just check write_len instead, directly
> below the loop that ads backup blocks.

We're not changing this unless you can convince me that the read-side
error check mentioned in the comment is useless.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-18 21:13  Andres Freund <andres@2ndquadrant.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  1 sibling, 0 replies; 74+ messages in thread

From: Andres Freund @ 2013-01-18 21:13 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

On 2013-01-18 16:01:18 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
> >> I doubt it ever came up before.  What use is logging only the content of
> >> a buffer page?  Surely you'd need to know, for example, which relation
> >> and page number it is from.
> 
> > It only got to be a length of 0 because the the data got removed due to
> > a logged full page write. And the backup block contains the data about
> > which blocks it is logging in itself.
> 
> And if the full-page-image case *hadn't* been invoked, what then?  I
> still don't see a very good argument for xlog records with no fixed
> data.

In that case data would have been logged?

The code in question was:

            xl_heap_lock_updated xlrec;
            xlrec.target.node = rel->rd_node;
...
            xlrec.xmax = new_xmax;

-           rdata.data = (char *) &xlrec;
-           rdata.len = SizeOfHeapLockUpdated;
-           rdata.buffer = buf;
-           rdata.buffer_std = true;
-           rdata.next = NULL;
-           recptr = XLogInsert(RM_HEAP2_ID, XLOG_HEAP2_LOCK_UPDATED, &rdata);

Other wal logging code (and fklocks now as well) just put those into
two XLogRecData blocks to avoid the issue.

> > I wonder if the check shouldn't just check write_len instead, directly
> > below the loop that ads backup blocks.
> 
> We're not changing this unless you can convince me that the read-side
> error check mentioned in the comment is useless.

Youre right, the read side check is worth quite a bit. I think I am
retracting my suggestion.
I guess the amount of extra data thats uselessly logged although never
used in in the redo functions doesn't really amass to anything
significant in comparison to the backup block data.


Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-19 10:21  Simon Riggs <simon@2ndQuadrant.com>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  1 sibling, 0 replies; 74+ messages in thread

From: Simon Riggs @ 2013-01-19 10:21 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@2ndquadrant.com>; Alvaro Herrera <alvherre@2ndquadrant.com>; Erik Rijkers <er@xs4all.nl>; Kevin Grittner <kgrittn@mail.com>; pgsql-hackers

On 18 January 2013 21:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
>>> I doubt it ever came up before.  What use is logging only the content of
>>> a buffer page?  Surely you'd need to know, for example, which relation
>>> and page number it is from.
>
>> It only got to be a length of 0 because the the data got removed due to
>> a logged full page write. And the backup block contains the data about
>> which blocks it is logging in itself.
>
> And if the full-page-image case *hadn't* been invoked, what then?  I
> still don't see a very good argument for xlog records with no fixed
> data.
>
>> I wonder if the check shouldn't just check write_len instead, directly
>> below the loop that ads backup blocks.
>
> We're not changing this unless you can convince me that the read-side
> error check mentioned in the comment is useless.


There's some confusion here, I think. Alvaro wasn't proposing a WAL
record that had no fixed data.

The current way XLogRecData works is that if you put data and buffer
together on the same chunk then we optimise the data away if we take a
backup block.

Alvaro chose what looks like the right way to do this when you have
simple data: use one XLogRecData chunk and let the data part get
optimised away. But doing that results in a WAL record that has a
backup block, plus data of 0 length, which then fails the later check.

All current code gets around this by including multiple XLogRecData
chunks, which results in including additional data that is superfluous
when the backup block is present. Alvaro was questioning this; I
didn't understand that either when he said it, but I do now.

The zero length check should stay, definitely.

What this looks like is that further compression of the WAL is
possible, but given its alongside backup blocks, that's on the order
of a 1% saving, so probably isn't worth considering right now. The way
to do that would to include a small token to show record has been
optimised, rather than being zero length.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

* Re: foreign key locks
@ 2013-01-23 18:33  Alvaro Herrera <alvherre@2ndquadrant.com>
  parent: Alvaro Herrera <alvherre@2ndquadrant.com>
  1 sibling, 0 replies; 74+ messages in thread

From: Alvaro Herrera @ 2013-01-23 18:33 UTC (permalink / raw)
  To: pgsql-hackers

I just pushed this patch to the master branch.  There was a
corresponding catversion bump and pg_control version bump.  I have
verified that "make check-world" passes on my machine, as well as
isolation tests and pg_upgrade.

Tom Lane said at one point "this is too complex to maintain".  Several
times during the development I feared he might well be right.  I am sure
he will be discovering many oversights and poor design choices, when
gets around to reviewing the code; hopefully some extra effort will be
all that's needed to make the whole thing work sanely and not eat
anyone's data.  I just hope that nothing so serious comes up that the
patch will need to be reverted completely.

This patch is the result of the work of many people.  I am not allowed
to mention the patch sponsors in the commit message, so I'm doing it
here: first and foremost I need to thank my previous and current
employers Command Prompt and 2ndQuadrant -- they were extremely kind in
allowing me to work on this for days on end (and not all of it was
supported by financial sponsors).  Joel Jacobson started the whole
effort by posting a screencast of a problem his company was having; I
hope they found a workaround in the meantime, because his post was in
mid 2010.  The key idea of this patch' design came from Simon Riggs;
Noah Misch provided additional design advice that allowed the project
torun to completion.  Noah and Andres Freund spent considerable time
reviewing early versions of this patch; they uncovered many embarrasing
bugs in my implementation.  Kevin Grittner, Robert Haas, and others,
provided useful comments as well.  Noah Misch, Andres Freund, Marti
Raudsepp and Alexander Shulgin also provided bits of code.

Any bugs that remain are, of course, my own fault only.

Financial support came from

* Command Prompt Inc. of Washington, US
* 2ndQuadrant Ltd. of United Kingdom
* Trustly (then Glue Finance) of Sweden
* Novozymes A/S of Denmark
* MailerMailer LLC of Maryland, US
* PostgreSQL Experts, Inc. of California, US.

My sincerest thanks to everyone.


I seriously hope that no patch of mine ever becomes this monstruous
again.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



^ permalink  raw  reply  [nested|flat] 74+ messages in thread

end of thread, other threads:[~2013-01-23 18:33 UTC | newest]

Thread overview: 74+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2012-06-14 16:41 foreign key locks Alvaro Herrera <alvherre@alvh.no-ip.org>
2012-06-20 14:28 ` Jaime Casanova <jaime@2ndquadrant.com>
2012-06-20 16:54   ` Tom Lane <tgl@sss.pgh.pa.us>
2012-06-21 19:47     ` Alvaro Herrera <alvherre@commandprompt.com>
2012-06-23 22:38 Re: foreign key locks Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-06-25 03:24 ` Alvaro Herrera <alvherre@commandprompt.com>
2012-06-25 03:47   ` Alvaro Herrera <alvherre@commandprompt.com>
2012-06-27 12:40 Re: foreign key locks Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-06-27 15:27 ` Alvaro Herrera <alvherre@commandprompt.com>
2012-06-29 23:17 ` Alvaro Herrera <alvherre@commandprompt.com>
2012-06-29 23:26   ` Alvaro Herrera <alvherre@commandprompt.com>
2012-07-05 17:02   ` Alvaro Herrera <alvherre@commandprompt.com>
2012-07-05 22:44   ` Alvaro Herrera <alvherre@commandprompt.com>
2012-08-17 20:23     ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-08-22 21:31       ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-08-25 01:51         ` Robert Haas <robertmhaas@gmail.com>
2012-08-27 19:28         ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-08-31 04:59           ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-10-11 15:36             ` Andres Freund <andres@2ndquadrant.com>
2012-10-11 16:10               ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-10-12 21:09                 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-10-18 19:58             ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-10-19 15:40               ` Noah Misch <noah@leadboat.com>
2012-10-26 22:06               ` Andres Freund <andres@2ndquadrant.com>
2012-10-28 22:47                 ` Simon Riggs <simon@2ndQuadrant.com>
2012-10-29 11:27                   ` Andres Freund <andres@2ndquadrant.com>
2012-10-29 12:08                     ` Simon Riggs <simon@2ndQuadrant.com>
2012-11-14 15:23                 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-11-14 16:27                   ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-11-16 00:24                     ` Noah Misch <noah@leadboat.com>
2012-11-16 16:17                       ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-11-16 16:31                         ` Andres Freund <andres@2ndquadrant.com>
2012-11-17 03:31                           ` Noah Misch <noah@leadboat.com>
2012-11-17 14:20                             ` Andres Freund <andres@2ndquadrant.com>
2012-11-17 14:56                               ` Noah Misch <noah@leadboat.com>
2012-11-17 16:07                               ` Andres Freund <andres@2ndquadrant.com>
2012-11-17 18:25                                 ` Noah Misch <noah@leadboat.com>
2012-11-16 14:55                     ` Andres Freund <andres@2ndquadrant.com>
2012-11-19 11:58                     ` Andres Freund <andres@2ndquadrant.com>
2012-11-20 20:36                       ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-11-20 21:15                         ` Andres Freund <andres@2ndquadrant.com>
2012-11-26 19:45                           ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-11-27 15:07                             ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-11-19 12:12                     ` Andres Freund <andres@2ndquadrant.com>
2012-10-29 12:18 Re: foreign key locks Kevin Grittner <kgrittn@mail.com>
2012-10-31 19:35 ` Noah Misch <noah@leadboat.com>
2012-10-31 20:02   ` Simon Riggs <simon@2ndQuadrant.com>
2012-10-31 20:22     ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-10-31 21:01       ` Noah Misch <noah@leadboat.com>
2012-11-05 13:37         ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2012-11-05 13:48           ` Andres Freund <andres@2ndquadrant.com>
2012-11-13 22:07         ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-11-05 22:22       ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-11-28 21:22 Re: foreign key locks Kevin Grittner <kgrittn@mail.com>
2012-11-29 15:23 Re: foreign key locks Kevin Grittner <kgrittn@mail.com>
2012-11-29 16:02 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-11-29 16:16   ` Alvaro Herrera <alvherre@2ndquadrant.com>
2012-12-22 09:53     ` Erik Rijkers <er@xs4all.nl>
2012-12-22 11:50       ` Andres Freund <andres@2ndquadrant.com>
2012-12-28 20:48       ` Alvaro Herrera <alvherre@2ndquadrant.com>
2013-01-10 21:00         ` Alvaro Herrera <alvherre@2ndquadrant.com>
2013-01-10 21:22           ` Andres Freund <andres@2ndquadrant.com>
2013-01-11 15:11             ` Alvaro Herrera <alvherre@2ndquadrant.com>
2013-01-11 15:19               ` Andres Freund <andres@2ndquadrant.com>
2013-01-11 16:10                 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2013-01-11 16:31                   ` Andres Freund <andres@2ndquadrant.com>
2013-01-18 20:02           ` Alvaro Herrera <alvherre@2ndquadrant.com>
2013-01-18 20:24             ` Simon Riggs <simon@2ndQuadrant.com>
2013-01-18 20:37             ` Tom Lane <tgl@sss.pgh.pa.us>
2013-01-18 20:46               ` Andres Freund <andres@2ndquadrant.com>
2013-01-18 21:01                 ` Tom Lane <tgl@sss.pgh.pa.us>
2013-01-18 21:13                   ` Andres Freund <andres@2ndquadrant.com>
2013-01-19 10:21                   ` Simon Riggs <simon@2ndQuadrant.com>
2013-01-23 18:33     ` Alvaro Herrera <alvherre@2ndquadrant.com>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox