Re: lazy detoasting

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lazy detoasting
Date: 2018-04-08 06:01:26
Message-ID: 87sh86gsds.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Chapman" == Chapman Flack <chap(at)anastigmatix(dot)net> writes:

Chapman> Please bear with me as I check my understanding of snapshot
Chapman> management by looking at PersistHoldablePortal(). There's a
Chapman> PushActiveSnapshot(queryDesc->snapshot) in there. Is that
Chapman> because:

Chapman> (d) some other reason I haven't thought of ?

It has to be pushed as the active snapshot so that it's the snapshot
that the executor uses to run the query to populate the tuplestore which
becomes the "held" portal content.

I think you're confusing the stack of active snapshots with the registry
of snapshots. The snapshot of a portal that's not currently running in
the executor won't be on the stack, but it will be registered (which is
enough to maintain the session's reported xmin, which is what prevents
visible data from being vacuumed away).

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-04-08 06:37:34 Re: pgsql: Support partition pruning at execution time
Previous Message Fabien COELHO 2018-04-08 05:58:31 Re: [HACKERS] pgbench - allow to store select results into variables