Greg Stark wrote:
> On Tue, Nov 11, 2014 at 12:12 PM, Alvaro Herrera
> <[email protected]> wrote:
> > As far as I understand, the scan keys don't change within any given
> > scan; if they do, the rescan AM method is called, at which point we
> > should reset whatever is cached about the previous scan.
>
> But am I guaranteed that rescan will throw away the opcinfo struct and
> its opaque element? I guess that's the heart of the uncertainty I had.
Well, it should, and if not that's a bug, which should be fixed by the
attached (untested) patch.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index bd35cf6..441127f 100644
--- a/src/backend/access/brin/brin.c
+++ b/src/backend/access/brin/brin.c
@@ -519,6 +519,7 @@ brinrescan(PG_FUNCTION_ARGS)
{
IndexScanDesc scan = (IndexScanDesc) PG_GETARG_POINTER(0);
ScanKey scankey = (ScanKey) PG_GETARG_POINTER(1);
+ BrinOpaque *opaque;
/* other arguments ignored */
@@ -526,6 +527,14 @@ brinrescan(PG_FUNCTION_ARGS)
memmove(scan->keyData, scankey,
scan->numberOfKeys * sizeof(ScanKeyData));
+ /*
+ * Reinitialize the opaque struct; some opclasses might choose to
+ * cache per-scan info in there.
+ */
+ opaque = (BrinOpaque *) scan->opaque;
+ brin_free_desc(opaque->bo_bdesc);
+ opaque->bo_bdesc = brin_build_desc(scan->indexRelation);
+
PG_RETURN_VOID();
}
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
