Why does the first query below return the same value for each row
while the second query returns random values? Planner optimization?
test= SELECT ARRAY(SELECT random()) FROM generate_series(1, 5);
?column?
-
{0.269273371561092}
{0.269273371561092}
Tom Lane schrieb:
Greg Stark [EMAIL PROTECTED] writes:
So why bother with driving multiple invocations of psql under
Expect. Just use DBD::Pg to open as many connections as you want and
issue whatever queries you want.
The bit that I think is missing in DBI is issue a command and don't
wait
Michael Fuhr wrote:
Why does the first query below return the same value for each row
while the second query returns random values? Planner optimization?
I assume it is due to some kind of flattening in the planner, but it is
totally unrelated to ARRAY(subquery):
regression=# SELECT
Tom Lane [EMAIL PROTECTED] writes:
This patch is utterly wrong. Please revert it.
This is entirely likely to find the same non-BM_VALID buffer that was
assigned in the first iteration.
Yes, Tom is right. A relation extension might find a non-BM_VALID buffer
left by previous failed
On Mon, Aug 15, 2005 at 06:01:20PM -0400, Tom Lane wrote:
What we really need is a test program that can issue a command on one
connection (perhaps waiting for it to finish, perhaps not) and then
issue other commands on other connections, all according to a script.
Well, using Tcl with its
On 15-Aug-05, at 1:30 PM, Joshua D. Drake wrote:
Hello,
I have negotiated with the author of pl/Ruby to release plRuby
under the PostgreSQL license. The reason I did this is the following:
1. I felt we needed a truly OO language in core.
Why ? Are you truly going to write huge OO
Tino Wildenhain [EMAIL PROTECTED] writes:
Tom Lane schrieb:
The bit that I think is missing in DBI is issue a command and don't
wait for the result just yet. ...
I might be wrong though, not being exactly a DBI guru ... can this
sort of thing be done?
I wonder if you dont have a wrapper
Tom Lane schrieb:
Tino Wildenhain [EMAIL PROTECTED] writes:
Tom Lane schrieb:
The bit that I think is missing in DBI is issue a command and don't
wait for the result just yet. ...
I might be wrong though, not being exactly a DBI guru ... can this
sort of thing be done?
I wonder if you
Dave Cramer wrote:
On 15-Aug-05, at 1:30 PM, Joshua D. Drake wrote:
Hello,
I have negotiated with the author of pl/Ruby to release plRuby under
the PostgreSQL license. The reason I did this is the following:
1. I felt we needed a truly OO language in core.
Why ? Are you truly going
Michael Fuhr [EMAIL PROTECTED] writes:
Why does the first query below return the same value for each row
while the second query returns random values? Planner optimization?
test= SELECT ARRAY(SELECT random()) FROM generate_series(1, 5);
test= SELECT ARRAY(SELECT random() + x * 0) FROM
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
So why bother with driving multiple invocations of psql under
Expect. Just use DBD::Pg to open as many connections as you want and
issue whatever queries you want.
The bit that I think is missing in DBI is issue a
Tom Lane wrote:
Sure, it wouldn't take much to create a minimal C+libpq program that
would do the basics. But the history of testing tools teaches that
you soon find yourself wanting a whole lot more functionality, like
conditional tests, looping, etc, in the test-driver mechanism.
That's
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe the right answer is just to hack up Pg.pm or DBD::Pg to provide
the needed asynchronous-command-submission facility, and go forward
from there using the Perl Test framework.
How will we make sure it's consistent? People have
[ redirected to -hackers ]
I wrote:
This suggests that we need a way to prevent immediate execution of
freshly queued triggers at the end of a command fired by an FK trigger.
If we could move them to the end of the trigger queue that the FK
operation itself is in, things would work reasonably
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah, that would be an issue. But can't a Perl script require
version = m.n for each module it uses?
Yes it can, but are you going to restrict building or running
regressions to only thos platforms that have our required modules
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe the right answer is just to hack up Pg.pm or DBD::Pg to provide
the needed asynchronous-command-submission facility, and go forward
from there using the Perl Test framework.
How will we make
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Another line of thought is to write a fresh implementation of the wire
protocol all in Perl, so as not to depend on DBI or much of anything
except Perl's TCP support (which I hope is reasonably well standardized
;-)). If you wanted to
Folks,
I think you should take a closer look at PL/Java for the following reasons:
Hmmm, this brings up a good point. If we're going to consider PL/Ruby for
main distro in 8.2, should we not consider PL/Java as well?
--
Josh Berkus
Aglio Database Solutions
San Francisco
Is there a sound reason to believe that pl/Ruby does not have the
trusted/untrusted issue ?
Sure... it hasn't been found. We can play the it might have or might
not have game all day long but it won't get us anywhere. Today, and
yesterday pl/Ruby can be run trust/untrusted, pl/python can
I think you should take a closer look at PL/Java for the following reasons:
1. The number of followers of the Java language is extremely high and
increasing.
2. Oracle and DB2 offers Java as a procedural language. You make
transisitions easy.
3. There's a SQL standard for the mapping between
Josh Berkus wrote:
Folks,
I think you should take a closer look at PL/Java for the following reasons:
Hmmm, this brings up a good point. If we're going to consider PL/Ruby for
main distro in 8.2, should we not consider PL/Java as well?
There is one strong reason other than that, I
On Tue, 16 Aug 2005, Tom Lane wrote:
[ redirected to -hackers ]
I wrote:
This suggests that we need a way to prevent immediate execution of
freshly queued triggers at the end of a command fired by an FK trigger.
If we could move them to the end of the trigger queue that the FK
Well, if we are going to consider pljava for the main distribution,
then we should consider pl-j for inclusion as well.
Dave
On 16-Aug-05, at 11:53 AM, Josh Berkus wrote:
Folks,
I think you should take a closer look at PL/Java for the following
reasons:
Hmmm, this brings up a good
Joshua,
There's some material that explains the inner workings on the
gborg.postgresql.org/project/pljava site. Beyond that (and trying it out
of course), I'd be more then happy to answer any questions.
Regards,
Thomas Hallgren
Joshua D. Drake wrote:
I think you should take a closer look
On 8/16/05, Joshua D. Drake [EMAIL PROTECTED] wrote:
Sure... it hasn't been found. We can play the it might have or might
not have game all day long but it won't get us anywhere. Today, and
yesterday pl/Ruby can be run trust/untrusted, pl/python can not.
Both of these things could be said
Dave Cramer wrote:
Well, if we are going to consider pljava for the main distribution,
then we should consider pl-j for inclusion as well.
I believe we should consider both but only include 1.
Sincerely,
Joshua D. Drake
Dave
On 16-Aug-05, at 11:53 AM, Josh Berkus wrote:
Folks,
I
David Fetter wrote:
On a very closely related note, what's the latest on the integration
of PL/Java and PL/J?
Last time I spoke to Laszlo and Dave about this, we discussed the
following solution:
- PL/Java should be profiled as a tight Java integration, i.e. Java
executes in the same VM
On Tue, Aug 16, 2005 at 01:17:27PM -0400, Gregory Maxwell wrote:
On 8/16/05, Joshua D. Drake [EMAIL PROTECTED] wrote:
Sure... it hasn't been found. We can play the it might have or
might not have game all day long but it won't get us anywhere.
Today, and yesterday pl/Ruby can be run
Joshua D. Drake wrote:
Most distributions of Linux (yes I know that there is more than Linux
out there) don't ship with Java. They ship with a wanna be, but couldn't
be in the next 2 years thing call Gcj.
Gcj is OK with PL/Java, albeit slower then the more common JVM's from
Sun, IBM, or BEA.
Earlier today I noticed these lines in this buildfarm log
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypusdt=2005-08-16%2002:05:00
ccache gcc -O3 -pipe -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wendif-labels -fno-strict-aliasing -g -fPIC -DPIC -shared
I have started compiling the release notes for 8.1. I should be done by
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:
/usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o):
relocation R_X86_64_32S can not be used when making a shared object;
recompile with -fPIC
Does that mean that we are attempting to link against a static libperl.a?
I thought we
On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote:
If somebody has figured out a way to make a PL/Python (without the U),
that's great, but nothing has happened on this front in a couple of
years, and Guido said that it was a problem with the language that he
wasn't going to fix.
On Tue, Aug 16, 2005 at 11:39:04PM +0300, Marko Kreen wrote:
On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote:
If somebody has figured out a way to make a PL/Python (without the
U), that's great, but nothing has happened on this front in a
couple of years, and Guido said that it
Once more:
I would like to get at least some answer, why my patch for enabling
concurrent VACUUM was left out from 8.1.
It was submitted well in time, and there was only minimal amount of
discussion of an earlier patch,and AFAIK I addressed all the issues
raised there.
I really hate to have to
On T, 2005-08-16 at 09:14 -0700, Joshua D. Drake wrote:
Is there a sound reason to believe that pl/Ruby does not have the
trusted/untrusted issue ?
Sure... it hasn't been found.
It hasn't been found is a really weak reason for any security
assumption, even for a programming language. It
On 8/16/05, David Fetter [EMAIL PROTECTED] wrote:
It's not. In PL/parlance, trusted means prevented from ever
opening a filehandle or a socket, and PL/PythonU is called
PL/Python*U* (U for *un*trusted) because it cannot be so prevented.
If somebody has figured out a way to make a PL/Python
Andrew Dunstan wrote:
Earlier today I noticed these lines in this buildfarm log
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypusdt=2005-08-16%2002:05:00
ccache gcc -O3 -pipe -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wendif-labels -fno-strict-aliasing -g -fPIC -DPIC -shared
On Tue, Aug 16, 2005 at 05:09:24PM -0400, Gregory Maxwell wrote:
On 8/16/05, David Fetter [EMAIL PROTECTED] wrote:
It's not. In PL/parlance, trusted means prevented from ever
opening a filehandle or a socket, and PL/PythonU is called
PL/Python*U* (U for *un*trusted) because it cannot be so
Yes it can, but are you going to restrict building or running
regressions to only thos platforms that have our required modules
installed? That might be thought a tad unfriendly.
You could include DBD::Pg with the distribution and run it locally. Perhaps
even DBI, leaving Perl the only
On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote:
As with an automatic weapon, Perl absolutely *requires* discipline to
use properly. Unlike an automatic weapon, Perl is perfectly OK to use
day-to-day in civilian life :)
What on earth would be the proper use of an automatic
Alvaro Herrera wrote:
On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote:
As with an automatic weapon, Perl absolutely *requires* discipline to
use properly. Unlike an automatic weapon, Perl is perfectly OK to use
day-to-day in civilian life :)
What on earth would be the proper
Alvaro Herrera said:
On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote:
As with an automatic weapon, Perl absolutely *requires* discipline to
use properly. Unlike an automatic weapon, Perl is perfectly OK to use
day-to-day in civilian life :)
What on earth would be the proper
Hannu Krosing [EMAIL PROTECTED] writes:
Once more:
I would like to get at least some answer, why my patch for enabling
concurrent VACUUM was left out from 8.1.
You did not respond to this:
http://archives.postgresql.org/pgsql-patches/2005-08/msg00238.php
regards, tom
This seems to have descended into a my programming language is better
than your programming language war, which has ceased to be
interesting, much less illuminating to the problem at hand.
There are two questions, I perceive, critical to making decisions
about what goes into the core. While I'm
Mary Edie Meredith [EMAIL PROTECTED] writes:
I'm still very concerned about what I'm seeing in the oprofile:
namely: .CreateLWLocks is the second highest entry for postgres.
http://developer.osdl.org/maryedie/DBT2_PGSQL/59/oprofile.txt
This says there's something wrong with your oprofile
On Thu, 2005-08-11 at 22:11 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
O_DIRECT is only being used for WAL page writes (or I sure hope so
anyway), so shared_buffers should be irrelevant.
Uh, O_DIRECT really just enables when open_sync is
On Tue, 2005-08-16 at 18:53 -0400, Tom Lane wrote:
Mary Edie Meredith [EMAIL PROTECTED] writes:
I'm still very concerned about what I'm seeing in the oprofile:
namely: .CreateLWLocks is the second highest entry for postgres.
http://developer.osdl.org/maryedie/DBT2_PGSQL/59/oprofile.txt
People:
How about we draft some criteria for inclusion of a PL in the main distro?
Suggestions:
1) The PL must be stable (that is, not capable of crashing the backend)
2) The PL must be buildable only using --with-{lang} and createlang
(assuming that the user has the correct libraries)
3)
On Tue, 16 Aug 2005 18:53:55 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Mary Edie Meredith [EMAIL PROTECTED] writes:
I'm still very concerned about what I'm seeing in the oprofile:
namely: .CreateLWLocks is the second highest entry for postgres.
There are two questions, I perceive, critical to making decisions
about what goes into the core. While I'm not a contributing developer,
I've worked with PostgreSQL since it was still Stonebraker's child and
still use Postquel, and have rolled it inot a lot of production
situations, so I'm going
On Tue, 2005-08-16 at 16:07 -0700, Mark Wong wrote:
On Tue, 16 Aug 2005 18:53:55 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Mary Edie Meredith [EMAIL PROTECTED] writes:
I'm still very concerned about what I'm seeing in the oprofile:
namely: .CreateLWLocks is the second highest entry for
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Once more:
I would like to get at least some answer, why my patch for enabling
concurrent VACUUM was left out from 8.1.
You did not respond to this:
http://archives.postgresql.org/pgsql-patches/2005-08/msg00238.php
Yep, that's
Folks,
I just noticed that we seem to have two new bgwriter GUCs. Could someone
bring me up to date on the status of bgwriter configuration?I can't
draw a connection between the issues we discussed in December and adding
two new GUCs.
--
--Josh
Josh Berkus
Aglio Database Solutions
San
On Tue, 2005-08-16 at 16:07 -0700, Mark Wong wrote:
On Tue, 16 Aug 2005 18:53:55 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Mary Edie Meredith [EMAIL PROTECTED] writes:
I'm still very concerned about what I'm seeing in the oprofile:
namely: .CreateLWLocks is the second highest entry for
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
/usr/bin/ld: /usr/local/lib/perl5/5.6.1/mach/CORE/libperl.a(perl.o): relocation
R_X86_64_32S can not be used when making a shared object; recompile with -fPIC
Does that mean that we are attempting to link against a
As with an automatic weapon, Perl absolutely *requires* discipline to
use properly. Unlike an automatic weapon, Perl is perfectly OK to use
day-to-day in civilian life :)
What on earth would be the proper use of an automatic weapon?
You obviously don't live in the US.
Yeah, hunting...
Tom Lane [EMAIL PROTECTED] writes:
This is entirely likely to find the same non-BM_VALID buffer that was
assigned in the first iteration.
So after we found it, we still need to extend the file. In ReadBuffer():
---
/* if it was already in the buffer pool, we're done */
if (found)
{
...
Qingqing Zhou [EMAIL PROTECTED] writes:
Shall we write
/* If it was already in the buffer pool and not for extension, we're
done */
if (found !isExtend)
instead?
If you can demonstrate a problem in this code, please do. I'm very much
less than excited about making random changes
59 matches
Mail list logo
