From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Subject: Re: pgsql: Update pg_upgrade test for reg* to include regrole and
 regnamesp
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-committers@lists.postgresql.org
References: <E1gRS1V-0007eS-1p@gemulon.postgresql.org>
 <8863.1543297423@sss.pgh.pa.us>
 <20181127063226.mpyijg3jwrmmm3rr@alap3.anarazel.de>
Message-ID: <6f5edd28-e55f-7399-d89c-d2d1ed2d1e51@2ndQuadrant.com>
Date: Tue, 27 Nov 2018 10:32:05 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181127063226.mpyijg3jwrmmm3rr@alap3.anarazel.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-MW
Precedence: bulk


On 11/27/18 1:32 AM, Andres Freund wrote:
>
> The cross-version bug around pg_largeobject_metadata ought to be fixed
> now. I'm hoping for a response by Andrew about the ordering bit, you're
> welcome to opine on that too.
>
> I see that prairiedog
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2018-11-27%2005%3A30%3A39
> failed just it's last run, but I'm not clear whether that's just a
> random failure, or something I can't don't recognize without further
> information.


The report is that the dumps differ. My bet is that this is another 
instance of the LO ordering issue. I can handle that in the 
cross-version tests because they are completely under my control (see 
<https://github.com/PGBuildFarm/client-code/commit/9ca42ac1783a8cf99c73b4f7c52bd05a6024669d>) 
, but not in the builtin test, which has this:


    if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
         echo PASSED
         exit 0
    else
         echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
         echo "dumps were not identical"
         exit 1
    fi

So that's all we know. Maybe we should change the script to output the 
diff, or at least some of it, say the first 1000 lines.

In any case, I think we will probably need to bite the bullet and have 
pg_dump render LOs in OID order. Not sure if that needs to be always on, 
or an option.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services