Thread: Useless "Replica Identity: NOTHING" noise from psql \d

Useless "Replica Identity: NOTHING" noise from psql \d

From
Tom Lane
Date:
In HEAD:

regression=# \d pg_depend  Table "pg_catalog.pg_depend"  Column    |  Type   | Modifiers 
-------------+---------+-----------classid     | oid     | not nullobjid       | oid     | not nullobjsubid    |
integer| not nullrefclassid  | oid     | not nullrefobjid    | oid     | not nullrefobjsubid | integer | not
nulldeptype    | "char"  | not null
 
Indexes:   "pg_depend_depender_index" btree (classid, objid, objsubid)   "pg_depend_reference_index" btree (refclassid,
refobjid,refobjsubid)
 
Replica Identity: NOTHING

Where did that last line come from, and who thinks it's so important
that it should appear by default?  It seems absolutely content-free
even if I were using whatever feature it refers to, since it is
(I presume) the default state.

Please either suppress this entirely or at least condition it on \d+.
        regards, tom lane



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andres Freund
Date:
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 | not null
>  refclassid  | oid     | not null
>  refobjid    | oid     | not null
>  refobjsubid | integer | not null
>  deptype     | "char"  | not null
> Indexes:
>     "pg_depend_depender_index" btree (classid, objid, objsubid)
>     "pg_depend_reference_index" btree (refclassid, refobjid, refobjsubid)
> Replica Identity: NOTHING
> 
> Where did that last line come from, and who thinks it's so important
> that it should appear by default?  It seems absolutely content-free
> even if I were using whatever feature it refers to, since it is
> (I presume) the default state.

Hm. Yes, that's slightly inellegant. It's shown because it's not
actually the normal default normal tables. Just for system tables. Maybe
we should just set it to default (in pg_class) for system tables as
well, and just change it in the relcache.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andres Freund
Date:
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 null
> >  objid       | oid     | not null
> >  objsubid    | integer | not null
> >  refclassid  | oid     | not null
> >  refobjid    | oid     | not null
> >  refobjsubid | integer | not null
> >  deptype     | "char"  | not null
> > Indexes:
> >     "pg_depend_depender_index" btree (classid, objid, objsubid)
> >     "pg_depend_reference_index" btree (refclassid, refobjid, refobjsubid)
> > Replica Identity: NOTHING
> >
> > Where did that last line come from, and who thinks it's so important
> > that it should appear by default?  It seems absolutely content-free
> > even if I were using whatever feature it refers to, since it is
> > (I presume) the default state.
>
> Hm. Yes, that's slightly inellegant. It's shown because it's not
> actually the normal default normal tables. Just for system tables. Maybe
> we should just set it to default (in pg_class) for system tables as
> well, and just change it in the relcache.

Hm. I don't like that choice much after thinking for a bit. Seems to
make querying the catalog unneccessarily complex.
How about making it conditional on the table's namespace instead? That
will do the wrong thing if somebody moves a table to pg_catalog and
configures a replica identity, but I think we can live with that, given
how many other things work strangely around that.

Patch attached.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Robert Haas
Date:
On Mon, Dec 16, 2013 at 7:25 AM, Andres Freund <andres@2ndquadrant.com> 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
>> > -------------+---------+-----------
>> >  classid     | oid     | not null
>> >  objid       | oid     | not null
>> >  objsubid    | integer | not null
>> >  refclassid  | oid     | not null
>> >  refobjid    | oid     | not null
>> >  refobjsubid | integer | not null
>> >  deptype     | "char"  | not null
>> > Indexes:
>> >     "pg_depend_depender_index" btree (classid, objid, objsubid)
>> >     "pg_depend_reference_index" btree (refclassid, refobjid, refobjsubid)
>> > Replica Identity: NOTHING
>> >
>> > Where did that last line come from, and who thinks it's so important
>> > that it should appear by default?  It seems absolutely content-free
>> > even if I were using whatever feature it refers to, since it is
>> > (I presume) the default state.
>>
>> Hm. Yes, that's slightly inellegant. It's shown because it's not
>> actually the normal default normal tables. Just for system tables. Maybe
>> we should just set it to default (in pg_class) for system tables as
>> well, and just change it in the relcache.
>
> Hm. I don't like that choice much after thinking for a bit. Seems to
> make querying the catalog unneccessarily complex.
> How about making it conditional on the table's namespace instead? That
> will do the wrong thing if somebody moves a table to pg_catalog and
> configures a replica identity, but I think we can live with that, given
> how many other things work strangely around that.
>
> 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,
which is dumb.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
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,
> which is dumb.

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+?

    test=> \d+ test
                             Table "public.test"
     Column |  Type   | Modifiers | Storage | Stats target | Description
    --------+---------+-----------+---------+--------------+-------------
     x      | integer |           | plain   |              |
    Replica Identity: full
    Has OIDs: no

I used lower-case for the value, rather than all-caps.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> 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 think this display code is well south of minimal acceptability anyhow:
if the column contains anything other than what it expects, it will print
a lie, meaning it's entirely not future-proof.  I'd suggest a switch()
that prints "???" in the default: case.
        regards, tom lane



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
On Sun, Mar 23, 2014 at 11:49:37AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 think this display code is well south of minimal acceptability anyhow:
> if the column contains anything other than what it expects, it will print
> a lie, meaning it's entirely not future-proof.  I'd suggest a switch()
> that prints "???" in the default: case.

Oh, good points.  I have updated the attached patch.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andres Freund
Date:
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      | integer |           | plain   |              |
>     Replica Identity: full
>     Has OIDs: no
> 
> I used lower-case for the value, rather than all-caps.

Why? CLUSTER, PRIMARY KEY, etc. are displayed all caps, and replica
identity is similarly set via ALTER TABLE ... REPLICA IDENITY?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
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
> >     --------+---------+-----------+---------+--------------+-------------
> >      x      | integer |           | plain   |              |
> >     Replica Identity: full
> >     Has OIDs: no
> >
> > I used lower-case for the value, rather than all-caps.
>
> Why? CLUSTER, PRIMARY KEY, etc. are displayed all caps, and replica
> identity is similarly set via ALTER TABLE ... REPLICA IDENITY?

Oh, good points;  I had not considered PRIMARY KEY.  Updated patch
attached.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Alvaro Herrera
Date:
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
> > >     --------+---------+-----------+---------+--------------+-------------
> > >      x      | integer |           | plain   |              |
> > >     Replica Identity: full
> > >     Has OIDs: no
> > > 
> > > I used lower-case for the value, rather than all-caps.
> > 
> > Why? CLUSTER, PRIMARY KEY, etc. are displayed all caps, and replica
> > identity is similarly set via ALTER TABLE ... REPLICA IDENITY?
> 
> Oh, good points;  I had not considered PRIMARY KEY.  Updated patch
> attached.

In the "INDEX" case, should the output mention specifically which index
is being considered?



-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
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.test"
> > > >      Column |  Type   | Modifiers | Storage | Stats target | Description
> > > >     --------+---------+-----------+---------+--------------+-------------
> > > >      x      | integer |           | plain   |              |
> > > >     Replica Identity: full
> > > >     Has OIDs: no
> > > >
> > > > I used lower-case for the value, rather than all-caps.
> > >
> > > Why? CLUSTER, PRIMARY KEY, etc. are displayed all caps, and replica
> > > identity is similarly set via ALTER TABLE ... REPLICA IDENITY?
> >
> > Oh, good points;  I had not considered PRIMARY KEY.  Updated patch
> > attached.
>
> 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 "public.test"
     Column |  Type   | Modifiers | Storage | Stats target | Description
    --------+---------+-----------+---------+--------------+-------------
     x      | integer | not null  | plain   |              |
    Indexes:
        "test_pkey" PRIMARY KEY, btree (x) REPLICA IDENTITY
        "i_test2" btree (x)
-->    Replica Identity: USING INDEX "test_pkey"
    Has OIDs: no

However, now that I look at it, it seems redundant as REPLICA IDENTITY
is already marked on the actual index.  Ideas?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
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 "public.test"
>      Column |  Type   | Modifiers | Storage | Stats target | Description
>     --------+---------+-----------+---------+--------------+-------------
>      x      | integer | not null  | plain   |              |
>     Indexes:
>         "test_pkey" PRIMARY KEY, btree (x) REPLICA IDENTITY
>         "i_test2" btree (x)
> -->    Replica Identity: USING INDEX "test_pkey"
>     Has OIDs: no
>
> However, now that I look at it, it seems redundant as REPLICA IDENTITY
> is already marked on the actual index.  Ideas?

Hearing nothing, I have gone back to the previous patch that just marks
replica identity as USING INDEX;  applied patch attached.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Alvaro Herrera
Date:
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
> >                              Table "public.test"
> >      Column |  Type   | Modifiers | Storage | Stats target | Description
> >     --------+---------+-----------+---------+--------------+-------------
> >      x      | integer | not null  | plain   |              |
> >     Indexes:
> >         "test_pkey" PRIMARY KEY, btree (x) REPLICA IDENTITY
> >         "i_test2" btree (x)
> > -->    Replica Identity: USING INDEX "test_pkey"
> >     Has OIDs: no
> > 
> > However, now that I look at it, it seems redundant as REPLICA IDENTITY
> > is already marked on the actual index.  Ideas?
> 
> Hearing nothing, I have gone back to the previous patch that just marks
> replica identity as USING INDEX;  applied patch attached.

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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
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 patch attached.  The output is now:
> > > 
> > >     test=> \d+ test
> > >                              Table "public.test"
> > >      Column |  Type   | Modifiers | Storage | Stats target | Description
> > >     --------+---------+-----------+---------+--------------+-------------
> > >      x      | integer | not null  | plain   |              |
> > >     Indexes:
> > >         "test_pkey" PRIMARY KEY, btree (x) REPLICA IDENTITY
> > >         "i_test2" btree (x)
> > > -->    Replica Identity: USING INDEX "test_pkey"
> > >     Has OIDs: no
> > > 
> > > However, now that I look at it, it seems redundant as REPLICA IDENTITY
> > > is already marked on the actual index.  Ideas?
> > 
> > Hearing nothing, I have gone back to the previous patch that just marks
> > replica identity as USING INDEX;  applied patch attached.
> 
> 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 interesting idea.  It would mean that \d table would not show
anything about replica identity, because right now it does:
test=> \d test     Table "public.test" Column |  Type   | Modifiers--------+---------+----------- x      | integer |
notnullIndexes:    "test_pkey" PRIMARY KEY, btree (x) REPLICA IDENTITY
 

That seems logical.  So under the new plan, \d would show:
test=> \d test     Table "public.test" Column |  Type   | Modifiers--------+---------+----------- x      | integer |
notnullIndexes:    "test_pkey" PRIMARY KEY, btree (x)
 

and \d+ would show:
    test=> \d+ test                             Table "public.test"     Column |  Type   | Modifiers | Storage | Stats
target| Description    --------+---------+-----------+---------+--------------+-------------     x      | integer | not
null | plain   |              |    Indexes:        "test_pkey" PRIMARY KEY, btree (x)Replica Identity: USING INDEX
"test_pkey"   Has OIDs: no
 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Alvaro Herrera
Date:
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 interesting idea.  It would mean that \d table would not show
> anything about replica identity, because right now it does:
> 
>     test=> \d test
>          Table "public.test"
>      Column |  Type   | Modifiers
>     --------+---------+-----------
>      x      | integer | not null
>     Indexes:
>         "test_pkey" PRIMARY KEY, btree (x) REPLICA IDENTITY
> 
> That seems logical.

Hmm.  It seems to me that to make this more compact we could keep the
current token in the index line if it's INDEX, and not display the
Replica Identity: line at all; and if it's something other than index
and different from the default value, then print "Replica Identity" in
both \d and \d+.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
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 think we should
> > > lose the token in the "Indexes" section.
> >
> > That is an interesting idea.  It would mean that \d table would not show
> > anything about replica identity, because right now it does:
> >
> >     test=> \d test
> >          Table "public.test"
> >      Column |  Type   | Modifiers
> >     --------+---------+-----------
> >      x      | integer | not null
> >     Indexes:
> >         "test_pkey" PRIMARY KEY, btree (x) REPLICA IDENTITY
> >
> > That seems logical.
>
> Hmm.  It seems to me that to make this more compact we could keep the
> current token in the index line if it's INDEX, and not display the
> Replica Identity: line at all; and if it's something other than index
> and different from the default value, then print "Replica Identity" in
> both \d and \d+.

OK. Tom's original complaint was about showing the default state in \d:

    http://www.postgresql.org/message-id/12303.1387038473@sss.pgh.pa.us

though that example was for an odd case where a system table didn't use
the default value.

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.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Christoph Berg
Date:
Re: Bruce Momjian 2014-03-26 <20140326161056.GA468@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/contrib/test_decoding/regression.diffs ********
*** /tmp/buildd/postgresql-9.4-9.4~20140327.0501/build/../contrib/test_decoding/expected/ddl.out    Thu Mar 27 02:43:36
2014
--- /tmp/buildd/postgresql-9.4-9.4~20140327.0501/build/contrib/test_decoding/results/ddl.out    Thu Mar 27 05:14:02
2014
***************
*** 345,350 ****
--- 345,351 ----  options  | text[]  |                                                                   | extended |
          |  Indexes:     "replication_metadata_pkey" PRIMARY KEY, btree (id)
 
+ Replica Identity: DEFAULT Has OIDs: no Options: user_catalog_table=true 
***************
*** 360,365 ****
--- 361,367 ----  options  | text[]  |                                                                   | extended |
          |  Indexes:     "replication_metadata_pkey" PRIMARY KEY, btree (id)
 
+ Replica Identity: DEFAULT Has OIDs: no  INSERT INTO replication_metadata(relation, options)
***************
*** 374,379 ****
--- 376,382 ----  options  | text[]  |                                                                   | extended |
          |  Indexes:     "replication_metadata_pkey" PRIMARY KEY, btree (id)
 
+ Replica Identity: DEFAULT Has OIDs: no Options: user_catalog_table=true 
***************
*** 394,399 ****
--- 397,403 ----  rewritemeornot | integer |                                                                   | plain
 |              |  Indexes:     "replication_metadata_pkey" PRIMARY KEY, btree (id)
 
+ Replica Identity: DEFAULT Has OIDs: no Options: user_catalog_table=false

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> Re: Bruce Momjian 2014-03-26 <20140326161056.GA468@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:

Yes, the patch was partial to just show the code changes, to get
approval.  Attached is the full patch.

I did some research of the regression database to see what was being
set:

    SELECT relreplident, relkind, nspname, count(*)
    FROM pg_class, pg_namespace
    WHERE     relkind IN ('m', 'r') AND
        relnamespace = pg_namespace.oid AND
        nspname != 'pg_catalog'
    GROUP BY relreplident, nspname, relkind
    ORDER BY 1, 2, 3;

     relreplident | relkind |      nspname       | count
    --------------+---------+--------------------+-------
     d            | m       | mvschema           |     1
     d            | m       | public             |     5
     d            | r       | information_schema |     7
     d            | r       | public             |   205
     d            | r       | testxmlschema      |     3

It seems everything is default, which would not be displayed.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Christoph Berg
Date:
Re: Bruce Momjian 2014-03-27 <20140327131048.GA11694@momjian.us>
> On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> > Re: Bruce Momjian 2014-03-26 <20140326161056.GA468@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:
> 
> Yes, the patch was partial to just show the code changes, to get
> approval.  Attached is the full patch.

I meant to say what's actually in git HEAD at the moment is broken.
The regression.diffs are without an extra patch. This prevents
building 9.4devel packages for apt.postgresql.org now.

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> Re: Bruce Momjian 2014-03-27 <20140327131048.GA11694@momjian.us>
> > On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> > > Re: Bruce Momjian 2014-03-26 <20140326161056.GA468@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:
> > 
> > Yes, the patch was partial to just show the code changes, to get
> > approval.  Attached is the full patch.
> 
> I meant to say what's actually in git HEAD at the moment is broken.
> The regression.diffs are without an extra patch. This prevents
> building 9.4devel packages for apt.postgresql.org now.

Uh, I thought that might be what you were saying, but I am not seeing
any failures here.  I don't see any platform-specific regression files
in the files I modified.  Can you show me the failures?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Tom Lane
Date:
Bruce Momjian <bruce@momjian.us> 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 there some part of "make
check-world" that isn't exercised by the buildfarm?
        regards, tom lane



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
On Thu, Mar 27, 2014 at 10:13:36AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 there some part of "make
> check-world" that isn't exercised by the buildfarm?

I see it now in contrib/test_decoding;  fixing.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andrew Dunstan
Date:
On 03/27/2014 10:13 AM, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 there some part of "make
> check-world" that isn't exercised by the buildfarm?
>
>             

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.)

cheers

andrew




Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
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 <bruce@momjian.us> 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 there some part of "make
> > check-world" that isn't exercised by the buildfarm?
>
> I see it now in contrib/test_decoding;  fixing.

OK, fixed.  I have also updated my new patch to reflect those changes,
attached.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andrew Dunstan
Date:
On 03/27/2014 10:31 AM, Andrew Dunstan wrote:
>
> On 03/27/2014 10:13 AM, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> 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 there some part of "make
>> check-world" that isn't exercised by the buildfarm?
>>
>>
>
> 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 mentioned it 
to me :-(

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.

cheers

andrew




Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> 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



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andrew Dunstan
Date:
On 03/27/2014 11:27 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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?
>
>             


Yes, possibly.

It helps if people bring to my attention changes in the build and test 
infrastructure, sometimes I miss developments, as I did here.

cheers

andrew




Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Christoph Berg
Date:
Re: Andrew Dunstan 2014-03-27 <53344465.6010401@dunslane.net>
> 
> On 03/27/2014 11:27 AM, Tom Lane wrote:
> >Andrew Dunstan <andrew@dunslane.net> 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?
> 
> Yes, possibly.
> 
> It helps if people bring to my attention changes in the build and test
> infrastructure, sometimes I miss developments, as I did here.

Why not "make check-world"? That should include everything, and
doesn't need updating the scripts when something new gets included in
PostgreSQL itself. The pg_upgrade test is included.

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Alvaro Herrera
Date:
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 there some part of "make
> check-world" that isn't exercised by the buildfarm?

I'd bet it's "make check" in contrib.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andrew Dunstan
Date:
On 03/27/2014 11:34 AM, Christoph Berg wrote:
> Re: Andrew Dunstan 2014-03-27 <53344465.6010401@dunslane.net>
>> On 03/27/2014 11:27 AM, Tom Lane wrote:
>>> Andrew Dunstan <andrew@dunslane.net> 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?
>> Yes, possibly.
>>
>> It helps if people bring to my attention changes in the build and test
>> infrastructure, sometimes I miss developments, as I did here.
> Why not "make check-world"? That should include everything, and
> doesn't need updating the scripts when something new gets included in
> PostgreSQL itself. The pg_upgrade test is included.
>

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 "make -C 
contrib check" we'll have more information. So I'm not terribly excited 
about combining steps too much.

cheers

andrew



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Alvaro Herrera
Date:
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 "make -C contrib check" we'll have more information. So I'm
> not terribly excited about combining steps too much.

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 to have a
target that runs "make installcheck" for most modules and "make check"
only for those that need the separate installation?  Maybe we can have a
file listing modules that don't support installcheck, for instance, and
then use $(filter) and $(filter-out) to produce appropriate "$(MAKE) -C"
loops.

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 allows both MSVC and
make-based systems to run those tests?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andres Freund
Date:
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 mentioned it to
> me :-(

I tried to ping you about it :)

The background is that we can't run against a installed installation
because we require nonstandard PGC_POSTMASTER settings (wal_level,
max_replication_slots). I hope there will be more tests that depend on
wal_level sometime soon...

> 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.

Yes, I think that's a good idea.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Tom Lane
Date:
Alvaro Herrera <alvherre@2ndquadrant.com> 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 to have a
> target that runs "make installcheck" for most modules and "make check"
> only for those that need the separate installation?  Maybe we can have a
> file listing modules that don't support installcheck, for instance, and
> then use $(filter) and $(filter-out) to produce appropriate "$(MAKE) -C"
> loops.

This seems like a good idea to me; the slower animals will be putting lots
of cycles into pretty-much-useless "make check" builds if we don't.

Rather than a separate file, though, I think a distinct target in
contrib/Makefile would be the best mechanism for keeping the list of
modules that lack installcheck support.  Perhaps "make special-check"
or some name along that line?

> 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 allows both MSVC and
> make-based systems to run those tests?

Agreed, but I'm not volunteering to fix that one ;-)
        regards, tom lane



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Noah Misch
Date:
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 stuff in a way that allows both MSVC and
> make-based systems to run those tests?

+1


Incidentally, I've seen the following row-order difference for test_decoding.
(I assumed the buildfarm would notice that quickly enough, but this thread has
corrected that assumption.)  Barring objections, I'll make it "ORDER BY 1,2".

--- /home/nmisch/src/pg/postgresql/contrib/test_decoding/expected/ddl.out    2014-03-23 07:32:25.718189175 +0000
+++ /home/nmisch/src/pg/postgresql/contrib/test_decoding/results/ddl.out    2014-03-27 17:40:33.079815557 +0000
@@ -199,8 +199,8 @@ORDER BY 1; count |                       min                       |
 max
-------+-------------------------------------------------+------------------------------------------------------------------------
-     1 | COMMIT                                          | COMMIT     1 | BEGIN
  | BEGIN
 
+     1 | COMMIT                                          | COMMIT 20467 | table public.tr_etoomuch: DELETE:
id[integer]:1| table public.tr_etoomuch: UPDATE: id[integer]:9999 data[integer]:-9999(3 rows)
 

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andrew Dunstan
Date:
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 allows both MSVC and
> make-based systems to run those tests?
>

Well, to start with people need to get out of the habit of writing tests 
in shell script. I know it's hard, we've only had the Windows port for 9 
years or so, so it takes a bit of getting used to ...

cheers

andrew



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> 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 redoing that stuff in a way that allows both MSVC and
>> make-based systems to run those tests?

> Well, to start with people need to get out of the habit of writing tests 
> in shell script.

What alternative do you propose?  We have a policy of not requiring Perl
to build/test, so don't suggest that.

I'm inclined to think the problem with test.sh is not so much the language
that it's in, as that it's single-purpose.  Maybe it has to be given the
nature of the pg_upgrade tests, but we should look for some generality.
I'd be happy if we had shell-based infrastructure on non-Windows and a
separate Perl equivalent for Windows, as long as we didn't have to start
from scratch for each special-configuration test scenario.
        regards, tom lane



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andrew Dunstan
Date:
On 03/27/2014 04:31 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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 redoing that stuff in a way that allows both MSVC and
>>> make-based systems to run those tests?
>> Well, to start with people need to get out of the habit of writing tests
>> in shell script.
> What alternative do you propose?  We have a policy of not requiring Perl
> to build/test, so don't suggest that.
>
> I'm inclined to think the problem with test.sh is not so much the language
> that it's in, as that it's single-purpose.  Maybe it has to be given the
> nature of the pg_upgrade tests, but we should look for some generality.
> I'd be happy if we had shell-based infrastructure on non-Windows and a
> separate Perl equivalent for Windows, as long as we didn't have to start
> from scratch for each special-configuration test scenario.
>
>             

If you can create it so it's somehow config driven, we can surely 
replicate the engine in Perl. But I'm not going to hold my breath waiting.

cheers

andrew



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andres Freund
Date:
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 not looking so good.
> > Should we consider redoing that stuff in a way that allows both MSVC and
> > make-based systems to run those tests?
>
> +1

I'd like that as well, but I don't really see how.

> Incidentally, I've seen the following row-order difference for test_decoding.
> (I assumed the buildfarm would notice that quickly enough, but this thread has
> corrected that assumption.)  Barring objections, I'll make it "ORDER BY 1,2".
> 
> --- /home/nmisch/src/pg/postgresql/contrib/test_decoding/expected/ddl.out    2014-03-23 07:32:25.718189175 +0000
> +++ /home/nmisch/src/pg/postgresql/contrib/test_decoding/results/ddl.out    2014-03-27 17:40:33.079815557 +0000
> @@ -199,8 +199,8 @@
>  ORDER BY 1;
>   count |                       min                       |                                  max
            
 
>
-------+-------------------------------------------------+------------------------------------------------------------------------
> -     1 | COMMIT                                          | COMMIT
>       1 | BEGIN                                           | BEGIN
> +     1 | COMMIT                                          | COMMIT
>   20467 | table public.tr_etoomuch: DELETE: id[integer]:1 | table public.tr_etoomuch: UPDATE: id[integer]:9999
data[integer]:-9999
>  (3 rows)

That sounds like a good plan. Thanks!

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andres Freund
Date:
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 way that allows both MSVC and
> make-based systems to run those tests?

I really hope test_decoding needs less scaffolding than this? There's
much less going on in its test, right?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andrew Dunstan
Date:
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.
>> Should we consider redoing that stuff in a way that allows both MSVC and
>> make-based systems to run those tests?
> I really hope test_decoding needs less scaffolding than this? There's
> much less going on in its test, right?


Yeah.

What I have done is create a quite small buildfarm module to run these 
tests. See 
<https://github.com/PGBuildFarm/client-code/commit/69c92f53bbe3748c13fa29aee0c39c8dd7210f1e>

It can be added to an existing buildfarm client installation and enabled 
by adding TestDecoding to the list of modules in the buildfarm config 
file. It will be included in the next release and enabled in that 
release's sample config file.

See an example run at 
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2014-03-27%2023%3A40%3A15&stg=test-decoding-check>.

Larger questions can wait, but this makes a start on the immediate issue.

cheers

andrew



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Bruce Momjian
Date:
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 <bruce@momjian.us> 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 there some part of "make
> > > check-world" that isn't exercised by the buildfarm?
> > 
> > I see it now in contrib/test_decoding;  fixing.
> 
> OK, fixed.  I have also updated my new patch to reflect those changes,
> attached.

Applied.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Andrew Dunstan
Date:
On 03/27/2014 01:09 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> 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 to have a
>> target that runs "make installcheck" for most modules and "make check"
>> only for those that need the separate installation?  Maybe we can have a
>> file listing modules that don't support installcheck, for instance, and
>> then use $(filter) and $(filter-out) to produce appropriate "$(MAKE) -C"
>> loops.
> This seems like a good idea to me; the slower animals will be putting lots
> of cycles into pretty-much-useless "make check" builds if we don't.
>
> Rather than a separate file, though, I think a distinct target in
> contrib/Makefile would be the best mechanism for keeping the list of
> modules that lack installcheck support.  Perhaps "make special-check"
> or some name along that line?
>
>> 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 allows both MSVC and
>> make-based systems to run those tests?
> Agreed, but I'm not volunteering to fix that one ;-)
>
>             



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 MSVC support.

These can go on my long TOO list unless someone else gets there first.

cheers

andrew



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
andres@anarazel.de (Andres Freund)
Date:
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 MSVC support.
> 
> These can go on my long TOO list unless someone else gets there first.

So, I was thinking on how we can improve this situation. There's
basically one bigger remaining problem besides make check vs. make
installcheck:
Currently contrib modules can't easily run isolationtester in a general
fashion. That's why test_decoding's Makefile has to rig that all
itself. How about simply improving the contrib support to recognize
tests in ISOLATION_REGRESS in addition to the current REGRESS? Then we
can "simply" train vcregress.pl to pick them up generally, without
special support for test_decoding.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



Re: Useless "Replica Identity: NOTHING" noise from psql \d

From
Robert Haas
Date:
On Sat, Apr 5, 2014 at 7:12 AM, Andres Freund <andres@anarazel.de> 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 to run
>> test_decoding check. But of course It won't have MSVC support.
>>
>> These can go on my long TOO list unless someone else gets there first.
>
> So, I was thinking on how we can improve this situation. There's
> basically one bigger remaining problem besides make check vs. make
> installcheck:
> Currently contrib modules can't easily run isolationtester in a general
> fashion. That's why test_decoding's Makefile has to rig that all
> itself. How about simply improving the contrib support to recognize
> tests in ISOLATION_REGRESS in addition to the current REGRESS? Then we
> can "simply" train vcregress.pl to pick them up generally, without
> special support for test_decoding.

IMHO, that's a fine idea.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company