Re: [HACKERS] Missing info for buildfarm reports
Tom Lane said: > I'm finding it a bit annoying that the buildfarm results pages will > only show me what the program thinks I need to know. For example, to > debug the current 7.4-branch dblink failures, it'd be awfully useful to > compare the build logs of those systems to the same machines' logs for > the not-broken 8.0 branch. But unless there's a magic back door > somewhere, I can't see either of those logs. > > I think the ideal layout for the per-test-run pages would be the short > configuration summary plus links to the individual log files --- all of > them, no matter what the script thinks the outcome is. > We're ahead of you (just) :-) . This feature request was filed a few days ago - see http://pgfoundry.org/tracker/index.php?func=detail&aid=1000368&group_id=140&atid=241 It will take a little while though. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
Tom,
I agree with NOT fixing the tsearch2 code for this failure in 7.4. I have left
penguin building 7.4 just to see if the
core code continues to compile. I would be nice if the build farm code would
let me exclude a contrib module if
necessary. What do you think Andrew?
Jim
-- Original Message ---
From: Tom Lane <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Andrew Dunstan <[EMAIL PROTECTED]>, pgsql-hackers@postgresql.org
Sent: Mon, 18 Jul 2005 01:05:09 -0400
Subject: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
> Buildfarm member penguin has never got past this point in half a year of
> trying:
>
> creating template1 database in
> /home/postgres/pgfarmbuild/REL7_4_STABLE/pgsql.7701/src/test/regress/./tmp_check/data/base/1...
> ok
> initializing pg_shadow... TRAP:
> FailedAssertion("!(StrategyEvaluationIsValid(evaluation))", File: "istrat.c",
> Line: 273)
>
> Unfortunately it never will :-(, and I'd recommend removing 7.4 from its
> to-do list.
>
> The problem here appears to be the same unusual struct packing rules
> that make tsearch2 fail on this machine in the 8.0 branch. The old
> "index strategy" code assumes that given this set of struct
> declarations:
>
> typedef uint16 StrategyNumber;
>
> typedef struct StrategyOperatorData
> {
> StrategyNumber strategy;
> bits16flags;/* scan qualification flags, see skey.h */
> } StrategyOperatorData;
>
> typedef struct StrategyTermData
> { /* conjunctive term */
> uint16degree;
> StrategyOperatorData operatorData[1];/* VARIABLE LENGTH ARRAY */
> } StrategyTermData; /* VARIABLE LENGTH STRUCTURE */
>
> the contents of StrategyTermData are equivalent to a uint16 array
> containing {degree, strategy1, flags1, strategy2, flags2, ... }.
> This is true on 99% of machines out there, but the compiler penguin is
> using thinks it should align StrategyOperatorData on a word boundary,
> and so there is padding between the "degree" and the first array
> element.
>
> The compiler is within its rights to do this per the ANSI C spec, but
> considering that we'd never seen this problem in ten years of Postgres
> use and that the struct is gone (for unrelated reasons) in PG 8.0 and
> up, I don't think anyone is likely to feel like messing with the 7.*
> code to fix it.
>
> (This is all extrapolation, mind you, but given what we found out about
> the problem with tsearch2, I feel reasonably confident in the analysis.)
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faq
--- End of Original Message ---
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
Jim,
There seems to be some confusion. The error Tom remarked on 7.4 is an
initdb failure during the core check tests, not a tsearch2 failure,
which is why I think he recommends discontinuing to build that branch on
this machine.
Regarding the tsearch2 failure on the 8.0 branch, I am ambivalent about
your proposed change, to say the least. Tom made a comment some time ago
about not hiding errors/limitations, and I agree with him. This is in a
different class from the geometry tests, where the differences were
largely cosmetic. I don't want people to have to read the fine print to
see what tests were excluded - if we show a machine as green it should
mean that machine passed the whole test suite.
cheers
andrew
Jim Buttafuoco wrote:
Tom,
I agree with NOT fixing the tsearch2 code for this failure in 7.4. I have left
penguin building 7.4 just to see if the
core code continues to compile. I would be nice if the build farm code would
let me exclude a contrib module if
necessary. What do you think Andrew?
Jim
-- Original Message ---
From: Tom Lane <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Andrew Dunstan <[EMAIL PROTECTED]>, pgsql-hackers@postgresql.org
Sent: Mon, 18 Jul 2005 01:05:09 -0400
Subject: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
Buildfarm member penguin has never got past this point in half a year of
trying:
creating template1 database in
/home/postgres/pgfarmbuild/REL7_4_STABLE/pgsql.7701/src/test/regress/./tmp_check/data/base/1... ok
initializing pg_shadow... TRAP: FailedAssertion("!(StrategyEvaluationIsValid(evaluation))", File: "istrat.c",
Line: 273)
Unfortunately it never will :-(, and I'd recommend removing 7.4 from its
to-do list.
The problem here appears to be the same unusual struct packing rules
that make tsearch2 fail on this machine in the 8.0 branch. The old
"index strategy" code assumes that given this set of struct
declarations:
typedef uint16 StrategyNumber;
typedef struct StrategyOperatorData
{
StrategyNumber strategy;
bits16flags;/* scan qualification flags, see skey.h */
} StrategyOperatorData;
typedef struct StrategyTermData
{ /* conjunctive term */
uint16degree;
StrategyOperatorData operatorData[1];/* VARIABLE LENGTH ARRAY */
} StrategyTermData; /* VARIABLE LENGTH STRUCTURE */
the contents of StrategyTermData are equivalent to a uint16 array
containing {degree, strategy1, flags1, strategy2, flags2, ... }.
This is true on 99% of machines out there, but the compiler penguin is
using thinks it should align StrategyOperatorData on a word boundary,
and so there is padding between the "degree" and the first array
element.
The compiler is within its rights to do this per the ANSI C spec, but
considering that we'd never seen this problem in ten years of Postgres
use and that the struct is gone (for unrelated reasons) in PG 8.0 and
up, I don't think anyone is likely to feel like messing with the 7.*
code to fix it.
(This is all extrapolation, mind you, but given what we found out about
the problem with tsearch2, I feel reasonably confident in the analysis.)
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--- End of Original Message ---
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
must be early in the morning. I agree with removing penguin from the 7.4
branch. I have removed it on my end. Please
delete it from the database
-- Original Message ---
From: Andrew Dunstan <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Tom Lane <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
pgsql-hackers@postgresql.org
Sent: Mon, 18 Jul 2005 09:38:56 -0400
Subject: Re: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
> Jim,
>
> There seems to be some confusion. The error Tom remarked on 7.4 is an
> initdb failure during the core check tests, not a tsearch2 failure,
> which is why I think he recommends discontinuing to build that branch on
> this machine.
>
> Regarding the tsearch2 failure on the 8.0 branch, I am ambivalent about
> your proposed change, to say the least. Tom made a comment some time ago
> about not hiding errors/limitations, and I agree with him. This is in a
> different class from the geometry tests, where the differences were
> largely cosmetic. I don't want people to have to read the fine print to
> see what tests were excluded - if we show a machine as green it should
> mean that machine passed the whole test suite.
>
> cheers
>
> andrew
>
> Jim Buttafuoco wrote:
>
> >Tom,
> >
> >I agree with NOT fixing the tsearch2 code for this failure in 7.4. I have
> >left penguin building 7.4 just to see if the
> >core code continues to compile. I would be nice if the build farm code
> >would let me exclude a contrib module if
> >necessary. What do you think Andrew?
> >
> >Jim
> >
> >
> >-- Original Message ---
> >From: Tom Lane <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Cc: Andrew Dunstan <[EMAIL PROTECTED]>, pgsql-hackers@postgresql.org
> >Sent: Mon, 18 Jul 2005 01:05:09 -0400
> >Subject: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
> >
> >
> >
> >>Buildfarm member penguin has never got past this point in half a year of
> >>trying:
> >>
> >>creating template1 database in
> >>/home/postgres/pgfarmbuild/REL7_4_STABLE/pgsql.7701/src/test/regress/./tmp_check/data/base/1...
> >> ok
> >>initializing pg_shadow... TRAP:
> >>FailedAssertion("!(StrategyEvaluationIsValid(evaluation))", File:
> >>"istrat.c",
> >> Line: 273)
> >>
> >>Unfortunately it never will :-(, and I'd recommend removing 7.4 from its
> >>to-do list.
> >>
> >>The problem here appears to be the same unusual struct packing rules
> >>that make tsearch2 fail on this machine in the 8.0 branch. The old
> >>"index strategy" code assumes that given this set of struct
> >>declarations:
> >>
> >>typedef uint16 StrategyNumber;
> >>
> >>typedef struct StrategyOperatorData
> >>{
> >>StrategyNumber strategy;
> >>bits16flags;/* scan qualification flags, see skey.h
> >> */
> >>} StrategyOperatorData;
> >>
> >>typedef struct StrategyTermData
> >>{ /* conjunctive term */
> >>uint16degree;
> >>StrategyOperatorData operatorData[1];/* VARIABLE LENGTH ARRAY */
> >>} StrategyTermData; /* VARIABLE LENGTH STRUCTURE */
> >>
> >>the contents of StrategyTermData are equivalent to a uint16 array
> >>containing {degree, strategy1, flags1, strategy2, flags2, ... }.
> >>This is true on 99% of machines out there, but the compiler penguin is
> >>using thinks it should align StrategyOperatorData on a word boundary,
> >>and so there is padding between the "degree" and the first array
> >>element.
> >>
> >>The compiler is within its rights to do this per the ANSI C spec, but
> >>considering that we'd never seen this problem in ten years of Postgres
> >>use and that the struct is gone (for unrelated reasons) in PG 8.0 and
> >>up, I don't think anyone is likely to feel like messing with the 7.*
> >>code to fix it.
> >>
> >>(This is all extrapolation, mind you, but given what we found out about
> >>the problem with tsearch2, I feel reasonably confident in the analysis.)
> >>
> >>regards, tom lane
> >>
> >>---(end of broadcast)---
> >>TIP 3: Have you checked our extensive FAQ?
> >>
> >> http://www.postgresql.org/docs/faq
> >>
> >>
> >--- End of Original Message ---
> >
> >
> >---(end of broadcast)---
> >TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
> >
> >
>
> ---(end of broadcast)---
> TIP 2: Don't 'kill -9' the postmaster
--- End of Original Message ---
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
Jim Buttafuoco wrote: must be early in the morning. I agree with removing penguin from the 7.4 branch. I have removed it on my end. Please delete it from the database No need. In 27 days it will drop off the dashboard. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Toward pg_upgrade
On Wed, 2005-07-13 at 18:35 -0700, David Fetter wrote: > I'm sure I'm not the first to bring up this way of doing pg_upgrade, > but perhaps I can help seed a fruitful discussion on the matter. > Ideally, these transformations would be both idempotent and > reversible, although I understand that they may, by their nature, be > neither. I'm not sure it is easily possible to do all that you say as a general rule. Each release will be different, so I think we need a person, not a procedure. If we have a procedure, but no person, who will enforce the procedure? There is clearly an opening for an individual to track committed code and to analyse what the upgrade actions would need to be for each. That way, we might be able to implement things in a more upgrade friendly manner (when we have a choice). We specialise in most other areas Changes to data format mostly will need an external program, since no version of the server understands both formats. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] escape string syntax and pg_dumpall
I just ran pg_dumpall from today's CVS against a 14 April server - I got: pg_dumpall: query failed: ERROR: type "e" does not exist pg_dumpall: query was: SELECT spcname, pg_catalog.pg_get_userbyid(spcowner) AS spcowner, spclocation, spcacl FROM pg_catalog.pg_tablespace WHERE spcname NOT LIKE E'pg\_%' That comes from v1.62 of pg_dumpall.c : res = executeQuery(conn, "SELECT spcname, " "pg_catalog.pg_get_userbyid(spcowner) AS spcowner, " "spclocation, spcacl " "FROM pg_catalog.pg_tablespace " "WHERE spcname NOT LIKE E'pg\\_%'"); revision 1.62 date: 2005/06/26 03:03:48; author: momjian; state: Exp; lines: +2 -2 Add E'' syntax so eventually normal strings can treat backslashes literally. Add GUC variables: "escape_string_warning" - warn about backslashes in non-E strings "escape_string_syntax" - supports E'' syntax? "standard_compliant_strings" - treats backslashes literally in '' Update code to use E'' when escapes are used. My version of the server predates those GUC settings - could the code be assuming that my server can cope with something it can't? (Normally I would just upgrade everything - and I bet it will work - but, I think we still recommend that people use new pg_dumpall to dump their old server when upgrading..) Cheers, Patrick ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] escape string syntax and pg_dumpall
On 2005-07-18, Tom Lane <[EMAIL PROTECTED]> wrote: >> That comes from v1.62 of pg_dumpall.c : > >> res = executeQuery(conn, "SELECT spcname, " >> "pg_catalog.pg_get_userbyid(spcowner) AS spcowner, " >>"spclocation, spcacl " >>"FROM pg_catalog.pg_tablespace " >>"WHERE spcname NOT LIKE E'pg\\_%'"); > > This query needs to be version-dependent, Bruce ... It's not even correct as it stands - if you want to match a literal _ using LIKE then you would need E'pg_%' there. Would NOT LIKE 'pg!_%' ESCAPE '!' be better? -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] escape string syntax and pg_dumpall
Patrick Welche <[EMAIL PROTECTED]> writes: > I just ran pg_dumpall from today's CVS against a 14 April server - I got: > pg_dumpall: query failed: ERROR: type "e" does not exist > pg_dumpall: query was: SELECT spcname, pg_catalog.pg_get_userbyid(spcowner) > AS spcowner, spclocation, spcacl FROM pg_catalog.pg_tablespace WHERE spcname > NOT LIKE E'pg\_%' > That comes from v1.62 of pg_dumpall.c : > res = executeQuery(conn, "SELECT spcname, " > "pg_catalog.pg_get_userbyid(spcowner) AS spcowner, " >"spclocation, spcacl " >"FROM pg_catalog.pg_tablespace " >"WHERE spcname NOT LIKE E'pg\\_%'"); This query needs to be version-dependent, Bruce ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] escape string syntax and pg_dumpall
Andrew - Supernews <[EMAIL PROTECTED]> writes: >>> "WHERE spcname NOT LIKE E'pg\\_%'"); > It's not even correct as it stands - if you want to match a literal _ > using LIKE then you would need E'pg_%' there. Good point! > Would NOT LIKE 'pg!_%' ESCAPE '!' be better? Seems like a fine solution --- I was about to object that ESCAPE doesn't go back as far as PG 7.0, but neither does pg_tablespace, so that seems OK. Or perhaps better, use a regular regex: spcname !~ '^pg_'. The majority of the comparable cases in psql's describe.c do it this way, and they seem more readable to me ... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] build farm failure tuna on OSX 10.4 for 8.0
It appears to be getting the wrong address for tsearch()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x011b
0x9009a7c8 in tsearch ()
However if I set a break point for tsearch, I get
br tsearch
Breakpoint 5 at 0xe08c64: file txtidx.c, line 533.
further
(gdb) display *finfo
5: *finfo = {
fn_addr = 0x9009a798 ,
fn_oid = 377912,
fn_nargs = 0,
fn_strict = 0 '\0',
fn_retset = 0 '\0',
fn_extra = 0x0,
fn_mcxt = 0x20270f4,
fn_expr = 0x0
}
(gdb) list *0x9009a798
No source file for address 0x9009a798.
I admit to not being an expert in gdb here, but it certainly looks
like something isn't quite right
Dave
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] The reason for loris' intermittent prepared_xacts failures
Title: Re: [HACKERS] The reason for loris' intermittent prepared_xacts failures Andrew Dunstan wrote: How things will work with that setting on a non-English locale box I don't know - it might help if we had a Windows buildfarm member from one of our colleagues in a non-English speaking country. Actually my workstation is non-English (Czech) and it works (All 98 tests passed several times). It also fixed my rules test problem - it always failed before. About that Toms conclusion - I was trying to analyze it too but I lack knowledge of Postgres internals so I didn't come up with any final conclusion. I can however agree on few things - that OID isn't OID of pxtest2 and it seems to happend only if concurent drop table occurs in one of parralel tests. And I also agree with that PS. On related note, I was also testing that signal emulation when analyzing this and it seems to work without any errors (except for start of course but thats known) - I think Tom had some doubts about it after what he wrote in his first reply. -- Regards Petr Jelinek (PJMODOS)
Re: [HACKERS] build farm failure tuna on OSX 10.4 for 8.0
Dave Cramer <[EMAIL PROTECTED]> writes: > It appears to be getting the wrong address for tsearch() I applied a patch for that earlier today. It seems that in OS X 10.4 the compiler generates a function with the same name as the shared library, ie tsearch() for libtsearch ... and it doesn't tell you about the name conflict, it just lets the wrong function get called at runtime. Earlier OS X versions did not do this, and I have to say that it's one of the most brain-dead usurpations of application namespace I've seen in a long time. But there you have it. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] The reason for loris' intermittent prepared_xacts failures
Petr Jelinek <[EMAIL PROTECTED]> writes: > On related note, I was also testing that signal emulation when analyzing > this and it seems to work without any errors (except for start of course > but thats known) - I think Tom had some doubts about it after what he > wrote in his first reply. It was just one of the first things that came to mind when wondering "why does this only seem to happen on Windows?" At this point I'm convinced that the answer is "because pg_regress sets up the locale differently on Windows than anywhere else". But at the time I hadn't suspected a locale issue ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Truncate on tables with FK's
Hmmm...could we allow truncate in cases where all the FK's on a table refer only to that table itself? Chris ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Truncate on tables with FK's
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > Hmmm...could we allow truncate in cases where all the FK's on a table > refer only to that table itself? Alvaro already did that and more ... 2005-01-26 22:17 tgl * doc/src/sgml/ref/truncate.sgml, src/backend/catalog/heap.c, src/backend/commands/tablecmds.c, src/backend/nodes/copyfuncs.c, src/backend/nodes/equalfuncs.c, src/backend/parser/gram.y, src/backend/tcop/utility.c, src/include/catalog/heap.h, src/include/commands/tablecmds.h, src/include/nodes/parsenodes.h, src/test/regress/expected/temp.out, src/test/regress/expected/truncate.out, src/test/regress/sql/temp.sql, src/test/regress/sql/truncate.sql: Generalize TRUNCATE to support truncating multiple tables in one command. This is useful because we can allow truncation of tables referenced by foreign keys, so long as the referencing table is truncated in the same command. Alvaro Herrera regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
