On Sat, Apr 5, 2014 at 7:12 AM, Andres Freund wrote:
> On 2014-04-03 14:49:54 -0400, Andrew Dunstan wrote:
>> I've been kind of hoping that someone would step up on both these items, but
>> the trail seems to have gone cold.
>>
>> I'm going to put out the new buildfarm release with the new module
On 2014-04-03 14:49:54 -0400, Andrew Dunstan wrote:
> I've been kind of hoping that someone would step up on both these items, but
> the trail seems to have gone cold.
>
> I'm going to put out the new buildfarm release with the new module to run
> test_decoding check. But of course It won't have M
On 03/27/2014 01:09 PM, Tom Lane wrote:
Alvaro Herrera writes:
Note that "make check" in contrib is substantially slower than "make
installcheck" --- it creates a temporary installation for each contrib
module. If we make buildfarm run installcheck for all modules, that
might be a problem for
On Thu, Mar 27, 2014 at 11:02:55AM -0400, Bruce Momjian wrote:
> On Thu, Mar 27, 2014 at 10:30:59AM -0400, Bruce Momjian wrote:
> > On Thu, Mar 27, 2014 at 10:13:36AM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> > > >>
On 03/27/2014 05:15 PM, Andres Freund wrote:
On 2014-03-27 12:56:02 -0300, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not looking so good.
Sho
On 2014-03-27 12:56:02 -0300, Alvaro Herrera wrote:
> Also, there's the vcregress.pl business. The way it essentially
> duplicates pg_upgrade/test.sh is rather messy; and now that
> test_decoding also needs similar treatment, it's not looking so good.
> Should we consider redoing that stuff in a w
On 2014-03-27 13:52:19 -0400, Noah Misch wrote:
> On Thu, Mar 27, 2014 at 12:56:02PM -0300, Alvaro Herrera wrote:
> > Also, there's the vcregress.pl business. The way it essentially
> > duplicates pg_upgrade/test.sh is rather messy; and now that
> > test_decoding also needs similar treatment, it's
On 03/27/2014 04:31 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 03/27/2014 11:56 AM, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not lookin
Andrew Dunstan writes:
> On 03/27/2014 11:56 AM, Alvaro Herrera wrote:
>> Also, there's the vcregress.pl business. The way it essentially
>> duplicates pg_upgrade/test.sh is rather messy; and now that
>> test_decoding also needs similar treatment, it's not looking so good.
>> Should we consider r
On 03/27/2014 11:56 AM, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not looking so good.
Should we consider redoing that stuff in a way that al
On Thu, Mar 27, 2014 at 12:56:02PM -0300, Alvaro Herrera wrote:
> Also, there's the vcregress.pl business. The way it essentially
> duplicates pg_upgrade/test.sh is rather messy; and now that
> test_decoding also needs similar treatment, it's not looking so good.
> Should we consider redoing that
Alvaro Herrera writes:
> Note that "make check" in contrib is substantially slower than "make
> installcheck" --- it creates a temporary installation for each contrib
> module. If we make buildfarm run installcheck for all modules, that
> might be a problem for some animals. Would it be possible
On 2014-03-27 11:12:41 -0400, Andrew Dunstan wrote:
> >No, unless you're building with some options the buildfarm doesn't
> >exercise. (Well, the buildfarm does installcheck rather than check for
> >contrib, but that should not matter.)
> And I see it does. I missed that, and I don't think anyone
Andrew Dunstan wrote:
> For several reasons. It's not simply a matter of running that
> command. You also have to bundle up the various log files. Also, if
> all we do is "check-world" and it fails that fact gives us
> relatively little information, whereas if it passes "make check" but
> fails "m
On 03/27/2014 11:34 AM, Christoph Berg wrote:
Re: Andrew Dunstan 2014-03-27 <53344465.6010...@dunslane.net>
On 03/27/2014 11:27 AM, Tom Lane wrote:
Andrew Dunstan writes:
I guess we'd better add a make-contrib-check step to the buildfarm. I
was just prepping a release, so I'll delay that whi
Re: Andrew Dunstan 2014-03-27 <53344465.6010...@dunslane.net>
>
> On 03/27/2014 11:27 AM, Tom Lane wrote:
> >Andrew Dunstan writes:
> >>I guess we'd better add a make-contrib-check step to the buildfarm. I
> >>was just prepping a release, so I'll delay that while I add this.
> >BTW, won't that ob
Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> >> I meant to say what's actually in git HEAD at the moment is broken.
>
> > Uh, I thought that might be what you were saying, but I am not seeing
> > any failures here.
>
> The buildfar
On 03/27/2014 11:27 AM, Tom Lane wrote:
Andrew Dunstan writes:
I guess we'd better add a make-contrib-check step to the buildfarm. I
was just prepping a release, so I'll delay that while I add this.
BTW, won't that obsolete the need for the separate check-pg_upgrade
step?
Andrew Dunstan writes:
> I guess we'd better add a make-contrib-check step to the buildfarm. I
> was just prepping a release, so I'll delay that while I add this.
BTW, won't that obsolete the need for the separate check-pg_upgrade
step?
regards, tom lane
--
Sent via p
On 03/27/2014 10:31 AM, Andrew Dunstan wrote:
On 03/27/2014 10:13 AM, Tom Lane wrote:
Bruce Momjian writes:
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
I meant to say what's actually in git HEAD at the moment is broken.
Uh, I thought that might be what you were saying,
On Thu, Mar 27, 2014 at 10:30:59AM -0400, Bruce Momjian wrote:
> On Thu, Mar 27, 2014 at 10:13:36AM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> > >> I meant to say what's actually in git HEAD at the moment is broken.
> >
On Thu, Mar 27, 2014 at 10:13:36AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> >> I meant to say what's actually in git HEAD at the moment is broken.
>
> > Uh, I thought that might be what you were saying, but I am not seein
On 03/27/2014 10:13 AM, Tom Lane wrote:
Bruce Momjian writes:
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
I meant to say what's actually in git HEAD at the moment is broken.
Uh, I thought that might be what you were saying, but I am not seeing
any failures here.
The buil
Bruce Momjian writes:
> On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
>> I meant to say what's actually in git HEAD at the moment is broken.
> Uh, I thought that might be what you were saying, but I am not seeing
> any failures here.
The buildfarm isn't complaining, either. Is
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> Re: Bruce Momjian 2014-03-27 <20140327131048.ga11...@momjian.us>
> > On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> > > Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> > > > The attached patch matc
Re: Bruce Momjian 2014-03-27 <20140327131048.ga11...@momjian.us>
> On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> > Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> > > The attached patch matches your suggestion. It is basically back to
> > > what the code origin
On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> > The attached patch matches your suggestion. It is basically back to
> > what the code originally had, except it skips system tables, and shows
> > "???" for invalid
Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> The attached patch matches your suggestion. It is basically back to
> what the code originally had, except it skips system tables, and shows
> "???" for invalid values.
Fwiw, "make check-world" is currently broken:
build/c
On Wed, Mar 26, 2014 at 12:53:32PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Wed, Mar 26, 2014 at 12:20:07PM -0300, Alvaro Herrera wrote:
>
> > > Not opposed to this, but it seems a bit strange; REPLICA IDENTITY is a
> > > property of the table, not of any individual index. I thi
Bruce Momjian wrote:
> On Wed, Mar 26, 2014 at 12:20:07PM -0300, Alvaro Herrera wrote:
> > Not opposed to this, but it seems a bit strange; REPLICA IDENTITY is a
> > property of the table, not of any individual index. I think we should
> > lose the token in the "Indexes" section.
>
> That is an
On Wed, Mar 26, 2014 at 12:20:07PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, Mar 24, 2014 at 09:07:07PM -0400, Bruce Momjian wrote:
> > > > In the "INDEX" case, should the output mention specifically which index
> > > > is being considered?
> > >
> > > Ah, good idea. Updated
Bruce Momjian wrote:
> On Mon, Mar 24, 2014 at 09:07:07PM -0400, Bruce Momjian wrote:
> > > In the "INDEX" case, should the output mention specifically which index
> > > is being considered?
> >
> > Ah, good idea. Updated patch attached. The output is now:
> >
> > test=> \d+ test
> >
On Mon, Mar 24, 2014 at 09:07:07PM -0400, Bruce Momjian wrote:
> > In the "INDEX" case, should the output mention specifically which index
> > is being considered?
>
> Ah, good idea. Updated patch attached. The output is now:
>
> test=> \d+ test
>Table "pub
On Mon, Mar 24, 2014 at 01:35:20PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, Mar 24, 2014 at 05:06:25PM +0100, Andres Freund wrote:
> > > On 2014-03-22 23:47:57 -0400, Bruce Momjian wrote:
> > > > test=> \d+ test
> > > > Table "public.t
Bruce Momjian wrote:
> On Mon, Mar 24, 2014 at 05:06:25PM +0100, Andres Freund wrote:
> > On 2014-03-22 23:47:57 -0400, Bruce Momjian wrote:
> > > test=> \d+ test
> > >Table "public.test"
> > >Column | Type | Modifiers | Storage | Stats target | Description
> >
On Mon, Mar 24, 2014 at 05:06:25PM +0100, Andres Freund wrote:
> On 2014-03-22 23:47:57 -0400, Bruce Momjian wrote:
> > test=> \d+ test
> > Table "public.test"
> > Column | Type | Modifiers | Storage | Stats target | Description
> > +-+--
On 2014-03-22 23:47:57 -0400, Bruce Momjian wrote:
> test=> \d+ test
>Table "public.test"
>Column | Type | Modifiers | Storage | Stats target | Description
> +-+---+-+--+-
>x
On Sun, Mar 23, 2014 at 11:49:37AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Is this the patch you had in mind? I kept the pg_catalog filter. Do we
> > want to always show the replica identity line for \d+?
>
> Doesn't seem like a great idea to remove the filter tests for replident
> v
Bruce Momjian writes:
> Is this the patch you had in mind? I kept the pg_catalog filter. Do we
> want to always show the replica identity line for \d+?
Doesn't seem like a great idea to remove the filter tests for replident
values and then not fix the display code to cope with those values.
I
On Tue, Dec 17, 2013 at 09:37:09AM -0500, Robert Haas wrote:
> > Patch attached.
>
> I vote for showing it only with +, but regardless of whether the value
> matches the expected default. I'd keep the relkind test, though,
> because I think I noticed that it currently shows up for indexes,
> whic
On Mon, Dec 16, 2013 at 7:25 AM, Andres Freund wrote:
> On 2013-12-14 17:43:36 +0100, Andres Freund wrote:
>> On 2013-12-14 11:27:53 -0500, Tom Lane wrote:
>> > In HEAD:
>> >
>> > regression=# \d pg_depend
>> >Table "pg_catalog.pg_depend"
>> >Column| Type | Modifiers
>> > --
On 2013-12-14 17:43:36 +0100, Andres Freund wrote:
> On 2013-12-14 11:27:53 -0500, Tom Lane wrote:
> > In HEAD:
> >
> > regression=# \d pg_depend
> >Table "pg_catalog.pg_depend"
> >Column| Type | Modifiers
> > -+-+---
> > classid | oid | not nul
On 2013-12-14 11:27:53 -0500, Tom Lane wrote:
> In HEAD:
>
> regression=# \d pg_depend
>Table "pg_catalog.pg_depend"
>Column| Type | Modifiers
> -+-+---
> classid | oid | not null
> objid | oid | not null
> objsubid| integer | no
In HEAD:
regression=# \d pg_depend
Table "pg_catalog.pg_depend"
Column| Type | Modifiers
-+-+---
classid | oid | not null
objid | oid | not null
objsubid| integer | not null
refclassid | oid | not null
refobjid| oid
44 matches
Mail list logo
