| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Johannes Graën <johannes(at)selfnet(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: found xmin x from before relfrozenxid y |
| Date: | 2018-10-22 03:04:26 |
| Message-ID: | 82489.1540177466@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-10-21 10:24:16 -0400, Tom Lane wrote:
>> (Well, I see the short answer: the code layer throwing the error
>> doesn't know. But that could be fixed easily enough.)
> I wonder if the better approach wouldn't be to add an errcontext for
> vaccuum, where continually update the block number etc. Theres plenty of
> different sources of corruption that'd potentially cause debug messages
> or errors, and that should get most of them.
I did not chase this in detail, but it looked to me like there were
two code paths leading to heap_prepare_freeze_tuple, and only one
of them came from VACUUM. So adding a Relation parameter seemed like
a more promising fix for it. But possibly there are more error messages
we need to worry about besides this.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dinko Papak | 2018-10-22 04:44:13 | RE: Help with list partitioning on expression |
| Previous Message | David Rowley | 2018-10-22 01:50:47 | Re: Help with list partitioning on expression |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2018-10-22 03:59:35 | Re: Number of buckets/partitions of dshash |
| Previous Message | Michael Paquier | 2018-10-22 03:03:26 | Re: pgsql: Avoid duplicate XIDs at recovery when building initial snapshot |