Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

2015-05-04 Thread Andrew Dunstan
On 05/04/2015 02:23 PM, Robert Haas wrote: Recursively fsync() the data directory after a crash. Otherwise, if there's another crash, some writes from after the first crash might make it to disk while writes from before the crash fail to make it to disk. This could lead to data corruption. Ba

[COMMITTERS] pgsql: hstore_plpython: Support tests on Python 2.3

2015-05-04 Thread Peter Eisentraut
hstore_plpython: Support tests on Python 2.3 Python 2.3 does not have the sorted() function, so do it the long way. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c0574cd5aa96b988bb1f0287914dcc8b52fb01bd Modified Files -- contrib/hstore_plpython/expecte

[COMMITTERS] pgsql: Fix typos

2015-05-04 Thread Peter Eisentraut
Fix typos Author: Erik Rijkers Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ad8d6d064cbcc165e3033a6ed56818f711b0ffae Modified Files -- doc/src/sgml/func.sgml |2 +- src/backend/replication/logical/origin.c |2 +- 2 files chang

[COMMITTERS] pgsql: Use outerPlanState macro instead of referring to leffttree.

2015-05-04 Thread Robert Haas
Use outerPlanState macro instead of referring to leffttree. This makes the executor code more consistent. It also removes an apparently superfluous NULL test in nodeGroup.c. Qingqing Zhou, reviewed by Tom Lane, and further revised by me. Branch -- master Details --- http://git.postgres

[COMMITTERS] pgsql: Improve procost estimates for some text search functions.

2015-05-04 Thread Tom Lane
Improve procost estimates for some text search functions. The text search functions that involve parsing raw text into lexemes are remarkably CPU-intensive, so estimating them at the same cost as most other built-in functions seems like a mistake; moreover, doing so turns out to discourage the opt

[COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

2015-05-04 Thread Robert Haas
Recursively fsync() the data directory after a crash. Otherwise, if there's another crash, some writes from after the first crash might make it to disk while writes from before the crash fail to make it to disk. This could lead to data corruption. Back-patch to all supported versions. Abhijit M

[COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

2015-05-04 Thread Robert Haas
Recursively fsync() the data directory after a crash. Otherwise, if there's another crash, some writes from after the first crash might make it to disk while writes from before the crash fail to make it to disk. This could lead to data corruption. Back-patch to all supported versions. Abhijit M

[COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

2015-05-04 Thread Robert Haas
Recursively fsync() the data directory after a crash. Otherwise, if there's another crash, some writes from after the first crash might make it to disk while writes from before the crash fail to make it to disk. This could lead to data corruption. Back-patch to all supported versions. Abhijit M

[COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

2015-05-04 Thread Robert Haas
Recursively fsync() the data directory after a crash. Otherwise, if there's another crash, some writes from after the first crash might make it to disk while writes from before the crash fail to make it to disk. This could lead to data corruption. Back-patch to all supported versions. Abhijit M

[COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

2015-05-04 Thread Robert Haas
Recursively fsync() the data directory after a crash. Otherwise, if there's another crash, some writes from after the first crash might make it to disk while writes from before the crash fail to make it to disk. This could lead to data corruption. Back-patch to all supported versions. Abhijit M

[COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

2015-05-04 Thread Robert Haas
Recursively fsync() the data directory after a crash. Otherwise, if there's another crash, some writes from after the first crash might make it to disk while writes from before the crash fail to make it to disk. This could lead to data corruption. Back-patch to all supported versions. Abhijit M

[COMMITTERS] pgsql: Fix the same-rel optimization when creating WAL records.

2015-05-04 Thread Heikki Linnakangas
Fix the same-rel optimization when creating WAL records. prev_regbuf was never set, and therefore the same-rel flag was never set on WAL records. Report and fix by Zhanq Zq Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ec3d976bce7e322c29f1007d19b63b7a3a1a6ee4 Mod

[COMMITTERS] pgsql: Backport "Expose fsync_fname as a public API".

2015-05-04 Thread Robert Haas
Backport "Expose fsync_fname as a public API". Backport commit b0a48e996bd7ff336ea26344d3d97ad32b22a61a back to 9.0 to allow back-patching another fix that uses fsync_fname. Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f1d7516770739e1af5cf517c01aa3bfa7b02b8

[COMMITTERS] pgsql: Fix two small bugs in json's populate_record_worker

2015-05-04 Thread Andrew Dunstan
Fix two small bugs in json's populate_record_worker The first bug is not releasing a tupdesc when doing an early return out of the function. The second bug is a logic error in choosing when to do an early return if given an empty jsonb object. Bug reports from Pavel Stehule and Tom Lane respectiv

[COMMITTERS] pgsql: Fix two small bugs in json's populate_record_worker

2015-05-04 Thread Andrew Dunstan
Fix two small bugs in json's populate_record_worker The first bug is not releasing a tupdesc when doing an early return out of the function. The second bug is a logic error in choosing when to do an early return if given an empty jsonb object. Bug reports from Pavel Stehule and Tom Lane respectiv