pgsql: Prevent "snapshot too old" from trying to return pruned TOAST tu
Prevent "snapshot too old" from trying to return pruned TOAST tuples.
Previously, we tested for MVCC snapshots to see whether they were too
old, but not TOAST snapshots, which can lead to complaints about missing
TOAST chunks if those chunks are subject to early pruning. Ideally,
the threshold lsn and timestamp for a TOAST snapshot would be that of
the corresponding MVCC snapshot, but since we have no way of deciding
which MVCC snapshot was used to fetch the TOAST pointer, use the oldest
active or registered snapshot instead.
Reported by Andres Freund, who also sketched out what the fix should
look like. Patch by me, reviewed by Amit Kapila.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/3e2f3c2e423b3ae906668c186bac79522b8e3e29
Modified Files
--------------
src/backend/access/heap/tuptoaster.c | 37 +++++++++++++++++++++++++++++++----
src/backend/utils/time/snapmgr.c | 38 ++++++++++++++++++++++++++++++++++++
src/backend/utils/time/tqual.c | 1 -
src/include/storage/bufmgr.h | 3 ++-
src/include/utils/snapmgr.h | 1 +
src/include/utils/tqual.h | 32 ++++++++++++++++++++----------
6 files changed, 96 insertions(+), 16 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Robert Haas <rhaas@postgresql.org> writes:
Prevent "snapshot too old" from trying to return pruned TOAST tuples.
Looks like this patch broke the build on castoroides. Recommend
changing InitToastSnapshot into a macro. (There's a reason why
InitDirtySnapshot is a macro.)
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Thu, Aug 4, 2016 at 7:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <rhaas@postgresql.org> writes:
Prevent "snapshot too old" from trying to return pruned TOAST tuples.
Looks like this patch broke the build on castoroides. Recommend
changing InitToastSnapshot into a macro. (There's a reason why
InitDirtySnapshot is a macro.)
What is the reason? We refuse to separate frontend and backend
headers in any sort of principled way?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Thu, Aug 4, 2016 at 10:58 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Aug 4, 2016 at 7:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <rhaas@postgresql.org> writes:
Prevent "snapshot too old" from trying to return pruned TOAST tuples.
Looks like this patch broke the build on castoroides. Recommend
changing InitToastSnapshot into a macro. (There's a reason why
InitDirtySnapshot is a macro.)What is the reason? We refuse to separate frontend and backend
headers in any sort of principled way?
That was poorly phrased. I'll try again: I can't see any reason for
using a macro here except that it allows frontend code to compile this
without breaking. But that doesn't seem like a very good way of
solving that problem. There's surely no way for a casual reader of
the code to realize that macros can be used here and inline functions
cannot, especially because this works apparently works fine on most
machines, including mine.
Here's a patch. Is this what you want?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
init-toast-snapshot-macro-v1.patchtext/x-patch; charset=US-ASCII; name=init-toast-snapshot-macro-v1.patchDownload+5-8
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Aug 4, 2016 at 10:58 PM, Robert Haas <robertmhaas@gmail.com> wrote:
What is the reason? We refuse to separate frontend and backend
headers in any sort of principled way?
That was poorly phrased. I'll try again: I can't see any reason for
using a macro here except that it allows frontend code to compile this
without breaking.
Well, the alternative would be to put "#ifndef FRONTEND" around the
static-inline function. That's not very pretty either, and it's
inconsistent with the existing precedent (ie, InitDirtySnapshot).
Also, it presumes that a non-backend includer actually has defined
FRONTEND; that seems to be the case for pg_xlogdump but I do not
think we do that everywhere.
Here's a patch. Is this what you want?
OK by me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Aug 5, 2016 at 11:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Aug 4, 2016 at 10:58 PM, Robert Haas <robertmhaas@gmail.com> wrote:
What is the reason? We refuse to separate frontend and backend
headers in any sort of principled way?That was poorly phrased. I'll try again: I can't see any reason for
using a macro here except that it allows frontend code to compile this
without breaking.Well, the alternative would be to put "#ifndef FRONTEND" around the
static-inline function. That's not very pretty either, and it's
inconsistent with the existing precedent (ie, InitDirtySnapshot).
Also, it presumes that a non-backend includer actually has defined
FRONTEND; that seems to be the case for pg_xlogdump but I do not
think we do that everywhere.
That may not be pretty, but it'd be a lot more transparent. If I see
#ifndef FRONTEND, I think, oh, that's protecting some stuff that
shouldn't be included in front-end compiles. If I see a macro, I not
necessarily think of the fact that this may be a way of preventing
that code from being compiled in front-end compiles.
Here's a patch. Is this what you want?
OK by me.
OK, committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers