Consider this sequence of commands:
create type rowtype as (c int, d int);
create temp table t of rowtype;
\c -
drop type rowtype cascade;
Since the switch to MVCC catalog scans, it exhibits the following error about
10% of the time on my system:
CREATE TYPE
CREATE TABLE
You are
On Tue, Jul 16, 2013 at 9:50 AM, Noah Misch n...@leadboat.com wrote:
Consider this sequence of commands:
create type rowtype as (c int, d int);
create temp table t of rowtype;
\c -
drop type rowtype cascade;
Since the switch to MVCC catalog scans, it exhibits the following
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 16, 2013 at 9:50 AM, Noah Misch n...@leadboat.com wrote:
Let's fix this by having systable_recheck_tuple() acquire a fresh catalog
MVCC
snapshot and recheck against that. I believe it would also be fully safe to
use SnapshotNow here;
On 2013-07-16 09:50:07 -0400, Noah Misch wrote:
With \c, in general, you may end up executing commands under the new session
before the old backend has finished exiting. For this test case specifically,
the two backends' attempts to drop table t regularly overlap. The old
backend would drop
On Tue, Jul 16, 2013 at 05:56:10PM +0200, Andres Freund wrote:
On 2013-07-16 09:50:07 -0400, Noah Misch wrote:
With \c, in general, you may end up executing commands under the new
session
before the old backend has finished exiting. For this test case
specifically,
the two backends'
On Tue, Jul 16, 2013 at 11:27:02AM -0400, Robert Haas wrote:
I recommend reworking the header comment to avoid mention of
SnapshotNow, since if we get rid of SnapshotNow, the reference might
not be too clear to far-future hackers.
+ /*
+ * For a scan using a non-MVCC snapshot like
