public inbox for [email protected]  

help / color / mirror / Atom feed

From: Lars Aksel Opsahl <[email protected]>
To: Tom Lane <[email protected]>
To: Christophe Pettus <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows
Date: Tue, 10 Dec 2024 05:32:44 +0000
Message-ID: <AM7P189MB1028B388987982CEA5541DEF9D3D2@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <[email protected]>
References: <AM7P189MB10281DCA1FD196A5610484B29D3C2@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM>
	<[email protected]>
	<[email protected]>


________________________________
From: Tom Lane <[email protected]>
Sent: Monday, December 9, 2024 5:07 PM
To: Christophe Pettus <[email protected]>
Cc: Lars Aksel Opsahl <[email protected]>; [email protected] <[email protected]>
Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows

Christophe Pettus <[email protected]> writes:
>> On Dec 9, 2024, at 03:02, Lars Aksel Opsahl <[email protected]> wrote:
>> If there were a way to remove dead rows without requiring a commit from totally unrelated jobs, it would be much easier.

> (Strictly speaking, the rows you are describing are not "dead," in that they are still visible to some transaction.)

We do only very coarse-grained analysis of whether a row is "dead".
In principle, if vacuum had access to all the live snapshots of
all sessions, it could realize that a row really is dead even though
it's later than the current global xmin horizon.  But discovering that
would be quite difficult and therefore expensive.  Notably, sessions
would have to expose far more of their snapshot state than they do
today, and there would have to be interlocks to allow other sessions
to inspect that state safely, and that'd probably put us into much the
same sort of too-many-lock-conflicts problem that the OP has already.

I don't think there's any free lunch here.  Maybe there's some
other compromise between amount-of-state-exposed versus
dead-row-discoverability, but finding a better way would take
a great deal of creative effort and testing.

                        regards, tom lane


Hi

Thanks for the clarifications , back to more divide and conquer work then.

Lars

view thread (17+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows
  In-Reply-To: <AM7P189MB1028B388987982CEA5541DEF9D3D2@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox