| From: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "ofir(dot)manor" <ofir(dot)manor(at)gmail(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #13725: Logical Decoding - wrong results with large transactions and unfortunate timing |
| Date: | 2015-10-26 11:16:40 |
| Message-ID: | CACACo5TM5sxyqg8=QL7-L1DpnVg3_pNsRXRwsszYK6RXgkAHDA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, Oct 26, 2015 at 12:05 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > So we compute end_of_wal before entering the loop, but the WAL keeps
> > growing as we read through it.
>
> So?
>
> > If we do it correctly, there's potential that the loop will never finish
> if
> > the WAL grows faster than we can decode it.
>
> > Shouldn't we also try to re-write this SRF to support
> > SFRM_ValuePerCall?
>
> Why? ValuePercall gets materialized into a tuplestore as well, unless
> you call it from the select list.
>
Ah, yes: good catch. Then it makes less sense to change this indeed.
--
Alex
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ofir.manor | 2015-10-26 11:21:44 | Re: BUG #13725: Logical Decoding - wrong results with large transactions and unfortunate timing |
| Previous Message | Andres Freund | 2015-10-26 11:05:02 | Re: BUG #13725: Logical Decoding - wrong results with large transactions and unfortunate timing |