Avoid integer overflow when LIMIT + OFFSET >= 2^63.
This fixes bug #6139 reported by Hitoshi Harada.
Branch
--
REL8_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/d5276887cb408b11589a2c07d5b2d06f892d
Modified Files
--
src/backend/executor/nodeLimit.c |2
Avoid integer overflow when LIMIT + OFFSET >= 2^63.
This fixes bug #6139 reported by Hitoshi Harada.
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/f00fbad6bd43141faae05cd13a518fd28ae94673
Modified Files
--
src/backend/executor/nodeLimit.c |2
Avoid integer overflow when LIMIT + OFFSET >= 2^63.
This fixes bug #6139 reported by Hitoshi Harada.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/bc6616aaedbe4bcd2441334a3bf8f43fe9635bf1
Modified Files
--
src/backend/executor/nodeLimit.c |2
Avoid integer overflow when LIMIT + OFFSET >= 2^63.
This fixes bug #6139 reported by Hitoshi Harada.
Branch
--
REL8_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/0a6167f76bc4e3a433d097ba0c39f843e66c669f
Modified Files
--
src/backend/executor/nodeLimit.c |2
Avoid integer overflow when LIMIT + OFFSET >= 2^63.
This fixes bug #6139 reported by Hitoshi Harada.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/89df948ec26679e09f71baf6bbb9b06f9d329712
Modified Files
--
src/backend/executor/nodeLimit.c |2 +-
1 f
Avoid integer overflow when LIMIT + OFFSET >= 2^63.
This fixes bug #6139 reported by Hitoshi Harada.
Branch
--
REL8_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/443a44ba62c3b3089456ddcf72df695d3c77bee3
Modified Files
--
src/backend/executor/nodeLimit.c |2
Fix incorrect initialization of ProcGlobal->startupBufferPinWaitBufId.
It was initialized in the wrong place and to the wrong value. With bad
luck this could result in incorrect query-cancellation failures in hot
standby sessions, should a HS backend be holding pin on buffer number 1
while trying
Fix incorrect initialization of ProcGlobal->startupBufferPinWaitBufId.
It was initialized in the wrong place and to the wrong value. With bad
luck this could result in incorrect query-cancellation failures in hot
standby sessions, should a HS backend be holding pin on buffer number 1
while trying
Fix incorrect initialization of ProcGlobal->startupBufferPinWaitBufId.
It was initialized in the wrong place and to the wrong value. With bad
luck this could result in incorrect query-cancellation failures in hot
standby sessions, should a HS backend be holding pin on buffer number 1
while trying
On Tue, Aug 2, 2011 at 6:24 PM, Tom Lane wrote:
> Fix incorrect initialization of ProcGlobal->startupBufferPinWaitBufId.
>
> It was initialized in the wrong place and to the wrong value. With bad
> luck this could result in incorrect query-cancellation failures in hot
> standby sessions, should a
Move CheckRecoveryConflictDeadlock() call to a safer place.
This kluge was inserted in a spot apparently chosen at random: the lock
manager's state is not yet fully set up for the wait, and in particular
LockWaitCancel hasn't been armed by setting lockAwaited, so the ProcLock
will not get cleaned
Move CheckRecoveryConflictDeadlock() call to a safer place.
This kluge was inserted in a spot apparently chosen at random: the lock
manager's state is not yet fully set up for the wait, and in particular
LockWaitCancel hasn't been armed by setting lockAwaited, so the ProcLock
will not get cleaned
Move CheckRecoveryConflictDeadlock() call to a safer place.
This kluge was inserted in a spot apparently chosen at random: the lock
manager's state is not yet fully set up for the wait, and in particular
LockWaitCancel hasn't been armed by setting lockAwaited, so the ProcLock
will not get cleaned
Simon Riggs writes:
> On Tue, Aug 2, 2011 at 6:24 PM, Tom Lane wrote:
>> Fix incorrect initialization of ProcGlobal->startupBufferPinWaitBufId.
>>
>> It was initialized in the wrong place and to the wrong value. With bad
>> luck this could result in incorrect query-cancellation failures in hot
On Tue, Aug 2, 2011 at 8:23 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Tue, Aug 2, 2011 at 6:24 PM, Tom Lane wrote:
>>> Fix incorrect initialization of ProcGlobal->startupBufferPinWaitBufId.
>>>
>>> It was initialized in the wrong place and to the wrong value. With bad
>>> luck this could
15 matches
Mail list logo