Andrew Dunstan writes:
> On 3/26/20 9:50 AM, Tom Lane wrote:
>> Why is jacana doing it differently?
> longfin is also running it (first) here
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=longfin=2020-03-26%2014%3A39%3A51=ssl_passphrase_callback-check
Oh, I missed that. Isn't
On 3/26/20 11:31 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/26/20 9:50 AM, Tom Lane wrote:
>>> Why is jacana doing it differently?
>> longfin is also running it (first) here
>>
Ensure that plpgsql cleans up cleanly during parallel-worker exit.
plpgsql_xact_cb ought to treat events XACT_EVENT_PARALLEL_COMMIT and
XACT_EVENT_PARALLEL_ABORT like XACT_EVENT_COMMIT and XACT_EVENT_ABORT
respectively, since its goal is to do process-local cleanup. This
oversight caused
Ensure that plpgsql cleans up cleanly during parallel-worker exit.
plpgsql_xact_cb ought to treat events XACT_EVENT_PARALLEL_COMMIT and
XACT_EVENT_PARALLEL_ABORT like XACT_EVENT_COMMIT and XACT_EVENT_ABORT
respectively, since its goal is to do process-local cleanup. This
oversight caused
Ensure that plpgsql cleans up cleanly during parallel-worker exit.
plpgsql_xact_cb ought to treat events XACT_EVENT_PARALLEL_COMMIT and
XACT_EVENT_PARALLEL_ABORT like XACT_EVENT_COMMIT and XACT_EVENT_ABORT
respectively, since its goal is to do process-local cleanup. This
oversight caused
Ensure that plpgsql cleans up cleanly during parallel-worker exit.
plpgsql_xact_cb ought to treat events XACT_EVENT_PARALLEL_COMMIT and
XACT_EVENT_PARALLEL_ABORT like XACT_EVENT_COMMIT and XACT_EVENT_ABORT
respectively, since its goal is to do process-local cleanup. This
oversight caused
Improve performance of "simple expressions" in PL/pgSQL.
For relatively simple expressions (say, "x + 1" or "x > 0"), plpgsql's
management overhead exceeds the cost of evaluating the expression.
This patch substantially improves that situation, providing roughly
2X speedup for such trivial
Andrew Dunstan writes:
> On 3/26/20 11:31 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> I don't think this belongs in installcheck, we should add
>>> 'NO_INSTALLCHECK = 1' to the Makefile.
>> Why? The other src/test/modules/ modules with TAP tests do not
>> specify that, with the exception
On 3/25/20 9:28 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/25/20 7:44 PM, Tom Lane wrote:
>>> I don't actually see why we need the localhost port at all --- it doesn't
>>> look like this test ever attempts to connect to the server. So couldn't
>>> we just drop that?
>> Seems
Drop slot's LWLock before returning from SaveSlotToPath()
When SaveSlotToPath() is called with elevel=LOG, the early exits didn't
release the slot's io_in_progress_lock.
This could result in a walsender being stuck on the lock forever. A
possible way to get into this situation is if the
Drop slot's LWLock before returning from SaveSlotToPath()
When SaveSlotToPath() is called with elevel=LOG, the early exits didn't
release the slot's io_in_progress_lock.
This could result in a walsender being stuck on the lock forever. A
possible way to get into this situation is if the
Drop slot's LWLock before returning from SaveSlotToPath()
When SaveSlotToPath() is called with elevel=LOG, the early exits didn't
release the slot's io_in_progress_lock.
This could result in a walsender being stuck on the lock forever. A
possible way to get into this situation is if the
Drop slot's LWLock before returning from SaveSlotToPath()
When SaveSlotToPath() is called with elevel=LOG, the early exits didn't
release the slot's io_in_progress_lock.
This could result in a walsender being stuck on the lock forever. A
possible way to get into this situation is if the
Drop slot's LWLock before returning from SaveSlotToPath()
When SaveSlotToPath() is called with elevel=LOG, the early exits didn't
release the slot's io_in_progress_lock.
This could result in a walsender being stuck on the lock forever. A
possible way to get into this situation is if the
Andrew Dunstan writes:
> On 3/25/20 9:28 PM, Tom Lane wrote:
>> jacana has just exposed a different problem: it's not configured
>> --with-openssl, but the buildfarm script is trying to run this
>> new test module anyway. I'm confused about the reason.
>> "make installcheck" in src/test/modules
Document that pg_checksums exists in checksums README
Author: Daniel Gustafsson
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/eff5b245df259c73d8342e2f04dba5a832d2ea0a
Modified Files
--
src/backend/storage/page/README | 3 ++-
1 file changed, 2
On 3/26/20 9:50 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/25/20 9:28 PM, Tom Lane wrote:
>>> jacana has just exposed a different problem: it's not configured
>>> --with-openssl, but the buildfarm script is trying to run this
>>> new test module anyway. I'm confused about the reason.
On 3/17/20 9:59 PM, Michael Paquier wrote:
> On Tue, Mar 17, 2020 at 10:37:40AM -0400, Tom Lane wrote:
>> As of this morning, the only active animal ("active" meaning "has
>> built HEAD in the last month") that is not running REL_11 is
>> hamerkop. I think we could proceed.
> +1.
Hamerkop has
18 matches
Mail list logo
