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
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 tw
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 woul
Robert Haas writes:
> On Tue, Jul 16, 2013 at 9:50 AM, Noah Misch 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; however, I'm assuming we would ot
On Tue, Jul 16, 2013 at 9:50 AM, Noah Misch 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 error abou
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
