Stamp 9.2.8.
commit : f07692e1906c5f78d4dc4f777ade31cbfdb0069e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Mar 2014 15:36:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Mar 2014 15:36:46 -0400
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Release notes for 9.3.4, 9.2.8, 9.1.13, 9.0.17, 8.4.21.
commit : 00e063a23277a8aa2fcf522baec394b2846dcafb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Mar 2014 15:28:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Mar 2014 15:28:29 -0400
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
Fix bug in clean shutdown of walsender that pg_receiving is connecting to.
commit : 7899aa356a06181dfa4f958ea2f7276ec7253da1
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 17 Mar 2014 20:41:52 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 17 Mar 2014 20:41:52 +0900
On clean shutdown, walsender waits for all WAL to be replicated to a standby,
and exits. It determined whether that replication had been completed by
checking whether its sent location had been equal to a standby's flush
location. Unfortunately this condition never becomes true when the standby
such as pg_receivexlog which always returns an invalid flush location is
connecting to walsender, and then walsender waits forever.
This commit changes walsender so that it just checks a standby's write
location if a flush location is invalid.
Back-patch to 9.1 where enough infrastructure for this exists.
M src/backend/replication/walsender.c
plperl: Fix memory leak in hek2cstr
commit : ba5946e8696e9629e77cc1e9c2c8bc722798a0a0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 16 Mar 2014 23:22:22 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 16 Mar 2014 23:22:22 -0300
Backpatch all the way back to 9.1, where it was introduced by commit
50d89d42.
Reported by Sergey Burladyan in #9223
Author: Alex Hunsaker
M src/pl/plperl/plperl.c
Translation updates
commit : 3205d6b24e60eb7e7d2749b9447d5df98a6d84b9
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 16 Mar 2014 21:43:13 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 16 Mar 2014 21:43:13 -0400
M src/backend/po/fr.po
M src/backend/po/pt_BR.po
Fix unportable shell-script syntax in pg_upgrade's test.sh.
commit : d24d6691930e5f3a95e9daece2f299a076c80c15
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Mar 2014 21:55:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Mar 2014 21:55:10 -0400
I discovered the hard way that on some old shells, the locution
FOO="" unset FOO
does not behave the same as
FOO=""; unset FOO
and in fact leaves FOO set to an empty string. test.sh was inconsistently
spelling it different ways on adjacent lines.
This got broken relatively recently, in commit c737a2e56, so the lack of
field reports to date doesn't represent a lot of evidence that the problem
is rare.
M contrib/pg_upgrade/test.sh
Fix advertised dispsize for libpq's sslmode connection parameter.
commit : 0bdeb1d51d910e0e19dec3ce0396903ae7de5c74
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Mar 2014 21:43:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Mar 2014 21:43:46 -0400
"8" was correct back when "disable" was the longest allowed value, but
since "verify-full" was added, it should be "12". Given the lack of
complaints, I wouldn't be surprised if nobody is actually using these
values ... but still, if they're in the API, they should be right.
Noticed while pursuing a different problem. It's been wrong for quite
a long time, so back-patch to all supported branches.
M src/interfaces/libpq/fe-connect.c
Update time zone data files to tzdata release 2014a.
commit : f2063b379fe1e3a0d54ca2dd91839f1dac4d0c95
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Mar 2014 13:36:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Mar 2014 13:36:07 -0400
DST law changes in Fiji, Turkey; historical changes in Israel, Ukraine.
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/europe
M src/timezone/data/northamerica
M src/timezone/data/southamerica
Prevent interrupts while reporting non-ERROR elog messages.
commit : 7a289bb6d7f68393a9a4d7cde47e4440835d8dd5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Mar 2014 20:59:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Mar 2014 20:59:48 -0400
This should eliminate the risk of recursive entry to syslog(3), which
appears to be the cause of the hang reported in bug #9551 from James
Morton.
Arguably, the real problem here is auth.c's willingness to turn on
ImmediateInterruptOK while executing fairly wide swaths of backend code.
We may well need to work at narrowing the code ranges in which the
authentication_timeout interrupt is enabled. For the moment, though,
this is a cheap and reasonably noninvasive fix for a field-reported
failure; the other approach would be complex and not necessarily
bug-free itself.
Back-patch to all supported branches.
M src/backend/utils/error/elog.c
Avoid transaction-commit race condition while receiving a NOTIFY message.
commit : bbe9621a90a108a1ce6a018dd42afe36b8a6cba9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Mar 2014 12:03:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Mar 2014 12:03:00 -0400
Use TransactionIdIsInProgress, then TransactionIdDidCommit, to distinguish
whether a NOTIFY message's originating transaction is in progress,
committed, or aborted. The previous coding could accept a message from a
transaction that was still in-progress according to the PGPROC array;
if the client were fast enough at starting a new transaction, it might fail
to see table rows added/updated by the message-sending transaction. Which
of course would usually be the point of receiving the message. We noted
this type of race condition long ago in tqual.c, but async.c overlooked it.
The race condition probably cannot occur unless there are multiple NOTIFY
senders in action, since an individual backend doesn't send NOTIFY signals
until well after it's done committing. But if two senders commit in close
succession, it's certainly possible that we could see the second sender's
message within the race condition window while responding to the signal
from the first one.
Per bug #9557 from Marko Tiikkaja. This patch is slightly more invasive
than what he proposed, since it removes the now-redundant
TransactionIdDidAbort call.
Back-patch to 9.0, where the current NOTIFY implementation was introduced.
M src/backend/commands/async.c
In WAL replay, restore GIN metapage unconditionally to avoid torn page.
commit : 91f932cf47fd0e0825b2ec92a06d24648d1ff128
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 12 Mar 2014 09:59:49 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 12 Mar 2014 09:59:49 +0200
We don't take a full-page image of the GIN metapage; instead, the WAL record
contains all the information required to reconstruct it from scratch. But
to avoid torn page hazards, we must re-initialize it from the WAL record
every time, even if it already has a greater LSN, similar to how normal full
page images are restored.
This was highly unlikely to cause any problems in practice, because the GIN
metapage is small. We rely on an update smaller than a 512 byte disk sector
to be atomic elsewhere, at least in pg_control. But better safe than sorry,
and this would be easy to overlook if more fields are added to the metapage
so that it's no longer small.
Reported by Noah Misch. Backpatch to all supported versions.
M src/backend/access/gin/ginxlog.c
Fix tracking of psql script line numbers during \copy from another place.
commit : b315b767f7a3a1fb50c51739916de295be37487a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Mar 2014 15:47:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Mar 2014 15:47:13 -0400
Commit 08146775acd8bfe0fcc509c71857abb928697171 changed do_copy() to
temporarily scribble on pset.cur_cmd_source. That was a mighty ugly bit of
code in any case, but in particular it broke handleCopyIn's ability to tell
whether it was reading from the current script source file (in which case
pset.lineno should be incremented for each line of COPY data), or from
someplace else (in which case it shouldn't). The former case still worked,
the latter not so much. The visible effect was that line numbers reported
for errors in a script file would be wrong if there were an earlier \copy
that was reading anything other than inline-in-the-script-file data.
To fix, introduce another pset field that holds the file do_copy wants the
COPY code to use. This is a little bit ugly, but less so than passing the
file down explicitly through several layers that aren't COPY-specific.
Extracted from a larger patch by Kumar Rajeev Rastogi; that patch also
changes printing of COPY command tags, which is not a bug fix and shouldn't
get back-patched. This particular idea was from a suggestion by Amit
Khandekar, if I'm reading the thread correctly.
Back-patch to 9.2 where the faulty code was introduced.
M src/bin/psql/common.c
M src/bin/psql/copy.c
M src/bin/psql/settings.h
M src/bin/psql/startup.c
release notes: add item missed in 9.2.5 release
commit : 2570d936ff2e03cc4e1d8a8b3972459662b46830
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 7 Mar 2014 13:45:38 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 7 Mar 2014 13:45:38 -0500
Item is "Prevent errors in WAL replay due to references to uninitialized
empty pages".
Report and text by Andres Freund
Backpatch through 9.2.
M doc/src/sgml/release-9.2.sgml
Fix dangling smgr_owner pointer when a fake relcache entry is freed.
commit : f650387b5038b50407d33d1e9b7590483bb11a72
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Mar 2014 13:25:11 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Mar 2014 13:25:11 +0200
A fake relcache entry can "own" a SmgrRelation object, like a regular
relcache entry. But when it was free'd, the owner field in SmgrRelation
was not cleared, so it was left pointing to free'd memory.
Amazingly this apparently hasn't caused crashes in practice, or we would've
heard about it earlier. Andres found this with Valgrind.
Report and fix by Andres Freund, with minor modifications by me. Backpatch
to all supported versions.
M src/backend/access/transam/xlogutils.c
M src/backend/storage/smgr/smgr.c
M src/include/storage/smgr.h
Avoid memcpy() with same source and destination address.
commit : 4afc3f0faa3b1f86c23dabe716c3324962543fa6
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Mar 2014 13:13:33 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Mar 2014 13:13:33 +0200
The behavior of that is undefined, although unlikely to lead to problems in
practice.
Found by running regression tests with Valgrind.
M src/backend/tsearch/dict_ispell.c
M src/backend/utils/adt/tsvector.c
Fix name of syslog_ident GUC in docs.
commit : 6f529325ad269fe5f76160779d1d41799c6524c9
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Mar 2014 10:35:37 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Mar 2014 10:35:37 +0200
Michael Paquier
M doc/src/sgml/config.sgml
Avoid getting more than AccessShareLock when deparsing a query.
commit : 5ec41e345accd6d08142337aff071e9661fa55c8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Mar 2014 19:31:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Mar 2014 19:31:12 -0500
In make_ruledef and get_query_def, we have long used AcquireRewriteLocks
to ensure that the querytree we are about to deparse is up-to-date and
the schemas of the underlying relations aren't changing. Howwever, that
function thinks the query is about to be executed, so it acquires locks
that are stronger than necessary for the purpose of deparsing. Thus for
example, if pg_dump asks to deparse a rule that includes "INSERT INTO t",
we'd acquire RowExclusiveLock on t. That results in interference with
concurrent transactions that might for example ask for ShareLock on t.
Since pg_dump is documented as being purely read-only, this is unexpected.
(Worse, it used to actually be read-only; this behavior dates back only
to 8.1, cf commit ba4200246.)
Fix this by adding a parameter to AcquireRewriteLocks to tell it whether
we want the "real" execution locks or only AccessShareLock.
Report, diagnosis, and patch by Dean Rasheed. Back-patch to all supported
branches.
M src/backend/rewrite/rewriteHandler.c
M src/backend/utils/adt/ruleutils.c
M src/include/rewrite/rewriteHandler.h
Do wal_level and hot standby checks when doing crash-then-archive recovery.
commit : e7ec05562ed754fb60f75ea83efe103266a92015
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 5 Mar 2014 14:41:55 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 5 Mar 2014 14:41:55 +0200
CheckRequiredParameterValues() should perform the checks if archive recovery
was requested, even if we are going to perform crash recovery first.
Reported by Kyotaro HORIGUCHI. Backpatch to 9.2, like the crash-then-archive
recovery mode.
M src/backend/access/transam/xlog.c
Fix lastReplayedEndRecPtr calculation when starting from shutdown checkpoint.
commit : 931dc26b0d2ba9b2d174119b7ff277b977d03619
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 5 Mar 2014 13:27:18 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 5 Mar 2014 13:27:18 +0200
When entering crash recovery followed by archive recovery, and the latest
checkpoint is a shutdown checkpoint, and there are no more WAL records to
replay before transitioning from crash to archive recovery, we would not
immediately allow read-only connections in hot standby mode even if we
could. That's because when starting from a shutdown checkpoint, we set
lastReplayedEndRecPtr incorrectly to the record before the checkpoint
record, instead of the checkpoint record itself. We don't run the redo
routine of the shutdown checkpoint record, but starting recovery from it
goes through the same motions, so it should be considered as replayed.
Reported by Kyotaro HORIGUCHI. All versions with hot standby are affected,
so backpatch to 9.0.
M src/backend/access/transam/xlog.c
Allow regex operations to be terminated early by query cancel requests.
commit : 03e6423fc1eb45af18d49fee741a5536873ff626
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Mar 2014 15:21:04 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Mar 2014 15:21:04 -0500
The regex code didn't have any provision for query cancel; which is
unsurprising given its non-Postgres origin, but still problematic since
some operations can take a long time. Introduce a callback function to
check for a pending query cancel or session termination request, and
call it in a couple of strategic spots where we can make the regex code
exit with an error indicator.
If we ever actually split out the regex code as a standalone library,
some additional work will be needed to let the cancel callback function
be specified externally to the library. But that's straightforward
(certainly so by comparison to putting the locale-dependent character
classification logic on a similar arms-length basis), and there seems
no need to do it right now.
A bigger issue is that there may be more places than these two where
we need to check for cancels. We can always add more checks later,
now that the infrastructure is in place.
Since there are known examples of not-terribly-long regexes that can
lock up a backend for a long time, back-patch to all supported branches.
I have hopes of fixing the known performance problems later, but adding
query cancel ability seems like a good idea even if they were all fixed.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
M src/backend/regex/regexec.c
M src/backend/utils/adt/regexp.c
M src/backend/utils/adt/varlena.c
M src/include/regex/regerrs.h
M src/include/regex/regex.h
M src/include/regex/regguts.h
Use SnapshotDirty rather than an active snapshot to probe index endpoints.
commit : 00283cae1b78174e27b39c5102ef362a8766323a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Feb 2014 16:04:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Feb 2014 16:04:12 -0500
If there are lots of uncommitted tuples at the end of the index range,
get_actual_variable_range() ends up fetching each one and doing an MVCC
visibility check on it, until it finally hits a visible tuple. This is
bad enough in isolation, considering that we don't need an exact answer
only an approximate one. But because the tuples are not yet committed,
each visibility check does a TransactionIdIsInProgress() test, which
involves scanning the ProcArray. When multiple sessions do this
concurrently, the ensuing contention results in horrid performance loss.
20X overall throughput loss on not-too-complicated queries is easy to
demonstrate in the back branches (though someone's made it noticeably
less bad in HEAD).
We can dodge the problem fairly effectively by using SnapshotDirty rather
than a normal MVCC snapshot. This will cause the index probe to take
uncommitted tuples as good, so that we incur only one tuple fetch and test
even if there are many such tuples. The extent to which this degrades the
estimate is debatable: it's possible the result is actually a more accurate
prediction than before, if the endmost tuple has become committed by the
time we actually execute the query being planned. In any case, it's not
very likely that it makes the estimate a lot worse.
SnapshotDirty will still reject tuples that are known committed dead, so
we won't give bogus answers if an invalid outlier has been deleted but not
yet vacuumed from the index. (Because btrees know how to mark such tuples
dead in the index, we shouldn't have a big performance problem in the case
that there are many of them at the end of the range.) This consideration
motivates not using SnapshotAny, which was also considered as a fix.
Note: the back branches were using SnapshotNow instead of an MVCC snapshot,
but the problem and solution are the same.
Per performance complaints from Bartlomiej Romanski, Josh Berkus, and
others. Back-patch to 9.0, where the issue was introduced (by commit
40608e7f949fb7e4025c0ddd5be01939adc79eec).
M src/backend/utils/adt/selfuncs.c
Remove broken code that tried to handle OVERLAPS with a single argument.
commit : d7cd6a9d52b3c4a354c7ddac06aa6998e8505d44
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Feb 2014 12:44:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Feb 2014 12:44:27 -0500
The SQL standard says that OVERLAPS should have a two-element row
constructor on each side. The original coding of OVERLAPS support in
our grammar attempted to extend that by allowing a single-element row
constructor, which it internally duplicated ... or tried to, anyway.
But that code has certainly not worked since our List infrastructure was
rewritten in 2004, and I'm none too sure it worked before that. As it
stands, it ends up building a List that includes itself, leading to
assorted undesirable behaviors later in the parser.
Even if it worked as intended, it'd be a bit evil because of the
possibility of duplicate evaluation of a volatile function that the user
had written only once. Given the lack of documentation, test cases, or
complaints, let's just get rid of the idea and only support the standard
syntax.
While we're at it, improve the error cursor positioning for the
wrong-number-of-arguments errors, and inline the makeOverlaps() function
since it's only called in one place anyway.
Per bug #9227 from Joshua Yanovski. Initial patch by Joshua Yanovski,
extended a bit by me.
M src/backend/parser/gram.y
Disable RandomizedBaseAddress on MSVC builds
commit : 062deb31387b0e3190f8084c2de2194f40ee6a96
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 18 Feb 2014 14:45:58 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 18 Feb 2014 14:45:58 +0100
The ASLR in Windows 8/Windows 2012 can break PostgreSQL's shared memory. It
doesn't fail every time (which is explained by the Random part in ASLR), but
can fail with errors abut failing to reserve shared memory region.
MauMau, reviewed by Craig Ringer
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/VCBuildProject.pm
Fix comment; checkpointer, not bgwriter, performs checkpoints since 9.2.
commit : 5da060626089a3c67b1b12fa75733fb39ebe1bbb
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Feb 2014 09:48:18 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Feb 2014 09:48:18 +0200
Amit Langote
M src/backend/access/transam/xlog.c
Translation updates
commit : 67016c39703aa09ea7faf08dc3ec1456f92a832b
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 17 Feb 2014 16:56:04 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 17 Feb 2014 16:56:04 -0500
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/pt_BR.po
M src/backend/po/zh_TW.po
M src/bin/initdb/po/ko.po
M src/bin/initdb/po/ro.po
M src/bin/initdb/po/sv.po
M src/bin/initdb/po/zh_TW.po
M src/bin/pg_config/po/ko.po
M src/bin/pg_config/po/nb.po
M src/bin/pg_config/po/ro.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_config/po/ta.po
M src/bin/pg_config/po/tr.po
M src/bin/pg_config/po/zh_TW.po
M src/bin/pg_controldata/po/ro.po
M src/bin/pg_controldata/po/zh_TW.po
M src/bin/pg_ctl/po/zh_TW.po
M src/bin/pg_resetxlog/po/ko.po
M src/bin/pg_resetxlog/po/ro.po
M src/bin/pg_resetxlog/po/tr.po
M src/bin/pg_resetxlog/po/zh_TW.po
M src/bin/psql/po/zh_TW.po
M src/bin/scripts/po/ko.po
M src/bin/scripts/po/ro.po
M src/bin/scripts/po/sv.po
M src/bin/scripts/po/tr.po
M src/bin/scripts/po/zh_TW.po
M src/interfaces/ecpg/ecpglib/po/de.po
M src/interfaces/ecpg/ecpglib/po/fr.po
M src/interfaces/ecpg/ecpglib/po/ja.po
M src/interfaces/ecpg/ecpglib/po/pt_BR.po
M src/interfaces/ecpg/ecpglib/po/tr.po
M src/interfaces/ecpg/ecpglib/po/zh_CN.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/ko.po
M src/interfaces/ecpg/preproc/po/tr.po
M src/interfaces/ecpg/preproc/po/zh_TW.po
M src/interfaces/libpq/po/zh_TW.po
M src/pl/plperl/po/ro.po
M src/pl/plperl/po/zh_TW.po
M src/pl/plpgsql/src/po/ro.po
M src/pl/plpgsql/src/po/zh_TW.po
M src/pl/plpython/po/ro.po
M src/pl/tcl/po/de.po
M src/pl/tcl/po/fr.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/pt_BR.po
M src/pl/tcl/po/ro.po
M src/pl/tcl/po/tr.po
M src/pl/tcl/po/zh_CN.po
M src/pl/tcl/po/zh_TW.po