David Fetter <[EMAIL PROTECTED]> writes:
> It turns out that PL/PerlU wasn't available, even though createlang
> had succeeded. I think this is a bug in CREATE LANGUAGE, as CREATE
> LANGUAGE should have failed when it found no PL/Perl compiled in.
Works for me:
$ createlang plperlu array_test
cr
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Robert Treat wrote:
>> It's generally a very bad idea for a BSD licensed project to include lgpl
>> licensed code
> Psqlodbc package is LGPL licensed and seems to have little problem to
> include copy of BSD licensed code as a part of it.
Right, that d
Hi,
In reference to the seq scans roadmap, I have just submitted a patch
that addresses some of the concerns.
The patch does this:
1. for small relation (smaller than 60% of bufferpool), use the
current logic
2. for big relation:
- use a ring buffer in heap scan
- pin firs
Folks,
While trying to test the arrays of complex types, I used a
stripped-down configure. Too stripped down, it turns out.
CFLAGS="-O0" ./configure --prefix=/var/lib/pgsql/tip --with-pgport=2225
--enable-cassert --enable-debug --enable-depend --enable-integer-datetimes
I set $PGDATA to my te
Alvaro Herrera wrote:
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGP
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
I am havi
On May 9, 2007, at 11:01 AM, Magnus Hagander wrote:
On Wed, May 09, 2007 at 10:55:12AM -0500, Jim Nasby wrote:
On May 8, 2007, at 2:24 PM, Magnus Hagander wrote:
Speaking of which, it might be interesting to actually show these
values
in the stats collector. I was thinking three cols for each d
Magnus Hagander wrote:
Gregory Stark wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
What 3 columns? In-memory sorts, on-disk sorts, and on-disk size?
(Sum of how much spilled to disk).
I was thinking in-mem sorts, on-disk sorts, limited-by-LIMIT sorts (that
would be the new feature..)
After some more study of the SQL spec, the distinction between GENERATED
ALWAYS AS IDENTITY and GENERATED BY DEFAULT AS IDENTITY is not what
I thought it was.
* As far as I can find from the spec, there is *no* difference between
the two cases for INSERT commands. The rule is that you ignore any
On Wed, 9 May 2007, Tom Lane wrote:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
I tried that connecting to template1, but it doesn't helped. The problem
occurs even if I repeat 'drop;create' in one connection (the same backend).
Hmm. Do you have autovacuum turned on? 8.2 isn't real smart abou
Gregory Stark wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>
>>> What 3 columns? In-memory sorts, on-disk sorts, and on-disk size?
>>> (Sum of how much spilled to disk).
>> I was thinking in-mem sorts, on-disk sorts, limited-by-LIMIT sorts (that
>> would be the new feature..)
>
> Tom'
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> I tried that connecting to template1, but it doesn't helped. The problem
> occurs even if I repeat 'drop;create' in one connection (the same backend).
Hmm. Do you have autovacuum turned on? 8.2 isn't real smart about
dealing with autovac running in the
On Wed, 9 May 2007, Tom Lane wrote:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
I'm investigating a problem my client experienced with
"create database xxx with template=yyy" - they often get error
"ERROR: source database "yyy" is being accessed by other users",
Your test case simply shows tha
[cc'ing to pgsql-hackers since this is looking like a contrib/intarray bug]
"Valentine Gogichashvili" <[EMAIL PROTECTED]> writes:
> here is the DT
That works fine for me in 8.2:
regression=# explain SELECT id, (myintarray_int4)
FROM myintarray_table_nonulls
WHERE ARRAY[8] <@ myintarray_int4;
Tom Lane wrote:
Your test case simply shows that it takes a finite amount of time for
the previous backend to exit; depending on scheduler priorities it's
possible for the next instance to connect and try to CREATE DATABASE
before the previous one is gone. My suggestion would be to connect
to
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> I'm investigating a problem my client experienced with
> "create database xxx with template=yyy" - they often get error
> "ERROR: source database "yyy" is being accessed by other users",
Your test case simply shows that it takes a finite amount of time
Hi there,
I'm investigating a problem my client experienced with
"create database xxx with template=yyy" - they often get error
"ERROR: source database "yyy" is being accessed by other users",
I modelled situation in clean environment with very simple perl script
( FreeBSD 6.2-STABLE, postgre
Jim,
I am sympathetic to the issues you and Andrew are describing (I
understand Bruce's stream analogy, but I think Andrew is right that
from the user's point of view, it's not usable). But I am not
convinced that users voting on desired features will get us the
users' desired features. The fe
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> What 3 columns? In-memory sorts, on-disk sorts, and on-disk size?
>> (Sum of how much spilled to disk).
>
> I was thinking in-mem sorts, on-disk sorts, limited-by-LIMIT sorts (that
> would be the new feature..)
Tom's code distinguished in-memory
Robert Treat wrote:
> On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
> > Andrew Dunstan wrote:
> > > Hiroshi Inoue wrote:
> > >> Maybe it's BSD which is different from the license of psqlodbc (LGPL).
> > >> Is there no problem with their coexistence ?
> > >> Or is it possible for psqlodbc to b
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
> Andrew Dunstan wrote:
> > Hiroshi Inoue wrote:
> >> Maybe it's BSD which is different from the license of psqlodbc (LGPL).
> >> Is there no problem with their coexistence ?
> >> Or is it possible for psqlodbc to be LGPL entirely ?
> >
> > I am h
On Wed, May 09, 2007 at 10:55:12AM -0500, Jim Nasby wrote:
> On May 8, 2007, at 2:24 PM, Magnus Hagander wrote:
> >Speaking of which, it might be interesting to actually show these
> >values
> >in the stats collector. I was thinking three cols for each database
> >(probably the best level?) that
On May 8, 2007, at 2:24 PM, Magnus Hagander wrote:
Speaking of which, it might be interesting to actually show these
values
in the stats collector. I was thinking three cols for each database
(probably the best level?) that counts each of those three
counters. If
you have a lot of sorts (perc
Karel Gardas wrote:
>
> Hello,
>
> first of all, I've tried to ask on pgsql-general mailing list as advised,
> but no answer.
>
> I'd like to look at a possibility of integrating OpenPMF
> (http://www.openpmf.org) with the PostgreSQL. There is a possibility to
> have a "weak" integration by using a
Hello,
first of all, I've tried to ask on pgsql-general mailing list as advised,
but no answer.
I'd like to look at a possibility of integrating OpenPMF
(http://www.openpmf.org) with the PostgreSQL. There is a possibility to
have a "weak" integration by using a provided rule system and SQL,
Ned Lilly wrote:
On 5/9/2007 7:46 AM Dave Page wrote:
Oh, hang on... Vista's new 'security' features include popups that ask
permission from the user before running any installers. One of the
more basic checks they use is the filename - *anything* called
setup.exe will cause user confirmation
On 5/9/2007 7:46 AM Dave Page wrote:
Oh, hang on... Vista's new 'security' features include popups that ask
permission from the user before running any installers. One of the more
basic checks they use is the filename - *anything* called setup.exe will
cause user confirmation to be required be
On Wed, May 09, 2007 at 08:40:24AM -0400, Andrew Dunstan wrote:
>
>
> Peter Eisentraut wrote:
> >Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
> >
> >>Can we rename the test please?
> >>
> >
> >I'm thinking no. Brain-dead systems should produce brain-dead test
> >results.
> >
> >
>
Peter Eisentraut wrote:
Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
Can we rename the test please?
I'm thinking no. Brain-dead systems should produce brain-dead test results.
Not doing this would seem like sheer bloody-mindedness. We have
workarounds for craziness on ma
Peter Eisentraut wrote:
Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
Can we rename the test please?
I'm thinking no. Brain-dead systems should produce brain-dead test results.
And that helps us how exactly, on what will probably be the most widely
used OS in the world within a few ye
Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
> Can we rename the test please?
I'm thinking no. Brain-dead systems should produce brain-dead test results.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
T
Michael Meskes wrote:
Dave, could you please run
insert into date_test ( d , ts ) values ( date '1966-01-17' ,
timestamp '2000-07-12 17:34:29' );
on the Vista system and then select * from date_test;?
According to the logs the insert runs successfully but the select gives
an invalid date
On Tue, 2007-05-08 at 11:40 +0100, Heikki Linnakangas wrote:
> Here's my roadmap for the "scan-resistant buffer cache" and
> "synchronized scans" patches.
>
> 1. Fix the current vacuum behavior of throwing dirty buffers to the
> freelist, forcing a lot of WAL flushes. Instead, use a backend-priv
On Wed, May 09, 2007 at 09:21:59AM +0100, Dave Page wrote:
> I asked about this before, but the thread got hijacked to discuss
> another buildfarm failure :-(. Currently our only Windows Vista
> buildfarm member (Vaquita) fails every time (assuming it gets that far)
> on ECPG's dt_test and updat
"Marshall, Steve" <[EMAIL PROTECTED]> wrote:
> the first query would be optimized using
> constraint exclusion, while the second query would not:
>
> SELECT * FROM test_bulletins WHERE created_at > '2006-09-09
> 05:00:00+00'::timestamptz;
> SELECT * FROM test_bulletins WHERE created_at > '2006
> >> Are you filling multiple buffers in the buffer cache with a single
> >> read-call?
> >
> > yes, needs vector or ScatterGather IO.
>
> I would expect that to get only moderate improvement.
The vast improvement comes from 256k blocksize.
> To get
> the full benefit I would think you would
Hi,
I asked about this before, but the thread got hijacked to discuss
another buildfarm failure :-(. Currently our only Windows Vista
buildfarm member (Vaquita) fails every time (assuming it gets that far)
on ECPG's dt_test and update tests.
I've checked the FS permissions, and see no obviou
37 matches
Mail list logo
