2000-10-24 03:38:44 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_largeobject.c
|
|
|
|
* routines to support manipulation of the pg_largeobject relation
|
|
|
|
*
|
2015-01-06 17:43:47 +01:00
|
|
|
* Portions Copyright (c) 1996-2015, PostgreSQL Global Development Group
|
2000-10-24 03:38:44 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/catalog/pg_largeobject.c
|
2000-10-24 03:38:44 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "access/genam.h"
|
|
|
|
#include "access/heapam.h"
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.h"
|
2009-12-11 04:34:57 +01:00
|
|
|
#include "access/sysattr.h"
|
|
|
|
#include "catalog/dependency.h"
|
2000-10-24 03:38:44 +02:00
|
|
|
#include "catalog/indexing.h"
|
|
|
|
#include "catalog/pg_largeobject.h"
|
2009-12-11 04:34:57 +01:00
|
|
|
#include "catalog/pg_largeobject_metadata.h"
|
|
|
|
#include "miscadmin.h"
|
|
|
|
#include "utils/acl.h"
|
2000-10-24 03:38:44 +02:00
|
|
|
#include "utils/fmgroids.h"
|
2008-06-19 02:46:06 +02:00
|
|
|
#include "utils/rel.h"
|
2008-03-26 22:10:39 +01:00
|
|
|
#include "utils/tqual.h"
|
2000-10-24 03:38:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a large object having the given LO identifier.
|
|
|
|
*
|
2009-12-11 04:34:57 +01:00
|
|
|
* We create a new large object by inserting an entry into
|
|
|
|
* pg_largeobject_metadata without any data pages, so that the object
|
|
|
|
* will appear to exist with size 0.
|
2000-10-24 03:38:44 +02:00
|
|
|
*/
|
2009-12-11 04:34:57 +01:00
|
|
|
Oid
|
2000-10-24 03:38:44 +02:00
|
|
|
LargeObjectCreate(Oid loid)
|
|
|
|
{
|
2009-12-11 04:34:57 +01:00
|
|
|
Relation pg_lo_meta;
|
2000-10-24 03:38:44 +02:00
|
|
|
HeapTuple ntup;
|
2009-12-11 04:34:57 +01:00
|
|
|
Oid loid_new;
|
|
|
|
Datum values[Natts_pg_largeobject_metadata];
|
|
|
|
bool nulls[Natts_pg_largeobject_metadata];
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
pg_lo_meta = heap_open(LargeObjectMetadataRelationId,
|
|
|
|
RowExclusiveLock);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
|
|
|
/*
|
2009-12-11 04:34:57 +01:00
|
|
|
* Insert metadata of the largeobject
|
2000-10-24 03:38:44 +02:00
|
|
|
*/
|
2009-12-11 04:34:57 +01:00
|
|
|
memset(values, 0, sizeof(values));
|
|
|
|
memset(nulls, false, sizeof(nulls));
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
values[Anum_pg_largeobject_metadata_lomowner - 1]
|
|
|
|
= ObjectIdGetDatum(GetUserId());
|
|
|
|
nulls[Anum_pg_largeobject_metadata_lomacl - 1] = true;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
ntup = heap_form_tuple(RelationGetDescr(pg_lo_meta),
|
|
|
|
values, nulls);
|
|
|
|
if (OidIsValid(loid))
|
|
|
|
HeapTupleSetOid(ntup, loid);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
loid_new = simple_heap_insert(pg_lo_meta, ntup);
|
|
|
|
Assert(!OidIsValid(loid) || loid == loid_new);
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
CatalogUpdateIndexes(pg_lo_meta, ntup);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
|
|
|
heap_freetuple(ntup);
|
2009-12-11 04:34:57 +01:00
|
|
|
|
|
|
|
heap_close(pg_lo_meta, RowExclusiveLock);
|
|
|
|
|
|
|
|
return loid_new;
|
2000-10-24 03:38:44 +02:00
|
|
|
}
|
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Drop a large object having the given LO identifier. Both the data pages
|
2009-12-21 02:34:11 +01:00
|
|
|
* and metadata must be dropped.
|
2009-12-11 04:34:57 +01:00
|
|
|
*/
|
2000-10-24 03:38:44 +02:00
|
|
|
void
|
|
|
|
LargeObjectDrop(Oid loid)
|
|
|
|
{
|
2009-12-11 04:34:57 +01:00
|
|
|
Relation pg_lo_meta;
|
2000-10-24 03:38:44 +02:00
|
|
|
Relation pg_largeobject;
|
2001-03-22 05:01:46 +01:00
|
|
|
ScanKeyData skey[1];
|
2009-12-11 04:34:57 +01:00
|
|
|
SysScanDesc scan;
|
2002-05-21 01:51:44 +02:00
|
|
|
HeapTuple tuple;
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
pg_lo_meta = heap_open(LargeObjectMetadataRelationId,
|
|
|
|
RowExclusiveLock);
|
|
|
|
|
|
|
|
pg_largeobject = heap_open(LargeObjectRelationId,
|
|
|
|
RowExclusiveLock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Delete an entry from pg_largeobject_metadata
|
|
|
|
*/
|
2003-11-12 22:15:59 +01:00
|
|
|
ScanKeyInit(&skey[0],
|
2009-12-11 04:34:57 +01:00
|
|
|
ObjectIdAttributeNumber,
|
2003-11-12 22:15:59 +01:00
|
|
|
BTEqualStrategyNumber, F_OIDEQ,
|
2010-02-26 03:01:40 +01:00
|
|
|
ObjectIdGetDatum(loid));
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
scan = systable_beginscan(pg_lo_meta,
|
|
|
|
LargeObjectMetadataOidIndexId, true,
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
NULL, 1, skey);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
tuple = systable_getnext(scan);
|
|
|
|
if (!HeapTupleIsValid(tuple))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("large object %u does not exist", loid)));
|
|
|
|
|
|
|
|
simple_heap_delete(pg_lo_meta, &tuple->t_self);
|
|
|
|
|
|
|
|
systable_endscan(scan);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Delete all the associated entries from pg_largeobject
|
|
|
|
*/
|
|
|
|
ScanKeyInit(&skey[0],
|
|
|
|
Anum_pg_largeobject_loid,
|
|
|
|
BTEqualStrategyNumber, F_OIDEQ,
|
|
|
|
ObjectIdGetDatum(loid));
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
scan = systable_beginscan(pg_largeobject,
|
|
|
|
LargeObjectLOidPNIndexId, true,
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
NULL, 1, skey);
|
2009-12-11 04:34:57 +01:00
|
|
|
while (HeapTupleIsValid(tuple = systable_getnext(scan)))
|
2000-10-24 03:38:44 +02:00
|
|
|
{
|
2002-05-21 01:51:44 +02:00
|
|
|
simple_heap_delete(pg_largeobject, &tuple->t_self);
|
2000-10-24 03:38:44 +02:00
|
|
|
}
|
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
systable_endscan(scan);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2003-09-24 20:54:02 +02:00
|
|
|
heap_close(pg_largeobject, RowExclusiveLock);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
heap_close(pg_lo_meta, RowExclusiveLock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* LargeObjectExists
|
|
|
|
*
|
2010-06-09 23:14:28 +02:00
|
|
|
* We don't use the system cache for large object metadata, for fear of
|
2009-12-21 02:34:11 +01:00
|
|
|
* using too much local memory.
|
2009-12-11 04:34:57 +01:00
|
|
|
*
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
* This function always scans the system catalog using an up-to-date snapshot,
|
|
|
|
* so it should not be used when a large object is opened in read-only mode
|
|
|
|
* (because large objects opened in read only mode are supposed to be viewed
|
|
|
|
* relative to the caller's snapshot, whereas in read-write mode they are
|
|
|
|
* relative to a current snapshot).
|
2009-12-11 04:34:57 +01:00
|
|
|
*/
|
2000-10-24 03:38:44 +02:00
|
|
|
bool
|
|
|
|
LargeObjectExists(Oid loid)
|
|
|
|
{
|
2009-12-11 04:34:57 +01:00
|
|
|
Relation pg_lo_meta;
|
2010-02-26 03:01:40 +01:00
|
|
|
ScanKeyData skey[1];
|
|
|
|
SysScanDesc sd;
|
2009-12-11 04:34:57 +01:00
|
|
|
HeapTuple tuple;
|
2000-10-24 03:38:44 +02:00
|
|
|
bool retval = false;
|
|
|
|
|
2003-11-12 22:15:59 +01:00
|
|
|
ScanKeyInit(&skey[0],
|
2009-12-11 04:34:57 +01:00
|
|
|
ObjectIdAttributeNumber,
|
2003-11-12 22:15:59 +01:00
|
|
|
BTEqualStrategyNumber, F_OIDEQ,
|
|
|
|
ObjectIdGetDatum(loid));
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
pg_lo_meta = heap_open(LargeObjectMetadataRelationId,
|
|
|
|
AccessShareLock);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
sd = systable_beginscan(pg_lo_meta,
|
|
|
|
LargeObjectMetadataOidIndexId, true,
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
NULL, 1, skey);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
tuple = systable_getnext(sd);
|
|
|
|
if (HeapTupleIsValid(tuple))
|
2002-05-21 01:51:44 +02:00
|
|
|
retval = true;
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2003-09-24 20:54:02 +02:00
|
|
|
systable_endscan(sd);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
2009-12-11 04:34:57 +01:00
|
|
|
heap_close(pg_lo_meta, AccessShareLock);
|
2000-10-24 03:38:44 +02:00
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|