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,
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
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 w
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 y
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
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 t
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 solu
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 "
>>
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 p
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'
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 th
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)
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 PR
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 ambiva
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
-- O
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
16 matches
Mail list logo
