<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/postgresql.git, branch REL8_4_21</title>
<subtitle>git.postgresql.org: git/postgresql.git
</subtitle>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/'/>
<entry>
<title>Stamp 8.4.21.</title>
<updated>2014-03-17T19:39:12+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2014-03-17T19:39:12+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=e1fa2d4139bbc2dace6da1f6f77bc7e87cd091bb'/>
<id>e1fa2d4139bbc2dace6da1f6f77bc7e87cd091bb</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Release notes for 9.3.4, 9.2.8, 9.1.13, 9.0.17, 8.4.21.</title>
<updated>2014-03-17T19:28:38+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2014-03-17T19:28:38+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=cc80df243eaee67530fe5ca88435b36360031510'/>
<id>cc80df243eaee67530fe5ca88435b36360031510</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Translation updates</title>
<updated>2014-03-17T01:57:28+00:00</updated>
<author>
<name>Peter Eisentraut</name>
<email>peter_e@gmx.net</email>
</author>
<published>2014-03-17T01:30:16+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=cf641695595d6db59efd90a4858c5f6d6c286f8b'/>
<id>cf641695595d6db59efd90a4858c5f6d6c286f8b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix advertised dispsize for libpq's sslmode connection parameter.</title>
<updated>2014-03-17T01:43:57+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2014-03-17T01:43:57+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=962c14894768f95fabc82d4fb7db38c76d88fb97'/>
<id>962c14894768f95fabc82d4fb7db38c76d88fb97</id>
<content type='text'>
"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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
"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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Update time zone data files to tzdata release 2014a.</title>
<updated>2014-03-15T17:36:57+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2014-03-15T17:36:07+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=6e6c2c2e1e9f0cc1537dc2035aa6d1aaab935135'/>
<id>6e6c2c2e1e9f0cc1537dc2035aa6d1aaab935135</id>
<content type='text'>
DST law changes in Fiji, Turkey; historical changes in Israel, Ukraine.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
DST law changes in Fiji, Turkey; historical changes in Israel, Ukraine.
</pre>
</div>
</content>
</entry>
<entry>
<title>Add missing #include.</title>
<updated>2014-03-14T15:47:03+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2014-03-14T15:47:03+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=810d6df0818dae0df98e54b1f52365ba00ace2b2'/>
<id>810d6df0818dae0df98e54b1f52365ba00ace2b2</id>
<content type='text'>
Commit 31400a673 and siblings added a check_stack_depth() call in
contrib/intarray/_int_bool.c, but neglected to note that in our oldest
branches that file didn't have the #include that defines that function.
This results in a fortunately-harmless compiler warning.  Per buildfarm.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 31400a673 and siblings added a check_stack_depth() call in
contrib/intarray/_int_bool.c, but neglected to note that in our oldest
branches that file didn't have the #include that defines that function.
This results in a fortunately-harmless compiler warning.  Per buildfarm.
</pre>
</div>
</content>
</entry>
<entry>
<title>Prevent interrupts while reporting non-ERROR elog messages.</title>
<updated>2014-03-14T00:59:57+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2014-03-14T00:59:57+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=172c53e924021791621e97afd2e88eeea5ce5418'/>
<id>172c53e924021791621e97afd2e88eeea5ce5418</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>In WAL replay, restore GIN metapage unconditionally to avoid torn page.</title>
<updated>2014-03-12T08:10:04+00:00</updated>
<author>
<name>Heikki Linnakangas</name>
<email>heikki.linnakangas@iki.fi</email>
</author>
<published>2014-03-12T07:59:49+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=e2bccdfccd13e191c28084d05347ba0d1208cf5e'/>
<id>e2bccdfccd13e191c28084d05347ba0d1208cf5e</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix dangling smgr_owner pointer when a fake relcache entry is freed.</title>
<updated>2014-03-07T11:43:28+00:00</updated>
<author>
<name>Heikki Linnakangas</name>
<email>heikki.linnakangas@iki.fi</email>
</author>
<published>2014-03-07T11:25:11+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=d411d6eff1b7e91de0fecece08acc6b6eca04d6d'/>
<id>d411d6eff1b7e91de0fecece08acc6b6eca04d6d</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Avoid memcpy() with same source and destination address.</title>
<updated>2014-03-07T11:43:28+00:00</updated>
<author>
<name>Heikki Linnakangas</name>
<email>heikki.linnakangas@iki.fi</email>
</author>
<published>2014-03-07T11:13:33+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=ff9d757c67786b389f19abc3187d158adda500d8'/>
<id>ff9d757c67786b389f19abc3187d158adda500d8</id>
<content type='text'>
The behavior of that is undefined, although unlikely to lead to problems in
practice.

Found by running regression tests with Valgrind.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The behavior of that is undefined, although unlikely to lead to problems in
practice.

Found by running regression tests with Valgrind.
</pre>
</div>
</content>
</entry>
</feed>
