Alexander Korotkov writes:
> On Wed, Apr 18, 2018 at 10:04 PM Tom Lane wrote:
>> It's hard to see a way around this that isn't fairly catastrophic for
>> performance :-(. But in any case it's wrapped up in order-of-operations
>> issues. I've long since forgotten the details, but I seem to have
On Wed, Apr 18, 2018 at 10:04 PM Tom Lane wrote:
> [ re-reads thread... ] The extra assumption you need in order to have
> trouble is that the blocks in question are dirty in shared buffers and
> have never been written to disk since their rows were deleted. Then
> the situation is that the page
On Wed, Apr 18, 2018 at 11:49 PM Tom Lane wrote:
> I wrote:
> > Relation truncation throws away the page image in memory without ever
> > writing it to disk. Then, if the subsequent file truncate step fails,
> > we have a problem, because anyone who goes looking for that page will
> > fetch it af
On Wed, Apr 18, 2018 at 04:49:17PM -0400, Tom Lane wrote:
> Just to throw out a possibly-crazy idea: maybe we could fix this by
> PANIC'ing if truncation fails, so that we replay the row deletions from
> WAL. Obviously this would be intolerable if the case were frequent,
> but we've had only two s
I wrote:
> Relation truncation throws away the page image in memory without ever
> writing it to disk. Then, if the subsequent file truncate step fails,
> we have a problem, because anyone who goes looking for that page will
> fetch it afresh from disk and see the tuples as live.
> There are WAL
"MauMau" writes:
> I'd like to continue to think of a solution and create a patch, based
> on the severity and how the customer will respond to our answer. I
> have a feeling that we have to say it's a bit serious, since it
> requires recovery from a base backup, not just rebuilding indexes.
> Th
From: Tom Lane
[ re-reads thread... ] The extra assumption you need in order to have
trouble is that the blocks in question are dirty in shared buffers and
have never been written to disk since their rows were deleted. Then
the situation is that the page image on disk shows the rows as live,
whil
"MauMau" writes:
> However, I have a question. How does the truncation failure in
> autovacuum lead to duplicate keys? The failed-to-be-truncated pages
> should only contain dead tuples, so pg_dump's table scan should ignore
> dead tuples in those pages.
[ re-reads thread... ] The extra assump
