| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Nikhil Sontakke <nikhils(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Logical Decoding and HeapTupleSatisfiesVacuum assumptions |
| Date: | 2018-01-29 17:04:52 |
| Message-ID: | 891e409b-e792-5d1f-2196-7855051589f9@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01/29/2018 03:17 PM, Simon Riggs wrote:
> On 29 January 2018 at 14:13, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
>> 4) inspect the new row (which we still have in reorderbuffer)
>>
>> 5) Kabooom! The row has column "c" which we don't see in the catalog.
>
> We don't use caches? Why does a cache miss cause it to explode?
>
We do use caches (and we invalidate them), of course.
But the problem is that by the time we get to lookup the row, it may be
either removed by VACUUM (because the catalog cleanup is more
aggressive) or not reachable using an index (which is the HOT issue
pointed out by Robert earlier in this thread).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2018-01-29 17:08:33 | Re: [HACKERS] MERGE SQL Statement for PG11 |
| Previous Message | Simon Riggs | 2018-01-29 17:03:08 | Re: [HACKERS] MERGE SQL Statement for PG11 |