Josh Berkus schrieb:
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 co
"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 rando
"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)
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 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 stat
> 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 seco
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 F
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
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 high
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 t
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.
> > http://developer.osdl.org/maryedie/D
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) The
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
On Thu, 2005-08-11 at 22:11 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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 used,
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
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
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,
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
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 u
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 wea
> 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 unkn
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
Andrew Dunstan wrote:
Earlier today I noticed these lines in this buildfarm log
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=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 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
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
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 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 t
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.
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
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.
Earlier today I noticed these lines in this buildfarm log
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypus&dt=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
-Wl,-x,-soname,libplpe
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.
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
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
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 thi
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 b
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
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 po
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
>
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 have
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
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
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
--
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
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:
>> 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 m
[ 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 reasona
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
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 the
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
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
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 t
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
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 ha
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 function
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
"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 faile
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 (SELECT
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
wa
59 matches
Mail list logo
