From: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
---|---|
To: | Nick Renders <postgres(at)arcict(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PL/pgSQL question about EXCEPTION clause & corrupt records |
Date: | 2020-02-17 18:17:26 |
Message-ID: | 778b4c5c-312f-2e64-b690-5ddc9443966b@ardentperf.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2/17/20 08:23, Jeremy Schneider wrote:
> FWIW, Bertrand blogged an even faster way to do this about a month ago -
> using pageinspect and processing blocks instead of rows
>
> https://bdrouvot.wordpress.com/2020/01/18/retrieve-postgresql-variable-length-storage-information-thanks-to-pageinspect/
>
>
>> On Feb 17, 2020, at 03:32, Nick Renders <postgres(at)arcict(dot)com> wrote:
>>
>> The problem is that I don't know which column is corrupt. But I found
>> a solution: by simply copying the record into another variable, the
>> values are parsed and the TOAST errors are thrown.
>>
>> In case anyone's interested, here's my code, based on an example from
>> http://www.databasesoup.com/2013/10/de-corrupting-toast-tables.html
Apologies - sent that slightly rushed email while I was taking the bus
to the office this morning and linked the wrong blog post :D
Here's the right one, showing a much faster way to identify which tuple
links to a bad toast row:
-Jeremy
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-02-17 18:19:52 | Re: Cases where alter table set type varchar(longer length) still needs table rewrite |
Previous Message | Jimmy Angelakos | 2020-02-17 16:55:29 | Re: parsing xml with PG 9.2.4 |