I'm constantly amazed at the way people get worked up about
X-is-not-there *after* feature freeze. If you wanted it in 8.2,
the time to be throwing resources at the problem was six months ago.
It's not like Oleg and Teodor haven't let it be known that they
could use financing.
I would say tha
Hello
I suggest enhance plpgsq to simultaneous assignment. Main reason is missing
parameter passing by reference and less readable getting values from
functions with OUT parameters.
Currently I have to write SELECT: SELECT INTO a,b,c out3fce(1)
a,b,c := out3fce(1); -- Simultaneous assignmen
-Original Message-
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Greg Sabino Mullane" <[EMAIL PROTECTED]>
Cc: "pgsql-hackers@postgresql.org"
Sent: 07/08/06 04:42
Subject: Re: [HACKERS] 8.2 features status
> I'm constantly amazed at the way people get worked up about
> X-is-not-there *afte
Hello
Package contains package's variables, shared protected functions and
initialisation part, which is executed when any public function attached to
package is called. Every package has defined only one language. The reason
for this is binary compatibility of package's variables. Private fun
Hi,
José Orlando Pereira wrote:
I would argue that people haven't been able to build production-grade
multi-master replication, in part, due to the barrier of not having
a "standard" database-agnostic API. :-)
In fact, the problem is not the lack of a "standard" API but the lack of an
API at
Tom Lane <[EMAIL PROTECTED]> writes:
> I don't think there is very much hope of an in-place upgrade for
> scenarios involving changes in contents of user tables. In particular,
> what of a change that requires more space than before, such as adding a
> locale indicator to text fields? There's no
Pavel Stehule wrote:
Package is similar to schema.
Are you saying that the package would effectively *be* a schema from the
outside. That is, if I have package "foo" then I can't also have a
schema "foo"?
--
Richard Huxton
Archonet Ltd
---(end of broadcast)-
Pavel Stehule wrote:
Package is similar to schema.
Are you saying that the package would effectively *be* a schema from the
outside. That is, if I have package "foo" then I can't also have a schema
"foo"?
Yes, because I don't need duplicity in function's names.
Pavel
__
On Mon, Aug 07, 2006 at 06:05:30AM -0400, Gregory Stark wrote:
> What of having support in the backend for two heap formats in each version.
> That is, 8.3 would be able to support 8.2 heaps as well as 8.3. There could be
> a flag in pg_class indicating the heap format for that heap. Then you would
I've a table that stores hierarchical information in a ltree field for fast
access, indexed with a GiST index.
Interesting Problem with ltree/GiST index: sometimes, the index will get
corrupt, as seen by the examples below:
WRONG
db=# SELECT path from strukturelemente where path ~
'142.2330445
Andrew Dunstan wrote:
Tom Lane wrote:
I see one occurrence in the 8.1 branch on hyena, but the failure
probability seems to have jumped way up in HEAD since we put in the
C-coded pg_regress. This lends weight to the idea that it's a
timing-related issue, because pg_regress.c is presumably mu
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> a,b,c := out3fce(1); -- Simultaneous assignment
I thought we rejected that idea once already, on the grounds that it
would make it too hard to tell the difference between intended code
and typos.
regards, tom lane
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> Are you saying that the package would effectively *be* a schema from the
>> outside. That is, if I have package "foo" then I can't also have a schema
>> "foo"?
> Yes, because I don't need duplicity in function's names.
What if the package needs som
Martijn van Oosterhout writes:
> [ concerning handling a change in a single datatype's representation ]
> 1. Under old system, munge the system catalog to add code for new inet
> type with new OID. Probably needs a shared lib (if you could create
> type input/output function with pl/pgsql it woul
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> a,b,c := out3fce(1); -- Simultaneous assignment
>
> I thought we rejected that idea once already, on the grounds that it
> would make it too hard to tell the difference between intended code
> and typos.
>
In any case, I had some que
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> The invokers of SubTrans module are two SubTransGetTopmostTransaction()
> in HeapTupleSatisfiesSnapshot(). When I disabled the calls, CSStorm did
> not occur. SubTransGetTopmostTransaction returns the argument without
> change when we don't use SAVEPOI
Tom Lane <[EMAIL PROTECTED]> writes:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
>> How many cycles are we talking about here? Is it even worth the GUC?
>
> I think so. On simple queries the optimization will *never* fire,
> and there's no point in doing the search. People who are running
>
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> a,b,c := out3fce(1); -- Simultaneous assignment
I thought we rejected that idea once already, on the grounds that it
would make it too hard to tell the difference between intended code
and typos.
Yes, because wasn't procedures with out params, my
I'm in process of reviewing the restartable-recovery patch,
http://archives.postgresql.org/pgsql-patches/2006-07/msg00356.php
and I'm wondering if we really need to invent a "standby mode" boolean
to get the right behavior. The problem I see with that flag is that
it'd be static over a run, wherea
On Mon, Aug 07, 2006 at 08:37:14AM -0400, Tom Lane wrote:
> Probably easier and more flexible just to include both versions of the
> datatype in the new release, and tell people they'd better ALTER COLUMN
> TYPE sometime before updating to release N+2.
Right, but I wasn't sure if that'd be conside
>> Are you saying that the package would effectively *be* a schema from
the
>> outside. That is, if I have package "foo" then I can't also have a
schema
>> "foo"?
> Yes, because I don't need duplicity in function's names.
What if the package needs some tables associated with it? I think you
n
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> a,b,c := out3fce(1); -- Simultaneous assignment
>
> I thought we rejected that idea once already, on the grounds that it
> would make it too hard to tell the difference between intended code
> and typos.
>
In any case, I had some q
On Mon, Aug 07, 2006 at 04:11:48PM +0200, Pavel Stehule wrote:
> The best of is implementation of CALL statement, where I can transmit
> values "by" references. But it's not possible in Postgres :-(. I can't to
> select unambiguously called procedure. "I can, if I accept SQL Server
> syntax, whe
I got notice of this from a local database reading group:
http://research.aol.com
Looks like the data they are providing is information retrieval oriented
for non-commercial research use only but could potentially be an
interesting data set to test with.
Mark
On Mon, 2006-08-07 at 09:48 -0400, Tom Lane wrote:
> I'm in process of reviewing the restartable-recovery patch,
> http://archives.postgresql.org/pgsql-patches/2006-07/msg00356.php
> and I'm wondering if we really need to invent a "standby mode" boolean
> to get the right behavior. The problem I s
On Sat, 2006-08-05 at 23:59 -0400, Tom Lane wrote:
> I wrote:
> > Rather than expecting user-level scripts to get this corner case
> > right, I suggest that we ought to modify pg_stop_backup and friends
> > so that what they return is the last used byte address of WAL, not
> > the first unused byte
Simon Riggs <[EMAIL PROTECTED]> writes:
> If we are in standby mode, then rather than ending recovery we go into a
> wait loop. We poll for the next file, then sleep for 1000 ms, then poll
> again. When a file arrives we mark a restartpoint each checkpoint.
> We need the standby_mode to signify th
On Fri, 2006-08-04 at 14:40 -0400, Tom Lane wrote:
> I was just looking at Martin Lesser's gripe here:
> http://archives.postgresql.org/pgsql-performance/2006-08/msg00053.php
> about how the planner is not real bright about the filter conditions
> it generates for a simple partitioning layout. In
On Fri, Aug 04, 2006 at 11:57:03AM -0500, Kenneth Marshall wrote:
> On Fri, Aug 04, 2006 at 12:40:36PM -0400, Tom Lane wrote:
> > "Guillaume Smet" <[EMAIL PROTECTED]> writes:
> > > And what about compression of on-disk sorting?
> >
> > That's purely a performance issue, which some people seem to w
On Mon, 2006-08-07 at 11:37 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > If we are in standby mode, then rather than ending recovery we go into a
> > wait loop. We poll for the next file, then sleep for 1000 ms, then poll
> > again. When a file arrives we mark a restartpoint
On Sat, Aug 05, 2006 at 11:31:24AM -0400, Andrew Dunstan wrote:
> Bruce Momjian wrote:
> >The fact is, the existing system worked as it should, though it is often
> >invisible. We didn't get all the features we wanted, but that isn't
> >because the system isn't working.
>
> Thank you Bruce. That
On Fri, Aug 04, 2006 at 09:58:08PM -0400, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > Greg, you are on an utterly wrong track here. Try to look about a bit more
> > broadly.
>
> FWIW, I tend to agree with Greg. This project has gotten to where it is
> with a very loose structure, and I think
On Fri, Aug 04, 2006 at 10:30:26PM -0400, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > As I was saying on #postgresql, the current system works well for a
> > small group of developers. I don't think there is any arguing that.
>
> > However, there is a larger group out ther
the just added new buildfarm member leveret (fedora core5 x86_64) is
building with the recently released Intel C-compiler version 9.1.
It passes all tests on -HEAD but fails on make check in both
REL8_1_STABLE and REL8_0_STABLE.
The logs of the later two branches also contain a very large number of
On Sat, Aug 05, 2006 at 03:55:17PM -0700, Ron Mayer wrote:
> [EMAIL PROTECTED] wrote:
> >Ron Mayer wrote:
> >>>We have not had that many cases where lack of
> >>>communication was a problem.
> >>One could say too much communication was the problem this time.
> >>
> >>I get the impression people imp
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2006-08-05 at 23:59 -0400, Tom Lane wrote:
>> After further thought I desisted from that plan: changing the result
>> convention of existing functions like pg_stop_backup() will break any
>> existing archiving scripts that do get it right. Instead,
Jim C. Nasby wrote:
Going one step further, if that item was in a system that allowed people
to get emails any time status changed then *everyone* who was interested
in that feature would immediately know that help was needed. I fail to
see how that's a bad thing.
Or maybe even more importantl
Reindexing the index also fixes the problem, but regular reindexing cannot be a
solution, since there is still a timeframe where wrong results are returned.
I've made a copy of the index-file when it was broken, after the update and
after reindexing. Is there a tool for getting a human-readable
On Mon, Aug 07, 2006 at 06:05:30AM -0400, Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I don't think there is very much hope of an in-place upgrade for
> > scenarios involving changes in contents of user tables. In particular,
> > what of a change that requires more space tha
Bruce,
The fact is, the existing system worked as it should, though it is often
invisible. We didn't get all the features we wanted, but that isn't
because the system isn't working.
But it's exactly the invisibility of the process which people are
complaining about. If the postgresql novic
On Mon, Aug 07, 2006 at 08:26:17AM -0700, Mark Wong wrote:
> I got notice of this from a local database reading group:
> http://research.aol.com
>
> Looks like the data they are providing is information retrieval oriented
> for non-commercial research use only but could potentially be an
>
Simon Riggs <[EMAIL PROTECTED]> writes:
> I've implemented this for BTree, GIN, GIST using an additional rmgr
> function bool rm_safe_restartpoint(void)
> ...
> "Recovery checkpoints" are now renamed "restartpoints" to avoid
> confusion with checkpoints. So checkpoints occur during normal
> pr
On Sat, Aug 05, 2006 at 08:42:23AM -0400, [EMAIL PROTECTED] wrote:
> On Sat, Aug 05, 2006 at 10:01:30AM +0200, Pavel Stehule wrote:
> > I found maybe interesting article
> > http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0603wasserman2/
>
> That for the article. I had been meani
Jim C. Nasby wrote:
On Mon, Aug 07, 2006 at 08:26:17AM -0700, Mark Wong wrote:
I got notice of this from a local database reading group:
http://research.aol.com
Looks like the data they are providing is information retrieval oriented
for non-commercial research use only but could poten
Martijn van Oosterhout writes:
> Well, you can implement it. After all, the CALL syntax is merely
> syntactic sugar. You could (if you wanted to) do the following:
> CREATE FUNCTION foo( a TEXT IN, b TEXT INOUT, c TEXT OUT ) as blah...
> And in a pl/pgsql function, translate: "CALL foo(a,b,c)"
http://jdigittl.blogspot.com/2006/08/tsk-tsk-aol.html
Mark Wong wrote:
Jim C. Nasby wrote:
On Mon, Aug 07, 2006 at 08:26:17AM -0700, Mark Wong wrote:
I got notice of this from a local database reading group:
http://research.aol.com
Looks like the data they are providing is information ret
Hi,
[ concerning handling a change in a single datatype's representation ]
1. Under old system, munge the system catalog to add code for new inet
type with new OID. Probably needs a shared lib (if you could create
type input/output function with pl/pgsql it would help here).
2. Execute ALTER
Martijn van Oosterhout writes:
> Well, you can implement it. After all, the CALL syntax is merely
> syntactic sugar. You could (if you wanted to) do the following:
> CREATE FUNCTION foo( a TEXT IN, b TEXT INOUT, c TEXT OUT ) as blah...
> And in a pl/pgsql function, translate: "CALL foo(a,b,c)"
On Mon, 2006-08-07 at 16:54 +0100, Simon Riggs wrote:
> On Fri, 2006-08-04 at 14:40 -0400, Tom Lane wrote:
> > I was just looking at Martin Lesser's gripe here:
> > http://archives.postgresql.org/pgsql-performance/2006-08/msg00053.php
> > about how the planner is not real bright about the filter co
Rod Taylor <[EMAIL PROTECTED]> writes:
> A simple way of doing this might be to use a minimum cost number?
But you don't have any cost numbers until after you've done the plan.
regards, tom lane
---(end of broadcast)---
TIP
Oops, wait a bit: problem is founded in gist_between() call.
Fixed in 7.3 - HEAD versions. Thank you for feedback: those bugs can be found
only on high-loaded boxes.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
On Mon, 2006-08-07 at 13:44 -0400, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > A simple way of doing this might be to use a minimum cost number?
>
> But you don't have any cost numbers until after you've done the plan.
Isn't it possible to find the cost using the straight forward
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> *) why the large difference in the build-flags ?
CVS HEAD configure.in knows about icc and the release branches don't.
I think the changes were only put into HEAD because of lack of testing,
but if we have buildfarm coverage I think it'd be OK to
Simon Riggs <[EMAIL PROTECTED]> writes:
> To achieve the "indexed" partition pruning, we'd need
> - a way to specify that all constraints are mutually exclusive
> - a declarative approach for saying something like "arranged in date
> sequence"
> - preferably a way to have this happen at run-time so
On Mon, 7 Aug 2006, Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > *) why the large difference in the build-flags ?
>
> CVS HEAD configure.in knows about icc and the release branches don't.
> I think the changes were only put into HEAD because of lack of testing,
> but if w
On Monday 07 August 2006 10:58, Markus Schiltknecht wrote:
>
> Where do I find the included technical report?
Sorry, stuff was put twice in the zip file making it somewhat confusing. It is
in postgresql-g-0.1/javasrc/GordaInterfaces/docs/gapi.pdf or directly on the
web site at http://gorda.di.um
Jeremy Drake wrote:
On Mon, 7 Aug 2006, Tom Lane wrote:
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
*) why the large difference in the build-flags ?
CVS HEAD configure.in knows about icc and the release branches don't.
I think the changes were only put into HEAD because of
Tom Lane wrote:
> I'm wondering about doing something similar to what
> TransactionIdIsInProgress does, ie, make use of the PGPROC lists
> of live subtransactions. Suppose that GetSnapshotData copies not
> only top xids but live subxids into the snapshot, and adds a flag
> indicating whether the
On Mon, 7 Aug 2006, Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > *) why the large difference in the build-flags ?
>
> CVS HEAD configure.in knows about icc and the release branches don't.
> I think the changes were only put into HEAD because of lack of testing,
> but if w
On Mon, 7 Aug 2006, Stefan Kaltenbrunner wrote:
> the just added new buildfarm member leveret (fedora core5 x86_64) is
> building with the recently released Intel C-compiler version 9.1.
> It passes all tests on -HEAD but fails on make check in both
> REL8_1_STABLE and REL8_0_STABLE.
> The logs of
On Sat, Aug 05, 2006 at 11:59:40PM -0400, Tom Lane wrote:
> I wrote:
> > Rather than expecting user-level scripts to get this corner case
> > right, I suggest that we ought to modify pg_stop_backup and friends
> > so that what they return is the last used byte address of WAL, not
> > the first unus
Jeremy Drake wrote:
> On Mon, 7 Aug 2006, Tom Lane wrote:
>
>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>>> *) why the large difference in the build-flags ?
>> CVS HEAD configure.in knows about icc and the release branches don't.
>> I think the changes were only put into HEAD because of la
On Mon, Aug 07, 2006 at 03:57:05PM +0200, Pavel Stehule wrote:
> >>> Are you saying that the package would effectively *be* a schema from
> >the
> >>> outside. That is, if I have package "foo" then I can't also have a
> >schema
> >>> "foo"?
> >
> >> Yes, because I don't need duplicity in function
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm wondering about doing something similar to what
>> TransactionIdIsInProgress does, ie, make use of the PGPROC lists
>> of live subtransactions.
> Well, that sounds awfully more expensive than setting
> local-to-my-database Xmins a
Zdenek,
> However what happened? I think that following scenarios occurred.
> Postmaster listen only in one process and there are many clients run
> really parallel. T2000 server has 32 threads ( 8 core and each has 4
> threads). These clients generate more TCP/IP request at one time, than
> postm
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Should we ask users if anyone is currently doing this? It seems pretty
> ugly to have most functions return the last used WAL byte with only
> stop_backup returning the first unused byte.
No, you misunderstood. All the functions that return WAL locatio
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I'm wondering about doing something similar to what
> >> TransactionIdIsInProgress does, ie, make use of the PGPROC lists
> >> of live subtransactions.
>
> > Well, that sounds awfully more expensive than setting
Jeremy Drake <[EMAIL PROTECTED]> writes:
> Plus if it is backported, I can enable 8.x builds on mongoose (my x86 icc
> buildfarm box).
Please do --- I've applied the changes in 8.1 and 8.0 branches.
regards, tom lane
---(end of broadcast)--
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I was thinking at what time was the most appropiate to insert or remove
> an Xid from the cache. We can do without any excl-locking because 1) we
> already assume the storing of an Xid to be atomic, and 2) no one can be
> interested in querying for an X
Hello all, hope you are remembering me, some years ago I've designed the
PgAccess , the Tcl/Tk visual interface to PostgreSQL.
Thought you haven't received any news from me, I continued working with
PostgreSQL, being involved in very big projects in Romania.
Right now, the national identificati
Constantin Teodorescu wrote:
EXPLAIN VARIANTS SELECT .. (and so on) that will display the
different query plans analyzed by the planner and their "estimated time
values" , not just the "best guess" .
assuming that the EXPLAIN VARIANTS will show 3 or 4 different query
plans, the database
Tom Lane wrote:
Rod Taylor <[EMAIL PROTECTED]> writes:
A simple way of doing this might be to use a minimum cost number?
But you don't have any cost numbers until after you've done the plan.
Couldn't this work similar to geqo_effort? The planner could
try planning the query using only cheap
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> But you don't have any cost numbers until after you've done the plan.
> Couldn't this work similar to geqo_effort? The planner could
> try planning the query using only cheap algorithmns, and if
> the cost exceeds a certain value,
On Mon, 2006-08-07 at 22:01 -0400, Tom Lane wrote:
> "Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> But you don't have any cost numbers until after you've done the plan.
>
> > Couldn't this work similar to geqo_effort? The planner could
> > try planning the query using onl
This is an additional information.
I wrote:
> If we want to resolve the probmen fundamentally, we might have to
> improve SubTrans using a better buffer management algorithm or so.
The above is maybe wrong. I checked each lwlock of pg_subtrans's buffers.
All lwlocks are uniformly acquired and I c
>
> What is problem? I can attach table or sequence. What can be problem is
> visibility of nesteded objects (if can be different than functions). My
> proposal is only concept, and I my first goal is find way for secure
> storing session's variables and shared native functions, like my sample.
I
Josh Berkus wrote:
> Bruce,
>
> > The fact is, the existing system worked as it should, though it is often
> > invisible. We didn't get all the features we wanted, but that isn't
> > because the system isn't working.
>
> But it's exactly the invisibility of the process which people are
> compla
Joshua D. Drake wrote:
>
> > The fact is, the existing system worked as it should, though it is often
> > invisible. We didn't get all the features we wanted, but that isn't
> > because the system isn't working.
>
> Well that kind of comes back to my point of better communication.
> Perhaps a l
78 matches
Mail list logo
