| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, 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 04:14:40 |
| Message-ID: | 2125633.1592885680@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-06-23 04:26:10 | Re: Transactions involving multiple postgres foreign servers, take 2 |
| Previous Message | Amit Kapila | 2020-06-23 04:12:09 | Re: Global snapshots |