Skip site navigation (1) Skip section navigation (2)

Re: [v9.2] Fix Leaky View Problem

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Kohei(dot)Kaigai(at)emea(dot)nec(dot)com, thom(at)linux(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [v9.2] Fix Leaky View Problem
Date: 2012-01-21 20:51:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jan 17, 2012 at 7:08 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sun, Jan 8, 2012 at 10:32 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>>> I guess you concerned about that expected/select_views_1.out is
>>>> patched, not expected/select_views.out.
>>>> I'm not sure the reason why regression test script tries to make diff
>>>> between results/select_views and expected/select_views_1.out.
>>> select_views.out and select_views_1.out are alternate expected output
>>> files.  The regression tests pass if the actual output matches either
>>> one.  Thus, you have to patch both.
>> It was new for me. The attached patch updates both of the expected
>> files, however, I'm not certain whether select_view.out is suitable, or
>> not, because my results/select_view.out matched with expected/select_view_1.out.
> Committed.  We'll see what the buildfarm thinks.

This passes installcheck initially.  Then upon second invocation of
installcheck, it fails.

It creates the role "alice", and doesn't clean it up.  On next
invocation alice already exists and cases a failure in test



In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-01-21 22:13:55
Subject: Re: Review of patch renaming constraints
Previous:From: Noah MischDate: 2012-01-21 20:42:23
Subject: Re: [PATCH] Support for foreign keys with arrays

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group