Greg Smith <[EMAIL PROTECTED]> writes:
> On Fri, 22 Feb 2008, Tom Lane wrote:
>> Counts are useless here, we need to see the sequence of write locations
>> to find out if there's a lot of nonconsecutive writes happening.
> How were you planning to analyze the strace output to quantify that?
I di
On Fri, 22 Feb 2008, Tom Lane wrote:
Counts are useless here, we need to see the sequence of write locations
to find out if there's a lot of nonconsecutive writes happening.
How were you planning to analyze the strace output to quantify that? I
would think you'd need to parse the file to gra
Andy Pavlo <[EMAIL PROTECTED]> writes:
> I have added support in readfuncs.c to write out Query and PlannedStmt
> objects
> using nodeToString() and then read them back in. We needed this so that we
> could use PREPARE and write the arguments to StorePreparedStatement() out to
> a file. We are
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> ... BTW, the strace had better run across the whole
>> PG process tree --- it's quite possible that there's some interaction
>> between the bgwriter and the backend doing COPY, for instance.
> So you want an st
I have added support in readfuncs.c to write out Query and PlannedStmt objects
using nodeToString() and then read them back in. We needed this so that we
could use PREPARE and write the arguments to StorePreparedStatement() out to
a file. We are going then read them back into Postgres on a diffe
On Fri, 22 Feb 2008, Richard Huxton wrote:
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
Would there be any support for two changes in 8.4 though?
1. Tag tsvector/tsquery's with the (oid of) their configuration?
2. Either warn or require CASCADE on changes to a configuration/
On Tue, Feb 19, 2008 at 3:36 AM, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> We propose to implement the recursive query (WITH RECURSIVE clause)
> defined in SQL:1999 and later. With the recursive query, one can
> easily inquire the data expressed as tree and graph structures. The
> actual synta
Peter,
> Half of this entire thread is content-free because the participants are
> apparently not aware that a database owner can add plpgsql *without*
> superuser privileges.
Yep. Among 280+ new features for 8.3, most of us missed that patch.
Thanks, Jeremy!
All, I think Jeremy's patch prett
Robert Lor <[EMAIL PROTECTED]> wrote:
> Peter,
>
> Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Could you please use diff -c or -u for the patch? It's quite hard
> to
> > read this way.
>
> Attached is the patch with diff -c.
>
Oops, here's the real attachment!
Regards,
-Robert
dtrac
Hi.
From: "Magnus Hagander" <[EMAIL PROTECTED]>
we can include in the next release.:-)
Thanks!
Good news. Can you provide a patch for the msvc build system to build
with it? We can't really ship it in the next release if we can't build
with it ;-)
Ahh Ok, I try it first and need to check
Peter,
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Could you please use diff -c or -u for the patch? It's quite hard to
> read this way.
Attached is the patch with diff -c.
Thanks,
-Robert
---(end of broadcast)---
TIP 3: Have you checked our e
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
Would there be any support for two changes in 8.4 though?
1. Tag tsvector/tsquery's with the (oid of) their configuration?
2. Either warn or require CASCADE on changes to a
configuration/dictionary that could impact existing indexe
>>> On Fri, Feb 22, 2008 at 10:09 AM, in message <[EMAIL PROTECTED]>,
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Roberts, Jon wrote:
>> However, you can not create anything in Oracle without being given
>> permission to create it. The notion that you can create a function
>> because you have co
Am Freitag, 22. Februar 2008 schrieb Robert Lor:
> Preliminary patch is attached.
Could you please use diff -c or -u for the patch? It's quite hard to read
this way.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 22 Feb 2008 12:54:00 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >> IIRC we were speculating that data was being written
> >> in a pattern that required a
On Fri, Feb 22, 2008 at 11:30:28AM -0500, Andrew Satori wrote:
> As a packager, I respond to customer pressure by solving their needs,
> so I pre-package those contrib's as needed, but I do feel that they
> should be reviewed as potential core inclusions
Given that you don't need to be superus
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> IIRC we were speculating that data was being written
>> in a pattern that required a lot of seeking thus ruining throughput,
>> but we didn't have any hard evidence of that. Did you do the
>> strace'ing I sugges
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Not really sure what to think here. On the one hand I agree that since
> the dbowner can load it at their leisure its cool. On the other hand I
> wonder why we continue to add extra unnecessary steps to our life. Yes,
> it is a simple step but it is o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 22 Feb 2008 12:39:57 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Yeah, that... is beyond my abilities. Well reading it is anyway. I
> > can provide any information people want though. Tom? Greg
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Yeah, that... is beyond my abilities. Well reading it is anyway. I can
> provide any information people want though. Tom? Greg? Andrew? Somebody?
> What information do you want from me to help you track this down?
The vmstat output you showed before
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 22 Feb 2008 12:31:14 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > So on reflection I'm now inclined to say we should not change what
> > we are now doing, which is simply to allow the db owner to i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> So on reflection I'm now inclined to say we should not change what we
> are now doing, which is simply to allow the db owner to install and
> control access to the language.
+1. It's worth pointing out here that we just changed the rules in 8.3
to ma
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
For example, since we don't support temp functions, we should probably
ban the creation of functions in temp schemas (which I found was possible).
What for? If you don't want someone to use a language, you should
either revo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 22. Februar 2008 schrieb Tom Lane:
>> Yeah, I think it would be folly to assume that we can name all the
>> individual object files in one big command line. But isn't the current
>> patch trying to do exactly that?
> The current patch ass
Richard Huxton <[EMAIL PROTECTED]> writes:
> Would there be any support for two changes in 8.4 though?
> 1. Tag tsvector/tsquery's with the (oid of) their configuration?
> 2. Either warn or require CASCADE on changes to a
> configuration/dictionary that could impact existing indexes etc.
IIRC,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 18:54:38 -0800
Luke Lonergan <[EMAIL PROTECTED]> wrote:
> Bah.
>
> It's the stuff in the format translation path and conversion to/from
> datums that is the bottleneck.
So how do we fix that? This performance is pretty anemic.
>
Motivation:
To enable probes to work with Mac OS X Leopard and other OSes that will
support DTrace in the future. Bug filed on this issue
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00201.php
The problem:
There are two different mechanisms to implementing application level
probes in
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
"D'Arcy J.M. Cain wrote:
> Besides, proof that it would do no extra harm is hardly a strong
> argumet for including it. Given how easy it is to add it to any DB
> that needs it, I fail to see why we should add it by default.
Because we're not
Speaking as someone who is all about packaging PG for end users, and
in truth could care less what is included by default, I can tell you
that the top 3 requests I get from end users that don't want to muck
around with building and installing themselves are for pl/pgsql,
tsearch2 (now inclu
Am Freitag, 22. Februar 2008 schrieb Tom Lane:
> Yeah, I think it would be folly to assume that we can name all the
> individual object files in one big command line. But isn't the current
> patch trying to do exactly that?
The current patch assumes that it works in most environments and offers t
On Fri, 22 Feb 2008, D'Arcy J.M. Cain wrote:
> On Fri, 22 Feb 2008 07:37:55 +
> "Dave Page" <[EMAIL PROTECTED]> wrote:
> > I know I'm gonna regret wading in on this, but in my mind this is akin
> > to one of the arguments for including tsearch in the core server -
> > namely that too many brai
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Well, my goal here was that we could use both ways of building for a while
> because we have no experience with how long command lines and argument lists
> we can handle portably.
Yeah, I think it would be folly to assume that we can name all the
in
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Roberts, Jon wrote:
>> However, you can not create anything in Oracle without being given
>> permission to create it. The notion that you can create a function
>> because you have connect rights to the database is foreign to me.
>> Connect should mean c
Peter Eisentraut wrote:
> Eventually, we could ideally transform the subdirectory Makefiles from
> independently callable Makefiles to mere include files so we have only one
> big dependency tree at the top, which would get rid of the annoying and
> time-consuming directory traversal. This, ho
Roberts, Jon wrote:
However, you can not create anything in Oracle without being given
permission to create it. The notion that you can create a function
because you have connect rights to the database is foreign to me.
Connect should mean connect, not connect AND create.
Include the language
Am Freitag, 22. Februar 2008 schrieb Alvaro Herrera:
> Hmm. Do we need the text file? I was kinda hoping we could just aggregate
> each subdir's OBJS into a big variable listing all the needed files, and
> then invoking the linker with that.
Well, my goal here was that we could use both ways of
On Fri, 22 Feb 2008 07:37:55 +
"Dave Page" <[EMAIL PROTECTED]> wrote:
> I know I'm gonna regret wading in on this, but in my mind this is akin
> to one of the arguments for including tsearch in the core server -
> namely that too many brain dead hosting providers won't add a contrib
> module or
Am Freitag, 22. Februar 2008 schrieb Tom Lane:
> What is the build time like with vs without this?
It's virtually indistinguishable. The big linker call doesn't take any
measurable extra time.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broa
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Andrew Dunstan
> Sent: Friday, February 22, 2008 9:28 AM
> To: Tom Lane
> Cc: Joshua D. Drake; Greg Sabino Mullane; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Including PL/PgS
Tom Lane wrote:
Certainly you can cause massive DOS-type problems in plain SQL without
any access to plpgsql, but that type of juvenile delinquency isn't what
concerns me. What I'm worried about is whether plpgsql isn't a useful
tool for the sort of professional who would much rather you never
> Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
>
> > 5. Limitation with PostgreSQL
> >
> > 1) we do not implement SEARCH clause and CYCLE clause. This is because
> >we need array of rows to implement them. Note that there's no
> >support for array of rows in PostgreSQL.
>
> What is difference
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Here is a patch so that the backend is linked in one piece instead of using
> the SUBSYS.o files.
> The question is how we want to activate that. I currently used make
> BIGLINK=1, which is obviously just for testing. Should we just turn it on by
Peter Eisentraut wrote:
> Here is a patch so that the backend is linked in one piece instead of using
> the SUBSYS.o files.
>
> The question is how we want to activate that. I currently used make
> BIGLINK=1, which is obviously just for testing. Should we just turn it on by
> default and see
Joshua D. Drake wrote:
> I probably shouldn't be answering this at two in the morning but... As I
> understand it in a hosted environment it is quite common that a
> superuser will do this:
>
> create database foo owner foo;
>
> Database foo would get plpgsql (as would user foo) at that point
On Fri, 2008-02-22 at 01:08 +0900, Hiroshi Saito wrote:
> Hi all.
>
> The door was opened by Mr. Ralf S. Engelschall of a great developer.
> http://www.ossp.org/pkg/lib/uuid/
> It can be used from Version 1.6.1.
>
> Please see,
> http://winpg.jp/~saito/pg_work/OSSP_win32/
>
> we can include in
Hi,
Magnus Hagander wrote:
...
Can you explain why this wouldn't be usable?
Because you will end up with an ever-growing file, that will be a PITA to
deal with. Consider it after 10k+ changes. (yes, I can see that happening.
You know how some people use GUIs) Or 100k. The problem does not happ
I've been looking at a problem someone encountered with ts_headline:
http://archives.postgresql.org/pgsql-general/2008-02/msg01035.php
It turns out the problem was mixing ts_headline()
with to_tsquery() where wasn't the
default.
Fair enough, and in retrospect it's obvious. However, I fear it
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb?
No, the real-world use-case we're trying to satisfy is hosted and/or
locked-down installatio
Am Freitag, 22. Februar 2008 schrieb Dave Page:
> I know I'm gonna regret wading in on this, but in my mind this is akin
> to one of the arguments for including tsearch in the core server -
> namely that too many brain dead hosting providers won't add a contrib
> module or anything else in a custom
49 matches
Mail list logo
