Access to old versions of a row

Started by Matthias Apitzover 2 years ago4 messagesbugs
Jump to latest
#1Matthias Apitz
guru@unixarea.de

As long as the vacuum is not run, older versions of a given row should
be "somewhere". Is there a way to read them?

Thanks

matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

#2Vik Fearing
vik@postgresfriends.org
In reply to: Matthias Apitz (#1)
Re: Access to old versions of a row

On 10/8/23 16:25, Matthias Apitz wrote:

As long as the vacuum is not run, older versions of a given row should
be "somewhere". Is there a way to read them?

No.

But there is a pg_dirtyread extension that can do it.
https://github.com/df7cb/pg_dirtyread
--
Vik Fearing

#3Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Matthias Apitz (#1)
Re: Access to old versions of a row

On 2023-Oct-08, Matthias Apitz wrote:

As long as the vacuum is not run, older versions of a given row should
be "somewhere". Is there a way to read them?

Maybe with
https://github.com/df7cb/pg_dirtyread

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

#4Andres Freund
andres@anarazel.de
In reply to: Vik Fearing (#2)
Re: Access to old versions of a row

Hi,

On 2023-10-08 21:35:15 +0200, Vik Fearing wrote:

On 10/8/23 16:25, Matthias Apitz wrote:

As long as the vacuum is not run, older versions of a given row should
be "somewhere". Is there a way to read them?

(auto-)vacuum not having processed a table doesn't guarantee that row versions
have not been removed. Most importantly, on-access pruning can lead to row
versions being removed. There's also the issue that the toast table could
have been autovacuumed independently from the "main" table.

No.

But there is a pg_dirtyread extension that can do it.
https://github.com/df7cb/pg_dirtyread

Note that there's a lot of potential for bogus data and even crashes when
using something like this. Which is fine when used for data recovery purposes,
but not for many other potential usecases.

Greetings,

Andres Freund