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
[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 defini
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 bea
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 hol
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
packa
=?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
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 alph
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
Sent: Wed, 29 Dec 2004 12:26:5
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
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
* 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
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 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 "t
* 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 preferenc
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
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 te
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.
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
=?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
> ! bef
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
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:
>
> Th
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 que
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:
>
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 h
> 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
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 0x3CD9C197
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 i
27 matches
Mail list logo
