Re: pg_dump --snapshot

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump --snapshot
Date: 2013-05-07 01:12:46
Message-ID: 5188550E.7070608@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/07/2013 06:37 AM, Joe Conway wrote:
> On 05/06/2013 03:00 PM, Stephen Frost wrote:
> > For example, I'm not sure that we need more information in the
> > WAL.. What we need is a way to tell VACUUM to skip over 'recently
> > modified' records and not mark them as dead until some time has
> > passed. This is essentially what we're already doing with the
> > feedback mechanism in replication, isn't it? Would it be possible
> > to make that a simple timer instead of requiring a replication
> > system which is feeding back that information based on queries
> > which are running on the replica?
>
> This sounds a lot like having an "idle in transaction" session hanging
> around. Could we use something akin to a prepared transaction to
> preserve the ability to use the snapshot? Maybe with an (optional)
> expiration timestamp?

I was thinking the same thing myself but assuming it was just another
one of my impractical ideas that're borne of lack of in-depth
understanding of the problem. A "lock holder" of some kind that's
independent of the session seems to be required here, either associated
directly with the snapshot or created after it and managed
independently. A prepared transaction created shortly after the commit
the snapshot refers to that holds all the required locks would seem to
serve the required purpose. A bit of a hack, but enough to make this
sane to use until/unless someone has the time/funding to do the major
rework needed to make this work "right".

- --
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRiFUOAAoJELBXNkqjr+S2TksH/2KqL+7eUxyE9aBg3Ci3gSc7
OP0y3jk34mpG5aXtzCcVD8jC81bDT0eRGDAEnjAliHW/UCWkaxdX6ziY3BRIfJ7B
vvpArYEA3I0CgewGypciT3/692iDVAvTsVXnd1Vx4jJLiyYt83MYr7EmOpsJwzG1
NJ7MFjAV+61SBW8uRwSopvqm2e6MZiYjCR3orvqBm7t3xKeuXAOv4zM5pM+m4hz5
gGB53XKPNsyr2m9pX8ScxprHvkAjflXB6QQBR07XBrkb1kWXifSKxw7bsscxP4hv
GQxcRzex2wWVJ654NH7v/QNt4Ynp2qUpl1tpTloIzv0aF+BTLXdlbGLpkjJvwRU=
=n/k9
-----END PGP SIGNATURE-----

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-05-07 01:27:50 Re: pg_dump --snapshot
Previous Message Stephen Frost 2013-05-07 01:07:36 Re: pg_dump --snapshot