On Tue, Dec 28, 2004 at 11:15:52PM -0700, Michael Fuhr wrote:
PostgreSQL 8.0.0rc2, 7.4.6
Solaris 9, FreeBSD 4.11-PRERELEASE
ECPG's CONNECT TO DEFAULT causes a segmentation fault. This
originally came up in the Connection without database name thread
in pgsql-hackers:
This is
I'm trying to implement a trigger within 8.0.0RC2.
I get a segfault when the trigger is fired, valgrind
reports an illegal read being the line:
TriggerData *trigdata = (TriggerData *) fcinfo-context;
Valgrind reports:
==941== Use of uninitialised value of size 4
==941==at
pgbuildfarm=# select name, operating_system, stage, count from buildsystems
b, (select sysname, stage, count(*) as count from build_status where log ~
'tablespace testspace is not empty' group by sysname, stage) as s where
s.sysname=b.name;
Note that the expected log has that as error
Kurt Roeckx wrote:
pgbuildfarm=# select name, operating_system, stage, count from buildsystems
b, (select sysname, stage, count(*) as count from build_status where log ~
'tablespace testspace is not empty' group by sysname, stage) as s where
s.sysname=b.name;
Note that the expected log
Sorry, my fault, just mistyped the function name
in PG_FUNCTION_INFO_V1() macro.
--strk;
On Wed, Dec 29, 2004 at 11:08:28AM +0100, strk wrote:
I'm trying to implement a trigger within 8.0.0RC2.
I get a segfault when the trigger is fired, valgrind
reports an illegal read being the line:
Le 28 déc. 04, à 23:36, Tom Lane a écrit :
Andrew Dunstan [EMAIL PROTECTED] writes:
This result is now seen for HEAD on buildfarm member osprey:
Yeah, I was wondering about that. It should be easy to reproduce the
failure by hand (just run the tsearch regression test and then
re-execute that
On Wed, Dec 29, 2004 at 10:32:21AM +0100, Michael Meskes wrote:
On Tue, Dec 28, 2004 at 11:15:52PM -0700, Michael Fuhr wrote:
ECPG's CONNECT TO DEFAULT causes a segmentation fault. This
originally came up in the Connection without database name thread
in pgsql-hackers:
This is
Greetings,
Due to the fact that group system id's and user system id's can
overlap, pg_class will need to change in order to accomedate group
ownership. The things I've thought of so far, in order of preference:
a) Add a boolean field 'relgroup_owned' which is 'false' when relowner
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
here is the tail of regression.diff (which indicates that the first=20
query failed):
SELECT '1'::mquery_txt;
! server closed the connection unexpectedly
! This probably means the server terminated abnormally
! before or
Andrew Dunstan [EMAIL PROTECTED] writes:
You're right - my query was not sufficiently specific. There have in
fact been 4 failures:
pgbuildfarm=# select sysname, snapshot, stage, branch from build_status
where log ~ 'tablespace testspace is not empty.*tablespace testspace
is not empty'
FYI, the release team is planning a PostgreSQL RC3 release for this
Friday.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.
Le 29 déc. 04, à 18:05, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
here is the tail of regression.diff (which indicates that the first=20
query failed):
SELECT '1'::mquery_txt;
! server closed the connection unexpectedly
! This probably means the server
Stephen Frost [EMAIL PROTECTED] writes:
Due to the fact that group system id's and user system id's can
overlap, pg_class will need to change in order to accomedate group
ownership. The things I've thought of so far, in order of preference:
I thought that the agreed-on direction for
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Due to the fact that group system id's and user system id's can
overlap, pg_class will need to change in order to accomedate group
ownership. The things I've thought of so far, in order of preference:
I
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
You're right - my query was not sufficiently specific. There have in
fact been 4 failures:
pgbuildfarm=# select sysname, snapshot, stage, branch from build_status
where log ~ 'tablespace testspace is not empty.*tablespace
Stephen Frost [EMAIL PROTECTED] writes:
Ah, alright, sounds good to me. I'll look into making them share a
common unique identifier space, that shouldn't be too difficult. Of
course, that'll require a dump/restore, I expect.. I don't suppose that
could possibly happen before 8.0, eh? :)
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Ah, alright, sounds good to me. I'll look into making them share a
common unique identifier space, that shouldn't be too difficult. Of
course, that'll require a dump/restore, I expect.. I don't suppose that
Stephen Frost [EMAIL PROTECTED] writes:
Well, yes, but that's no longer the issue. I guess my thought was that
if we could get the common id space change in before 8.0 then group
ownership could possibly be introduced in 8.1 w/o having to do a
dump/restore.
No chance whatever during RC
Andrew/all
I have not seen any problems on my MIPS systems since the rebuild ext3 (I ran
badblocks during fs creation). I should
have the alpha running about soon, the disk died and I am waiting a
replacement. I do believe there is a floating
point problem with older alpha's out there. The
Tom,
my systems are all EXT3 (Debian 3.1) (andrew can tell you which ones they are).
Jim
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: Kurt Roeckx [EMAIL PROTECTED], PostgreSQL-development
pgsql-hackers@postgresql.org
Sent:
Jim Buttafuoco wrote:
Andrew/all
I have not seen any problems on my MIPS systems since the rebuild ext3 (I ran badblocks during fs creation). I should
have the alpha running about soon, the disk died and I am waiting a replacement. I do believe there is a floating
point problem with older
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
Le 29 d=E9c. 04, =E0 18:05, Tom Lane a =E9crit :
Backtracing the core dump from that crash would do fine.
Here you go
(gdb) bt
#0 0x010a in ?? ()
#1 0x046e9cce in queryin (buf=3DCannot access memory at address 0x0
) at
Hi!
I'm maintaining a bunch of FreeBSD ports for postgresql stuff. I get
problems when building postgresql with Kerberos, because packages like
libpqxx does not automatically understand that it will also need to link
with libkrb.so. Is there any default way to get gnu configure for such
On Thu, 16 Dec 2004 21:54:14 -0300, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Else, it will have to wait, using XactLockTableWait, for
the first transaction in the array that is still running. We can be
sure that no one will try to share-lock the tuple while we check the
btree because we hold an
On Mon, 20 Dec 2004 21:44:01 +0100, [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] wrote on 20.12.2004, 19:34:21:
#1 could have a pretty serious performance impact, too. For small
numbers of FOR UPDATE locks (too few to force spill to disk) I would
expect #2 to substantially beat #1. #1
[I know I'm late and this has already been discussed by Richrad, Tom,
et al., but ...]
On Tue, 21 Dec 2004 16:17:17 -0600, Jim C. Nasby
[EMAIL PROTECTED] wrote:
look at where the last page you wrote out has ended up in the LRU list
since you last ran, and start scanning from there (by definition
Manfred Koizar [EMAIL PROTECTED] writes:
I don't see too much of a difference between #1 (an on-disk structure
buffered in shared memory) and #2 (a shared memory structure spilling
to disk).
If you stand back that far, maybe you can't see a difference ;-) ...
but the proposal on the table was
27 matches
Mail list logo
