From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...) |
Date: | 2020-06-23 13:53:54 |
Message-ID: | 20200623135354.GD4107@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 23, 2020 at 12:14:40AM -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I am only suggesting that where you save the old location, as currently
> > done with LVRelStats olderrinfo, you instead use a more specific
> > type. Not that you should pass that anywhere (except for
> > update_vacuum_error_info).
>
> As things currently stand, I don't think we need another struct
> type at all. ISTM we should hard-wire the handling of indname
> as I suggested above. Then there are only two fields to be dealt
> with, and we could just as well save them in simple local variables.
>
> If there's a clear future path to needing to save/restore more
> fields, then maybe another struct type would be useful ... but
> right now the struct type declaration itself would take more
> lines of code than it would save.
Updated patches for consideration. I left the "struct" patch there to show
what it'd look like.
--
Justin
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Rename-from-errcbarg.patch | text/x-diff | 1.6 KB |
v2-0002-Specially-save-the-index-name-in-lazy_-vacuum-cle.patch | text/x-diff | 6.1 KB |
v2-0003-Save-phase-blkno-in-local-variables-for-consisten.patch | text/x-diff | 4.3 KB |
v2-0004-Move-error-information-into-a-separate-struct.patch | text/x-diff | 15.0 KB |
v2-0005-Update-functions-to-pass-only-errinfo-struct.patch | text/x-diff | 9.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-06-23 13:54:48 | Re: Building postgresql with higher major version of separate libpq package |
Previous Message | Masahiko Sawada | 2020-06-23 13:46:14 | Re: Internal key management system |