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
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
--
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
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
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
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
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
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
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
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 ---
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
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
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
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
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
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,
16 matches
Mail list logo
