pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedvalgrind vs. shared typmod registry
7+ messages / 4 participants
[nested] [flat]
* valgrind vs. shared typmod registry
@ 2017-09-16 12:30 Tomas Vondra <tomas.vondra@2ndquadrant.com>
2017-09-16 19:42 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-16 19:47 ` Re: valgrind vs. shared typmod registry Peter Geoghegan <pg@bowt.ie>
0 siblings, 2 replies; 7+ messages in thread
From: Tomas Vondra @ 2017-09-16 12:30 UTC (permalink / raw)
To: pgsql-hackers
Hi,
I've been running some regression tests under valgrind, and it seems
select_parallel triggers some uses of uninitialized values in dshash. If
I'm reading the reports right, it complains about hashtable->size_log2
being not being initialized in ensure_valid_bucket_pointers.
I've been running tests under valgrind not too long ago and I don't
recall such failures, so perhaps something broke it in the past few days.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[text/x-log] valgrind.log (8.5K, ../../e72fb33c-4f31-f276-e972-263d9b59554d@2ndquadrant.com/2-valgrind.log)
download | inline:
==18897== Conditional jump or move depends on uninitialised value(s)
==18897== at 0x6C0B4F: ensure_valid_bucket_pointers (dshash.c:752)
==18897== by 0x6C0123: dshash_find (dshash.c:390)
==18897== by 0x971224: find_or_make_matching_shared_tupledesc (typcache.c:2265)
==18897== by 0x9704E7: assign_record_type_typmod (typcache.c:1602)
==18897== by 0x68879E: BlessTupleDesc (execTuples.c:1036)
==18897== by 0x6721C8: ExecInitExprRec (execExpr.c:1512)
==18897== by 0x671E62: ExecInitExprRec (execExpr.c:1385)
==18897== by 0x66FC87: ExecInitExpr (execExpr.c:130)
==18897== by 0x15AB9E92: exec_eval_simple_expr (pl_exec.c:5584)
==18897== by 0x15AB95E9: exec_eval_expr (pl_exec.c:5202)
==18897== by 0x15AB4388: exec_stmt_return (pl_exec.c:2755)
==18897== by 0x15AB2563: exec_stmt (pl_exec.c:1606)
==18897== by 0x15AB2306: exec_stmts (pl_exec.c:1521)
==18897== by 0x15AB21B1: exec_stmt_block (pl_exec.c:1459)
==18897== by 0x15AB046B: plpgsql_exec_function (pl_exec.c:464)
==18897== by 0x15AAACCD: plpgsql_call_handler (pl_handler.c:258)
==18897== by 0x674C7E: ExecInterpExpr (execExprInterp.c:650)
==18897== by 0x6AA6A0: ExecEvalExprSwitchContext (executor.h:309)
==18897== by 0x6AA709: ExecProject (executor.h:343)
==18897== by 0x6AA878: ExecResult (nodeResult.c:136)
==18897== Uninitialised value was created by a heap allocation
==18897== at 0x9A837E: palloc (mcxt.c:871)
==18897== by 0x6BFEEA: dshash_attach (dshash.c:269)
==18897== by 0x9707F7: SharedRecordTypmodRegistryAttach (typcache.c:1778)
==18897== by 0x484826: AttachSession (session.c:183)
==18897== by 0x504225: ParallelWorkerMain (parallel.c:1100)
==18897== by 0x7820B5: StartBackgroundWorker (bgworker.c:835)
==18897== by 0x793F9E: do_start_bgworker (postmaster.c:5686)
==18897== by 0x7942D7: maybe_start_bgworkers (postmaster.c:5890)
==18897== by 0x793399: sigusr1_handler (postmaster.c:5079)
==18897== by 0x4E4B5CF: ??? (in /usr/lib64/libpthread-2.24.so)
==18897== by 0x586AC72: __select_nocancel (in /usr/lib64/libc-2.24.so)
==18897== by 0x78F220: ServerLoop (postmaster.c:1720)
==18897== by 0x78E9C5: PostmasterMain (postmaster.c:1364)
==18897== by 0x6D5714: main (main.c:228)
==18897==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:ensure_valid_bucket_pointers
fun:dshash_find
fun:find_or_make_matching_shared_tupledesc
fun:assign_record_type_typmod
fun:BlessTupleDesc
fun:ExecInitExprRec
fun:ExecInitExprRec
fun:ExecInitExpr
fun:exec_eval_simple_expr
fun:exec_eval_expr
fun:exec_stmt_return
fun:exec_stmt
fun:exec_stmts
fun:exec_stmt_block
fun:plpgsql_exec_function
fun:plpgsql_call_handler
fun:ExecInterpExpr
fun:ExecEvalExprSwitchContext
fun:ExecProject
fun:ExecResult
}
==18897== Conditional jump or move depends on uninitialised value(s)
==18897== at 0x6C0B4F: ensure_valid_bucket_pointers (dshash.c:752)
==18897== by 0x6C024E: dshash_find_or_insert (dshash.c:440)
==18897== by 0x971310: find_or_make_matching_shared_tupledesc (typcache.c:2294)
==18897== by 0x9704E7: assign_record_type_typmod (typcache.c:1602)
==18897== by 0x68879E: BlessTupleDesc (execTuples.c:1036)
==18897== by 0x6721C8: ExecInitExprRec (execExpr.c:1512)
==18897== by 0x671E62: ExecInitExprRec (execExpr.c:1385)
==18897== by 0x66FC87: ExecInitExpr (execExpr.c:130)
==18897== by 0x15AB9E92: exec_eval_simple_expr (pl_exec.c:5584)
==18897== by 0x15AB95E9: exec_eval_expr (pl_exec.c:5202)
==18897== by 0x15AB4388: exec_stmt_return (pl_exec.c:2755)
==18897== by 0x15AB2563: exec_stmt (pl_exec.c:1606)
==18897== by 0x15AB2306: exec_stmts (pl_exec.c:1521)
==18897== by 0x15AB21B1: exec_stmt_block (pl_exec.c:1459)
==18897== by 0x15AB046B: plpgsql_exec_function (pl_exec.c:464)
==18897== by 0x15AAACCD: plpgsql_call_handler (pl_handler.c:258)
==18897== by 0x674C7E: ExecInterpExpr (execExprInterp.c:650)
==18897== by 0x6AA6A0: ExecEvalExprSwitchContext (executor.h:309)
==18897== by 0x6AA709: ExecProject (executor.h:343)
==18897== by 0x6AA878: ExecResult (nodeResult.c:136)
==18897== Uninitialised value was created by a heap allocation
==18897== at 0x9A837E: palloc (mcxt.c:871)
==18897== by 0x6BFEEA: dshash_attach (dshash.c:269)
==18897== by 0x970820: SharedRecordTypmodRegistryAttach (typcache.c:1782)
==18897== by 0x484826: AttachSession (session.c:183)
==18897== by 0x504225: ParallelWorkerMain (parallel.c:1100)
==18897== by 0x7820B5: StartBackgroundWorker (bgworker.c:835)
==18897== by 0x793F9E: do_start_bgworker (postmaster.c:5686)
==18897== by 0x7942D7: maybe_start_bgworkers (postmaster.c:5890)
==18897== by 0x793399: sigusr1_handler (postmaster.c:5079)
==18897== by 0x4E4B5CF: ??? (in /usr/lib64/libpthread-2.24.so)
==18897== by 0x586AC72: __select_nocancel (in /usr/lib64/libc-2.24.so)
==18897== by 0x78F220: ServerLoop (postmaster.c:1720)
==18897== by 0x78E9C5: PostmasterMain (postmaster.c:1364)
==18897== by 0x6D5714: main (main.c:228)
==18897==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:ensure_valid_bucket_pointers
fun:dshash_find_or_insert
fun:find_or_make_matching_shared_tupledesc
fun:assign_record_type_typmod
fun:BlessTupleDesc
fun:ExecInitExprRec
fun:ExecInitExprRec
fun:ExecInitExpr
fun:exec_eval_simple_expr
fun:exec_eval_expr
fun:exec_stmt_return
fun:exec_stmt
fun:exec_stmts
fun:exec_stmt_block
fun:plpgsql_exec_function
fun:plpgsql_call_handler
fun:ExecInterpExpr
fun:ExecEvalExprSwitchContext
fun:ExecProject
fun:ExecResult
}
==18657== Conditional jump or move depends on uninitialised value(s)
==18657== at 0x6C0B4F: ensure_valid_bucket_pointers (dshash.c:752)
==18657== by 0x6C0123: dshash_find (dshash.c:390)
==18657== by 0x970145: lookup_rowtype_tupdesc_internal (typcache.c:1436)
==18657== by 0x97024A: lookup_rowtype_tupdesc (typcache.c:1490)
==18657== by 0x8F7079: record_out (rowtypes.c:321)
==18657== by 0x97C5DE: FunctionCall1Coll (fmgr.c:1037)
==18657== by 0x97DD00: OutputFunctionCall (fmgr.c:1669)
==18657== by 0x48167E: printtup (printtup.c:356)
==18657== by 0x67F54C: ExecutePlan (execMain.c:1755)
==18657== by 0x67D4EC: standard_ExecutorRun (execMain.c:363)
==18657== by 0x67D38D: ExecutorRun (execMain.c:306)
==18657== by 0x822A24: PortalRunSelect (pquery.c:932)
==18657== by 0x8226FE: PortalRun (pquery.c:773)
==18657== by 0x81CBEF: exec_simple_query (postgres.c:1109)
==18657== by 0x820C29: PostgresMain (postgres.c:4106)
==18657== by 0x793216: BackendRun (postmaster.c:4360)
==18657== by 0x7929B0: BackendStartup (postmaster.c:4032)
==18657== by 0x78F348: ServerLoop (postmaster.c:1756)
==18657== by 0x78E9C5: PostmasterMain (postmaster.c:1364)
==18657== by 0x6D5714: main (main.c:228)
==18657== Uninitialised value was created by a heap allocation
==18657== at 0x9A837E: palloc (mcxt.c:871)
==18657== by 0x6BFC82: dshash_create (dshash.c:202)
==18657== by 0x9705DD: SharedRecordTypmodRegistryInit (typcache.c:1670)
==18657== by 0x4846D0: GetSessionDsmHandle (session.c:127)
==18657== by 0x5027B5: InitializeParallelDSM (parallel.c:222)
==18657== by 0x682E12: ExecInitParallelPlan (execParallel.c:510)
==18657== by 0x69832E: ExecGather (nodeGather.c:159)
==18657== by 0x684522: ExecProcNodeFirst (execProcnode.c:436)
==18657== by 0x68E1CF: ExecProcNode (executor.h:251)
==18657== by 0x68E5B0: fetch_input_tuple (nodeAgg.c:689)
==18657== by 0x690EDD: agg_retrieve_direct (nodeAgg.c:2318)
==18657== by 0x690B2F: ExecAgg (nodeAgg.c:2129)
==18657== by 0x684522: ExecProcNodeFirst (execProcnode.c:436)
==18657== by 0x67D048: ExecProcNode (executor.h:251)
==18657== by 0x67F4DF: ExecutePlan (execMain.c:1720)
==18657== by 0x67D4EC: standard_ExecutorRun (execMain.c:363)
==18657== by 0x67D38D: ExecutorRun (execMain.c:306)
==18657== by 0x822A24: PortalRunSelect (pquery.c:932)
==18657== by 0x8226FE: PortalRun (pquery.c:773)
==18657== by 0x81CBEF: exec_simple_query (postgres.c:1109)
==18657==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:ensure_valid_bucket_pointers
fun:dshash_find
fun:lookup_rowtype_tupdesc_internal
fun:lookup_rowtype_tupdesc
fun:record_out
fun:FunctionCall1Coll
fun:OutputFunctionCall
fun:printtup
fun:ExecutePlan
fun:standard_ExecutorRun
fun:ExecutorRun
fun:PortalRunSelect
fun:PortalRun
fun:exec_simple_query
fun:PostgresMain
fun:BackendRun
fun:BackendStartup
fun:ServerLoop
fun:PostmasterMain
fun:main
}
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: valgrind vs. shared typmod registry
2017-09-16 12:30 valgrind vs. shared typmod registry Tomas Vondra <tomas.vondra@2ndquadrant.com>
@ 2017-09-16 19:42 ` Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-16 20:49 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
1 sibling, 1 reply; 7+ messages in thread
From: Thomas Munro @ 2017-09-16 19:42 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>; +Cc: pgsql-hackers
On Sun, Sep 17, 2017 at 12:30 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> I've been running some regression tests under valgrind, and it seems
> select_parallel triggers some uses of uninitialized values in dshash. If
> I'm reading the reports right, it complains about hashtable->size_log2
> being not being initialized in ensure_valid_bucket_pointers.
Thanks. Will investigate.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: valgrind vs. shared typmod registry
2017-09-16 12:30 valgrind vs. shared typmod registry Tomas Vondra <tomas.vondra@2ndquadrant.com>
2017-09-16 19:42 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
@ 2017-09-16 20:49 ` Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-18 05:39 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Munro @ 2017-09-16 20:49 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>; +Cc: pgsql-hackers
On Sun, Sep 17, 2017 at 7:42 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Sun, Sep 17, 2017 at 12:30 AM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>> I've been running some regression tests under valgrind, and it seems
>> select_parallel triggers some uses of uninitialized values in dshash. If
>> I'm reading the reports right, it complains about hashtable->size_log2
>> being not being initialized in ensure_valid_bucket_pointers.
>
> Thanks. Will investigate.
Yeah, it's a bug, I simply failed to initialise it.
ensure_valid_bucket_pointers() immediately fixes the problem (unless
the uninitialised memory had an unlikely value), explaining why it
works anyway. I'm a bit tied up today but will test and post a patch
tomorrow.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: valgrind vs. shared typmod registry
2017-09-16 12:30 valgrind vs. shared typmod registry Tomas Vondra <tomas.vondra@2ndquadrant.com>
2017-09-16 19:42 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-16 20:49 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
@ 2017-09-18 05:39 ` Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-18 06:04 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Munro @ 2017-09-18 05:39 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>; +Cc: pgsql-hackers
On Sun, Sep 17, 2017 at 8:49 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Sun, Sep 17, 2017 at 7:42 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> On Sun, Sep 17, 2017 at 12:30 AM, Tomas Vondra
>> <tomas.vondra@2ndquadrant.com> wrote:
>>> I've been running some regression tests under valgrind, and it seems
>>> select_parallel triggers some uses of uninitialized values in dshash. If
>>> I'm reading the reports right, it complains about hashtable->size_log2
>>> being not being initialized in ensure_valid_bucket_pointers.
>>
>> Thanks. Will investigate.
>
> Yeah, it's a bug, I simply failed to initialise it.
> ensure_valid_bucket_pointers() immediately fixes the problem (unless
> the uninitialised memory had an unlikely value), explaining why it
> works anyway. I'm a bit tied up today but will test and post a patch
> tomorrow.
Here is a patch to fix that.
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] 0001-Fix-uninitialized-variable-in-dshash.c.patch (1.5K, ../../CAEepm=3bZYi0aih0Eds2ivTQ+dEbMvchXDTfRCcbadiOo_YZUQ@mail.gmail.com/2-0001-Fix-uninitialized-variable-in-dshash.c.patch)
download | inline diff:
From b11ef06d78758cc0446006f43cdf98d95250edb1 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@enterprisedb.com>
Date: Mon, 18 Sep 2017 17:28:05 +1200
Subject: [PATCH] Fix uninitialized variable in dshash.c.
A bugfix for commit 8c0d7bafad36434cb08ac2c78e69ae72c194ca20. The code
would have crashed if hashtable->size_log2 ever had the same value as
hashtable->control->size_log2 by coincidence.
Per Coverity.
Author: Thomas Munro
Reported-By: Tomas Vondra
Discussion: https://postgr.es/m/e72fb33c-4f31-f276-e972-263d9b59554d%402ndquadrant.com
---
src/backend/lib/dshash.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/backend/lib/dshash.c b/src/backend/lib/dshash.c
index 448e0587253..dd875730670 100644
--- a/src/backend/lib/dshash.c
+++ b/src/backend/lib/dshash.c
@@ -249,6 +249,7 @@ dshash_create(dsa_area *area, const dshash_parameters *params, void *arg)
}
hash_table->buckets = dsa_get_address(area,
hash_table->control->buckets);
+ hash_table->size_log2 = hash_table->control->size_log2;
return hash_table;
}
@@ -280,6 +281,14 @@ dshash_attach(dsa_area *area, const dshash_parameters *params,
hash_table->find_exclusively_locked = false;
Assert(hash_table->control->magic == DSHASH_MAGIC);
+ /*
+ * These will later be set to the correct values by
+ * ensure_valid_bucket_pointers(), at which time we'll be holding a
+ * partition lock for interlocking against concurrent resizing.
+ */
+ hash_table->buckets = NULL;
+ hash_table->size_log2 = 0;
+
return hash_table;
}
--
2.13.2
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: valgrind vs. shared typmod registry
2017-09-16 12:30 valgrind vs. shared typmod registry Tomas Vondra <tomas.vondra@2ndquadrant.com>
2017-09-16 19:42 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-16 20:49 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-18 05:39 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
@ 2017-09-18 06:04 ` Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-19 00:56 ` Re: valgrind vs. shared typmod registry Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Munro @ 2017-09-18 06:04 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>; +Cc: pgsql-hackers
On Mon, Sep 18, 2017 at 5:39 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Here is a patch to fix that.
Here's a better one (same code, corrected commit message).
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] 0001-Fix-uninitialized-variable-in-dshash.c.patch (1.5K, ../../CAEepm=2Aw3qZtrr5SyojKUh50gRwRC4mfE2HkAqqTj4vV8r3Kg@mail.gmail.com/2-0001-Fix-uninitialized-variable-in-dshash.c.patch)
download | inline diff:
From 0b4996a971e36bfe6ac2d8631b4dd0579dbd391c Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@enterprisedb.com>
Date: Mon, 18 Sep 2017 17:28:05 +1200
Subject: [PATCH] Fix uninitialized variable in dshash.c.
A bugfix for commit 8c0d7bafad36434cb08ac2c78e69ae72c194ca20. The code
would have crashed if hashtable->size_log2 ever had the same value as
hashtable->control->size_log2 by coincidence.
Per Valgrind.
Author: Thomas Munro
Reported-By: Tomas Vondra
Discussion: https://postgr.es/m/e72fb33c-4f31-f276-e972-263d9b59554d%402ndquadrant.com
---
src/backend/lib/dshash.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/backend/lib/dshash.c b/src/backend/lib/dshash.c
index 448e0587253..dd875730670 100644
--- a/src/backend/lib/dshash.c
+++ b/src/backend/lib/dshash.c
@@ -249,6 +249,7 @@ dshash_create(dsa_area *area, const dshash_parameters *params, void *arg)
}
hash_table->buckets = dsa_get_address(area,
hash_table->control->buckets);
+ hash_table->size_log2 = hash_table->control->size_log2;
return hash_table;
}
@@ -280,6 +281,14 @@ dshash_attach(dsa_area *area, const dshash_parameters *params,
hash_table->find_exclusively_locked = false;
Assert(hash_table->control->magic == DSHASH_MAGIC);
+ /*
+ * These will later be set to the correct values by
+ * ensure_valid_bucket_pointers(), at which time we'll be holding a
+ * partition lock for interlocking against concurrent resizing.
+ */
+ hash_table->buckets = NULL;
+ hash_table->size_log2 = 0;
+
return hash_table;
}
--
2.13.2
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: valgrind vs. shared typmod registry
2017-09-16 12:30 valgrind vs. shared typmod registry Tomas Vondra <tomas.vondra@2ndquadrant.com>
2017-09-16 19:42 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-16 20:49 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-18 05:39 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-18 06:04 ` Re: valgrind vs. shared typmod registry Thomas Munro <thomas.munro@enterprisedb.com>
@ 2017-09-19 00:56 ` Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 7+ messages in thread
From: Andres Freund @ 2017-09-19 00:56 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@enterprisedb.com>; +Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>; pgsql-hackers
Hi,
On 2017-09-18 18:04:36 +1200, Thomas Munro wrote:
> On Mon, Sep 18, 2017 at 5:39 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
> > Here is a patch to fix that.
>
> Here's a better one (same code, corrected commit message).
Pushed. For a second I was tempted to also replace the
palloc(sizeof(dshash_table)) with a palloc0 - but in the end it seems
actually not too bad either to be able to catch bugs like this with some
help. If you have a strong opinion either way...
Thanks,
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: valgrind vs. shared typmod registry
2017-09-16 12:30 valgrind vs. shared typmod registry Tomas Vondra <tomas.vondra@2ndquadrant.com>
@ 2017-09-16 19:47 ` Peter Geoghegan <pg@bowt.ie>
1 sibling, 0 replies; 7+ messages in thread
From: Peter Geoghegan @ 2017-09-16 19:47 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>; +Cc: pgsql-hackers
On Sat, Sep 16, 2017 at 5:30 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> I've been running tests under valgrind not too long ago and I don't
> recall such failures, so perhaps something broke it in the past few days.
That's what we have the buildfarm animal Skink for. It has indeed been
failing within select_parallel only following the commit that you
mentioned:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=skink&br=HEAD
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2017-09-19 00:56 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-09-16 12:30 valgrind vs. shared typmod registry Tomas Vondra <tomas.vondra@2ndquadrant.com>
2017-09-16 19:42 ` Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-16 20:49 ` Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-18 05:39 ` Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-18 06:04 ` Thomas Munro <thomas.munro@enterprisedb.com>
2017-09-19 00:56 ` Andres Freund <andres@anarazel.de>
2017-09-16 19:47 ` Peter Geoghegan <pg@bowt.ie>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox