Writeable CTEs and empty relations - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Writeable CTEs and empty relations
Date
Msg-id 4B70663B.1020409@cs.helsinki.fi
Whole thread Raw
Responses Re: Writeable CTEs and empty relations  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Writeable CTEs and empty relations  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
List pgsql-hackers
Hi,

While playing around with another issue with the patch, I came across
the following:

=> create table foo(a int);
CREATE TABLE
=> with t as (insert into foo values(0)) select * from foo;a
---
(0 rows)

I traced this down to heapam.c, which has this:

/** return null immediately if relation is empty*/if (scan->rs_nblocks == 0){    Assert(!BufferIsValid(scan->rs_cbuf));
  tuple->t_data = NULL;    return;}
 

and

/*
* Determine the number of blocks we have to scan.
*
* It is sufficient to do this once at scan start, since any tuples added
* while the scan is in progress will be invisible to my snapshot anyway.
* (That is not true when using a non-MVCC snapshot.  However, we couldn't
* guarantee to return tuples added after scan start anyway, since they
* might go into pages we already scanned.      To guarantee consistent
* results for a non-MVCC snapshot, the caller must hold some higher-level
* lock that ensures the interesting tuple(s) won't change.)
*/
scan->rs_nblocks = RelationGetNumberOfBlocks(scan->rs_rd);


This doesn't exactly work anymore since we modify the snapshot after
calling ExecInitScan().  I'm not really familiar with this part of the
code, so I'm asking: is there a simple enough way around this?  Would
updating scan->rs_nblocks before scanning the first tuple be OK?


Regards,
Marko Tiikkaja


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Next
From: Josh Berkus
Date:
Subject: Re: review: More frame options in window functions