Thread: the buildfarm has measles
bowerbird and lorikeet are complaining about the git tree being dirty. prairiedog is not happy about the new plpython error stuff. woodlouse and thrips failed like this (and mastodon in a similar but not identical way): "C:\buildfarm\buildenv\HEAD\pgsql.build\pgsql.sln" (Standardziel) (1) -> "C:\buildfarm\buildenv\HEAD\pgsql.build\ascii_and_mic.vcxproj" (Standardziel) (2) -> "C:\buildfarm\buildenv\HEAD\pgsql.build\postgres.vcxproj" (Standardziel) (3) -> (ClCompile Ziel) -> src/backend/access/brin/brin_pageops.c(824): error C2026: string too big, trailing characters truncated [C:\buildfarm\buildenv\HEAD\pgsql.build\postgres.vcxproj] crake failed 'make check': *** /home/bf/bfr/root/HEAD/pgsql.build/src/test/regress/expected/misc.out Fri Apr 8 19:38:58 2016 --- /home/bf/bfr/root/HEAD/pgsql.build/src/test/regress/results/misc.out Fri Apr 8 19:39:12 2016 *************** *** 607,612 **** --- 607,613 ---- circle_tbl city copy_tbl + ctv_data d d_star date_tbl *************** *** 710,716 **** tvvmv varchar_tbl xacttest ! (132 rows) SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))); name --- 711,717 ---- tvvmv varchar_tbl xacttest ! (133 rows) SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))); name -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas wrote:
> woodlouse and thrips failed like this (and mastodon in a similar but
> not identical way):
>
> "C:\buildfarm\buildenv\HEAD\pgsql.build\pgsql.sln" (Standardziel) (1) ->
> "C:\buildfarm\buildenv\HEAD\pgsql.build\ascii_and_mic.vcxproj"
> (Standardziel) (2) ->
> "C:\buildfarm\buildenv\HEAD\pgsql.build\postgres.vcxproj" (Standardziel) (3) ->
> (ClCompile Ziel) ->
> src/backend/access/brin/brin_pageops.c(824): error C2026: string too
> big, trailing characters truncated
> [C:\buildfarm\buildenv\HEAD\pgsql.build\postgres.vcxproj]
This complaint refers to this line:
Assert(BRIN_IS_REGULAR_PAGE(BufferGetPage(oldbuf, NULL, NULL, BGP_NO_SNAPSHOT_TEST)));
which the compiler complains that gets too long. This is related:
https://www.postgresql.org/message-id/4407.1435763473%40sss.pgh.pa.us
(There's a patch there which was never pushed AFAICS).
I suggest that we fix this by making BufferGetPage an inline function
rather than a macro.
> crake failed 'make check':
>
> *** /home/bf/bfr/root/HEAD/pgsql.build/src/test/regress/expected/misc.out
> Fri Apr 8 19:38:58 2016
> --- /home/bf/bfr/root/HEAD/pgsql.build/src/test/regress/results/misc.out
> Fri Apr 8 19:39:12 2016
> ***************
> *** 607,612 ****
> --- 607,613 ----
> circle_tbl
> city
> copy_tbl
> + ctv_data
> d
> d_star
> date_tbl
Ahh, my bug -- this is because test psql, in the same parallel group as
misc, creates this table. I hesitate to move the whole test to another
group; perhaps it's better to split the crosstabview out to its own
file, as Daniel had submitted it.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 04/08/2016 07:57 PM, Robert Haas wrote: > bowerbird and lorikeet are complaining about the git tree being dirty. bowerbird is fixed and rebuilding. cheers andrew
Alvaro Herrera wrote: > Robert Haas wrote: > > > crake failed 'make check': > > > > *** /home/bf/bfr/root/HEAD/pgsql.build/src/test/regress/expected/misc.out > > Fri Apr 8 19:38:58 2016 > > --- /home/bf/bfr/root/HEAD/pgsql.build/src/test/regress/results/misc.out > > Fri Apr 8 19:39:12 2016 > > *************** > > *** 607,612 **** > > --- 607,613 ---- > > circle_tbl > > city > > copy_tbl > > + ctv_data > > d > > d_star > > date_tbl > > Ahh, my bug -- this is because test psql, in the same parallel group as > misc, creates this table. I hesitate to move the whole test to another > group; perhaps it's better to split the crosstabview out to its own > file, as Daniel had submitted it. Pushed. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 04/08/2016 10:38 PM, Andrew Dunstan wrote: > > > On 04/08/2016 07:57 PM, Robert Haas wrote: >> bowerbird and lorikeet are complaining about the git tree being dirty. > > > bowerbird is fixed and rebuilding. > > lorikeet should be fixed, too. But bowerbird failed compiling an Assert from commit 8b65cf4c (Modify BufferGetPage() to prepare for "snapshot too old" feature). The error messsage is: src/backend/access/brin/brin_pageops.c(824): error C2026: string too big, trailing characters truncated Not sure what that's about. cheers andrew
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Robert Haas wrote: >> woodlouse and thrips failed like this (and mastodon in a similar but >> not identical way): >> >> "C:\buildfarm\buildenv\HEAD\pgsql.build\pgsql.sln" (Standardziel) (1) -> >> "C:\buildfarm\buildenv\HEAD\pgsql.build\ascii_and_mic.vcxproj" >> (Standardziel) (2) -> >> "C:\buildfarm\buildenv\HEAD\pgsql.build\postgres.vcxproj" (Standardziel) (3) -> >> (ClCompile Ziel) -> >> src/backend/access/brin/brin_pageops.c(824): error C2026: string too >> big, trailing characters truncated >> [C:\buildfarm\buildenv\HEAD\pgsql.build\postgres.vcxproj] > This complaint refers to this line: > Assert(BRIN_IS_REGULAR_PAGE(BufferGetPage(oldbuf, NULL, NULL, > BGP_NO_SNAPSHOT_TEST))); > which the compiler complains that gets too long. This is related: > https://www.postgresql.org/message-id/4407.1435763473%40sss.pgh.pa.us Yeah, pademelon thinks it's too long as well. > I suggest that we fix this by making BufferGetPage an inline function > rather than a macro. +1 regards, tom lane
Robert Haas <robertmhaas@gmail.com> writes: > prairiedog is not happy about the new plpython error stuff. Yeah, see my complaint here: http://www.postgresql.org/message-id/12559.1460141530@sss.pgh.pa.us I think it's just a matter of avoiding invented-in-this-decade Pythonisms. The feature doesn't seem to be broken in itself on that old Python version, it's just the test that's bad. I think we can await a rewritten test case from Pavel. regards, tom lane
On April 8, 2016 8:05:31 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Alvaro Herrera <alvherre@2ndquadrant.com> writes: >> Robert Haas wrote: >>> woodlouse and thrips failed like this (and mastodon in a similar but >>> not identical way): >>> >>> "C:\buildfarm\buildenv\HEAD\pgsql.build\pgsql.sln" (Standardziel) >(1) -> >>> "C:\buildfarm\buildenv\HEAD\pgsql.build\ascii_and_mic.vcxproj" >>> (Standardziel) (2) -> >>> "C:\buildfarm\buildenv\HEAD\pgsql.build\postgres.vcxproj" >(Standardziel) (3) -> >>> (ClCompile Ziel) -> >>> src/backend/access/brin/brin_pageops.c(824): error C2026: string too >>> big, trailing characters truncated >>> [C:\buildfarm\buildenv\HEAD\pgsql.build\postgres.vcxproj] > >> This complaint refers to this line: > >> Assert(BRIN_IS_REGULAR_PAGE(BufferGetPage(oldbuf, NULL, NULL, >> BGP_NO_SNAPSHOT_TEST))); > >> which the compiler complains that gets too long. This is related: >> https://www.postgresql.org/message-id/4407.1435763473%40sss.pgh.pa.us > >Yeah, pademelon thinks it's too long as well. > >> I suggest that we fix this by making BufferGetPage an inline function >> rather than a macro. > >+1 I'll get back to that patch early needy week. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.