pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>
Cc: Andrey V. Lepikhov <a.lepikhov@postgrespro.ru>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: POC: postgres_fdw insert batching
Date: Thu, 21 Jan 2021 02:45:12 +0100
Message-ID: <442cdcdc-5501-50f7-6efd-5df1668e11f9@enterprisedb.com> (raw)
In-Reply-To: <797826.1611192177@sss.pgh.pa.us>
References: <20200628151002.7x5laxwpgvkyiu3q@development>
	<OSBPR01MB29820BAA17AD3A79A49935EFFEA40@OSBPR01MB2982.jpnprd01.prod.outlook.com>
	<16fcfd4c-2d5e-67f7-fa69-9b5d119bac52@enterprisedb.com>
	<TYAPR01MB299026DB0E91E513664C162FFEA30@TYAPR01MB2990.jpnprd01.prod.outlook.com>
	<ba58f299-d50b-f347-4a0f-778cb6ac5588@enterprisedb.com>
	<TYAPR01MB2990A053D902EDF6244090BDFEA30@TYAPR01MB2990.jpnprd01.prod.outlook.com>
	<CA+HiwqH-7+L0B7iNWcAe8auWch=-EnbRkLYMG-27K4rUKsWKOQ@mail.gmail.com>
	<TYAPR01MB29903CBD68C9DA42B67D9EB6FEA30@TYAPR01MB2990.jpnprd01.prod.outlook.com>
	<CA+HiwqGiwxSc8kc0PgPef5DgnP7NTRHVyAZJG3zxY4XBivbfLQ@mail.gmail.com>
	<9d94c863-ce7c-ea7f-6b84-834c98929e2f@enterprisedb.com>
	<CA+HiwqHTeQKqRpCA3TGZSCYTVOcUoUdXeSrRfjRRcmT1CfM1oA@mail.gmail.com>
	<7e70a11e-cf5d-2e5f-a802-274c5e0e236b@enterprisedb.com>
	<eb81a728-4ac3-823e-0017-54a9491f5600@enterprisedb.com>
	<261fbedb-1ced-82f7-e978-60cfe17bce07@enterprisedb.! com>
	<797826.1611192177@sss.pgh.pa.us>



On 1/21/21 2:22 AM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> I may be wrong, but the most likely explanation seems to be this is due
>> to the junk filter initialization, which simply moves past the end of
>> the mtstate->resultRelInfo array.
> 
> resultRelInfo is certainly pointing at garbage at that point.
> 

Yup. It's pretty amazing the x86 machines seem to be mostly OK with it.

>> It kinda seems the GetForeignModifyBatchSize call should happen before
>> that block. The attached patch fixes this for me (i.e. regression tests
>> pass with no valgrind reports.
> 
>> Or did I get that wrong?
> 
> Don't we need to initialize ri_BatchSize for *each* resultrelinfo,
> not merely the first one?  That is, this new code needs to be
> somewhere inside a loop over the result rels.
> 

Yeah, I think you're right. That's an embarrassing oversight :-(


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company





view thread (115+ messages)  latest in thread

Message-ID: <442cdcdc-5501-50f7-6efd-5df1668e11f9@enterprisedb.com>
Permalink:  ../442cdcdc-5501-50f7-6efd-5df1668e11f9@enterprisedb.com/
Also on:    postgresql.org/message-id/442cdcdc-5501-50f7-6efd-5df1668e11f9@enterprisedb.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@enterprisedb.com, tgl@sss.pgh.pa.us, amitlangote09@gmail.com, tsunakawa.takay@fujitsu.com, a.lepikhov@postgrespro.ru, tomas.vondra@2ndquadrant.com
  Subject: Re: POC: postgres_fdw insert batching
  In-Reply-To: <442cdcdc-5501-50f7-6efd-5df1668e11f9@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

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