Re: Store data in pg_toast for custom type fails (bug?) - Mailing list pgsql-hackers

From Honza
Subject Re: Store data in pg_toast for custom type fails (bug?)
Date
Msg-id 53565033.4010905@gmail.com
Whole thread Raw
In response to Re: Store data in pg_toast for custom type fails (bug?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Store data in pg_toast for custom type fails (bug?)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 03/28/2014 07:02 PM, Tom Lane wrote:
> I wrote:
>> Honza <honzap@gmail.com> writes:
>>> after a months I've found a time to make test-case for this bug, probably:
> 
>> Confirmed that this reproduces a problem on HEAD.  Will look into it,
>> thanks!
> 
> I believe I understand what's going on here, and it's not quite as
> exciting as it first appears.  The issue is that we are failing to
> honor the "toasting goes only one level deep" rule in the specific
> case of arrays of composite type.  So while it's definitely a nasty
> bug, it affects only narrow use cases, and doesn't call into question
> our whole vacuuming strategy or anything like that.

I would like to ask if there is anything new in this bug?

I've made a simple script which checks if daily backups are complete. For a week I've been deleting
a few records every day and hope the backup will be successfully done after that. The problem is
it's not possible to read all data from table during making backup using pg_dump too (not only
selecting data from table). I've found there is only one possibility to temporarily solve it and
have full backups - delete corrupted records.

Thanks for any news,

Jan



pgsql-hackers by date:

Previous
From: Jov
Date:
Subject: Re: AXLE Plans for 9.5 and 9.6
Next
From: Florian Weimer
Date:
Subject: Re: RFC: Async query processing