Re: Asynchronous Append on postgres_fdw nodes.

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: etsuro(dot)fujita(at)gmail(dot)com
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pryzby(at)telsasoft(dot)com, a(dot)lepikhov(at)postgrespro(dot)ru, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Date: 2021-04-06 03:01:19
Message-ID: 20210406.120119.1353945975523521256.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the patch.

At Mon, 5 Apr 2021 17:15:47 +0900, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote in
> On Fri, Apr 2, 2021 at 12:09 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > The buildfarm points out that this fails under valgrind.
> > I easily reproduced it here:
> >
> > ==00:00:03:42.115 3410499== Syscall param epoll_wait(events) points to unaddressable byte(s)
> > ==00:00:03:42.115 3410499== at 0x58E926B: epoll_wait (epoll_wait.c:30)
> > ==00:00:03:42.115 3410499== by 0x7FC903: WaitEventSetWaitBlock (latch.c:1452)
...
> The reason for this would be that epoll_wait() is called with
> maxevents exceeding the size of the input event array in the test
> case. To fix, I adjusted the parameters to call the caller function

# s/input/output/ event array? (occurrred_events)

# I couldn't reproduce it, so sorry in advance if the following
# discussion is totally bogus..

I have nothing to say if it actually corrects the error, but the only
restriction of maxevents is that it must be positive, and in any case
epoll_wait returns no more than set->nevents events. So I'm a bit
wondering if that's the reason. In the first place I'm wondering if
valgrind is aware of that depth..

==00:00:03:42.115 3410499== Syscall param epoll_wait(events) points to unaddressable byte(s)
==00:00:03:42.115 3410499== at 0x58E926B: epoll_wait (epoll_wait.c:30)
...
==00:00:03:42.115 3410499== Address 0x10d10628 is 7,960 bytes inside a recently re-allocated block of size 8,192 alloc'd
==00:00:03:42.115 3410499== at 0x4C30F0B: malloc (vg_replace_malloc.c:307)
==00:00:03:42.115 3410499== by 0x94F9EA: AllocSetAlloc (aset.c:919)
==00:00:03:42.115 3410499== by 0x957BAF: MemoryContextAlloc (mcxt.c:809)
==00:00:03:42.115 3410499== by 0x958CC0: MemoryContextStrdup (mcxt.c:1179)
==00:00:03:42.115 3410499== by 0x516AE4: untransformRelOptions (reloptions.c:1336)
==00:00:03:42.115 3410499== by 0x6E6ADF: GetForeignTable (foreign.c:273)
==00:00:03:42.115 3410499== by 0xF3BD470: postgresBeginForeignScan (postgres_fdw.c:1479)

As Tom said, this looks like set->epoll_ret_events at the time points
to a palloc'ed memory resided within a realloced chunk.

Valgrind is saying that the variable (WaitEventSet*) set itself is a
valid pointer. On the other hand set->epoll_ret_events poinst to a
memory chunk that maybe valgrind thinks to have been freed. Since they
are in one allocation block so the pointer alone is broken if valgrind
is right in its complain.

I'm at a loss. How did you cause the error?

> WaitEventSetWait() with in ExecAppendAsyncEventWait(). Patch
> attached.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-04-06 03:13:04 Re: New IndexAM API controlling index vacuum strategies
Previous Message Dan Lynch 2021-04-06 02:51:46 Re: policies with security definer option for allowing inline optimization