| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com>, contact(at)yorhel(dot)nl, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16846: "retrieved too many tuples in a bounded sort" |
| Date: | 2021-02-15 15:18:46 |
| Message-ID: | 2251077.1613402326@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
James Coleman <jtc331(at)gmail(dot)com> writes:
> On Thu, Feb 11, 2021 at 12:06 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I stared at this for awhile and eventually convinced myself that it
>> implemented the same logic, but it still seems overly complex. We
>> do not need either the firstTuple or lastTuple flags, and we could
>> convert the nTuple adjustments into a normal for-loop with (IMO)
>> much greater intelligibility. What do you think of the attached?
> Yes, that looks even better. Not sure how I missed that I'd just
> reimplemented a normal for-loop with firstTuple/lastTuple conditions,
> but I guess that's the benefit of coming at it with fresh eyes and
> without the history of how it got the way it was.
> +1 on committing v2.
Sounds good, pushed.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2021-02-15 20:53:41 | BUG #16867: savepoints vs. commit and chain |
| Previous Message | PG Bug reporting form | 2021-02-15 15:12:10 | BUG #16866: pg_basebackup Windows Server 2016 |