On Tue, 2014-05-06 at 23:26 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > Fix interval test, which was broken for floating-point timestamps.
> > Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
> > couldn't be made consistent between integer and floating-point
> > timestamp
Fix interval test, which was broken for floating-point timestamps.
Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
couldn't be made consistent between integer and floating-point
timestamps.
It was designed to test the longest possible interval output length,
so removing fou
Fix interval test, which was broken for floating-point timestamps.
Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
couldn't be made consistent between integer and floating-point
timestamps.
It was designed to test the longest possible interval output length,
so removing fou
Fix interval test, which was broken for floating-point timestamps.
Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
couldn't be made consistent between integer and floating-point
timestamps.
It was designed to test the longest possible interval output length,
so removing fou
Fix interval test, which was broken for floating-point timestamps.
Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
couldn't be made consistent between integer and floating-point
timestamps.
It was designed to test the longest possible interval output length,
so removing fou
Fix interval test, which was broken for floating-point timestamps.
Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
couldn't be made consistent between integer and floating-point
timestamps.
It was designed to test the longest possible interval output length,
so removing fou
Fix some more confusion between uint32 and Datum.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/1891b415f0cf45d56f29af423598f8518754d675
Modified Files
--
src/backend/utils/adt/jsonb_gin.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Se
Jeff Davis writes:
> Fix interval test, which was broken for floating-point timestamps.
> Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
> couldn't be made consistent between integer and floating-point
> timestamps.
That patch was back-patched as far as 8.4, so if you're g
Fix interval test, which was broken for floating-point timestamps.
Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
couldn't be made consistent between integer and floating-point
timestamps.
It was designed to test the longest possible interval output length,
so removing fou
hash_any returns Datum, not uint32 (and definitely not "int").
The coding in JsonbHashScalarValue might have accidentally failed to fail
given current representational choices, but the key word there would be
"accidental". Insert the appropriate datatype conversion macro. And
use the right conve
Improve comment for tricky aspect of index-only scans.
Index-only scans avoid taking a lock on the VM buffer, which would
cause a lot of contention. To be correct, that requires some intricate
assumptions that weren't completely documented in the previous
comment.
Reviewed by Robert Haas.
Branch
doc: Fix DocBook XML validity
The main problem is that DocBook SGML allows indexterm elements just
about everywhere, but DocBook XML is stricter. For example, this common
pattern
...
...
...
needs to be changed to something like
..
...
See also
With ecpg exclusion removed, re-run pgindent for 9.4
Report by Tom Lane
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/84288a86ac74dbeae486b6ff699c017f7d9517bb
Modified Files
--
src/backend/utils/adt/jsonb_util.c |8 ++--
src/interfac
Remove pgindent ecpg exclusion pattern
Report by Tom Lane
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/9516668e48abcc5c036ecb199acf15e5bcc4b008
Modified Files
--
src/tools/pgindent/exclude_file_patterns |2 --
1 file changed, 2 deletions(-)
--
S
pg_basebackup streaming: adjust version check msg
Allow for translatable string, rather than use "or"
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/250f259a44411d341e75928401503a681844c59d
Modified Files
--
src/bin/pg_basebackup/receivelog.c | 16 +++
Improve pgindent test instructions
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/7c7b1f4ae5ea3b1b113682d4d4e5af4356b053bc
Modified Files
--
src/tools/pgindent/README |2 ++
1 file changed, 2 insertions(+)
--
Sent via pgsql-committers mailing list
Fix logic bug in dsm_attach().
The previous coding would potentially cause attaching to segment A to
fail if segment B was at the same time in the process of going away.
Andres Freund, with a comment tweak by me
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/e01242
Andres Freund writes:
> On 2014-03-20 16:58:42 +, Tom Lane wrote:
>> Again fix initialization of auto-tuned effective_cache_size.
> This still is pretty ugly. Couldn't we just have a function in
> costsize.c that returns the actual value and computes it based on
> NBuffers if set to -1? Which
Fix improperly passed file descriptors
Fix for commit 14ea89366fe321609afc5838ff9fe2ded1cd707d
Report by Andres Freund
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/4335c958154c39ef99a38dc953b3f803b13a1048
Modified Files
--
src/bin/pg_dump/pg_backup_t
On Tue, May 6, 2014 at 05:52:59PM +0200, Andres Freund wrote:
> On 2014-05-06 00:27:21 +, Bruce Momjian wrote:
> > Properly detect read and write errors in pg_dump/dumpall, and pg_restore
> >
> > Previously some I/O errors were ignored.
>
> My compiler complains about this with:
>
> /home/a
On 2014-05-06 00:27:21 +, Bruce Momjian wrote:
> Properly detect read and write errors in pg_dump/dumpall, and pg_restore
>
> Previously some I/O errors were ignored.
My compiler complains about this with:
/home/andres/src/postgresql/src/bin/pg_dump/pg_backup_tar.c: In function
‘_tarReadRaw
Adjust pgindent to remove tabs after periods in C comments.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/fb85cd4320414c3f6e9c8bc69ec944200ae1e493
Modified Files
--
src/tools/pgindent/pgindent |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Correct comment in Hot Standby nbtree handling
Logic is correct, matching handling of LP_DEAD elsewhere.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/41fdcf71d2b424104e08ce229104b8e8e2840d1b
Modified Files
--
src/backend/access/nbtree/nbtxlog.c
On 6 May 2014 15:00, Heikki Linnakangas wrote:
> On 05/06/2014 04:52 PM, Simon Riggs wrote:
>>
>> On 6 May 2014 14:38, Simon Riggs wrote:
>>>
>>> On 6 May 2014 14:01, Heikki Linnakangas wrote:
>>>
Another idea is to say "is not supported with server versions older than
9.3", when tryin
Fix detection of short tar files, broken by commit
14ea89366fe321609afc5838ff9fe2ded1cd707d
Report by Noah Misch
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/55d5ff825fae0ee9a1114a17fcd97a3e360a23b0
Modified Files
--
src/bin/pg_dump/pg_backup_archive
On 05/06/2014 04:52 PM, Simon Riggs wrote:
On 6 May 2014 14:38, Simon Riggs wrote:
On 6 May 2014 14:01, Heikki Linnakangas wrote:
Another idea is to say "is not supported with server versions older than
9.3", when trying to connect to an older version, and "is not supported with
server versi
On 6 May 2014 14:38, Simon Riggs wrote:
> On 6 May 2014 14:01, Heikki Linnakangas wrote:
>
>> Another idea is to say "is not supported with server versions older than
>> 9.3", when trying to connect to an older version, and "is not supported with
>> server versions newer than 9.4", when connectin
Correct comment in Hot Standby nbtree handling
Logic is correct, matching handling of LP_DEAD elsewhere.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/2e54d88af137da5c1cf4749e2b9d4371224bbd47
Modified Files
--
src/backend/access/nbtree/nbtxlog.c | 10
On 6 May 2014 14:01, Heikki Linnakangas wrote:
> Another idea is to say "is not supported with server versions older than
> 9.3", when trying to connect to an older version, and "is not supported with
> server versions newer than 9.4", when connecting to >=9.5.
Will do
--
Simon Riggs
Update typedef list in preparation for pgindent run
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/284c464b9f7a47e3c4559a1ced75ff3dcb697e36
Modified Files
--
src/tools/pgindent/typedefs.list | 153 +++---
1 file changed, 1
On 05/06/2014 03:47 PM, Simon Riggs wrote:
pg_basebackup streaming: adjust version check msg
Commit d298b50a3b469c088bb40a4d36d38111b4cd574d by Heikki Linnakangas
requested that the version check message be updated at next release, suggesting
that the appropriate text would be “9.3 or later”. Th
More rewording of pg_stat_statements for 9.4 release notes
Report by Amit Langote
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/47faae931686536cfbd5dd70f347e4e658c5ebcc
Modified Files
--
doc/src/sgml/release-9.4.sgml |4 ++--
1 file changed, 2 inser
On Tue, May 6, 2014 at 01:02:23PM +0900, Amit Langote wrote:
>
> Perhaps a typo/copy-pasto in this commit, ;-)
>
>
> This allows monitoring tools to only fetch query texts for newly observe
> entries, as determined by
> queryid.
>
>
> s/observe/observed
Fixed, thanks. I changed it to "cre
pg_basebackup streaming: adjust version check msg
Commit d298b50a3b469c088bb40a4d36d38111b4cd574d by Heikki Linnakangas
requested that the version check message be updated at next release, suggesting
that the appropriate text would be “9.3 or later”. The logic used for the check
indicates that the
Fix use of free in walsender error handling after a sysid mismatch.
Found via valgrind. The bug exists since the introduction of the walsender,
so backpatch to 9.0.
Andres Freund
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/a7a3e71c8592a530f9a605aea4f08af7
Fix use of free in walsender error handling after a sysid mismatch.
Found via valgrind. The bug exists since the introduction of the walsender,
so backpatch to 9.0.
Andres Freund
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/e0070a6858cfcd2c4129dfa93bc042d6
Fix use of free in walsender error handling after a sysid mismatch.
Found via valgrind. The bug exists since the introduction of the walsender,
so backpatch to 9.0.
Andres Freund
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/17b04a15806d8e8b4cc3013244f4837c
Fix use of free in walsender error handling after a sysid mismatch.
Found via valgrind. The bug exists since the introduction of the walsender,
so backpatch to 9.0.
Andres Freund
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/d65ecdf4110bb352527dd2f6de31421d
Fix use of free in walsender error handling after a sysid mismatch.
Found via valgrind. The bug exists since the introduction of the walsender,
so backpatch to 9.0.
Andres Freund
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/3a8e9e977fa642433986e5cd145e3a6f86601c2
Fix handling of array of char pointers in ecpglib.
When array of char * was used as target for a FETCH statement returning more
than one row, it tried to store all the result in the first element. Instead it
should dump array of char pointers with right offset, use the address instead
of the value
Fix handling of array of char pointers in ecpglib.
When array of char * was used as target for a FETCH statement returning more
than one row, it tried to store all the result in the first element. Instead it
should dump array of char pointers with right offset, use the address instead
of the value
Fix handling of array of char pointers in ecpglib.
When array of char * was used as target for a FETCH statement returning more
than one row, it tried to store all the result in the first element. Instead it
should dump array of char pointers with right offset, use the address instead
of the value
Fix handling of array of char pointers in ecpglib.
When array of char * was used as target for a FETCH statement returning more
than one row, it tried to store all the result in the first element. Instead it
should dump array of char pointers with right offset, use the address instead
of the value
Fix handling of array of char pointers in ecpglib.
When array of char * was used as target for a FETCH statement returning more
than one row, it tried to store all the result in the first element. Instead it
should dump array of char pointers with right offset, use the address instead
of the value
44 matches
Mail list logo
