Re: [HACKERS] 8.5 development schedule

On Wed, Jul 1, 2009 at 1:16 AM, Josh Berkus wrote: > Hmmm ... actually, I think Andrew's right that we don't need a specific > "last commitfest" rule which is special.  Really, any patch which gets > submitted to any commitfest gets returned if it's not ready to be committed > immediately after rev

Re: [HACKERS] 8.5 development schedule

Andrew, I thought we discussed that at pgCon in May and rejected it. That's not what we have in my notes: http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#CommitFests Of course, I may have missed some options, a lot of people were talking. I have very, very serious reservations

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 11:18 PM, Bruce Momjian wrote: > Tom Lane wrote: >> > As for thresholds, I'd propose that we measure the size of patches >> > using "diff -u | diffstat".  If the number of insertions plus the >> > number of deletions is >= 1000, then the patch is not eligible for the >> > fi

Re: [HACKERS] 8.5 development schedule

Tom Lane wrote: > > As for thresholds, I'd propose that we measure the size of patches > > using "diff -u | diffstat". If the number of insertions plus the > > number of deletions is >= 1000, then the patch is not eligible for the > > final CommitFest unless it was submitted for the penultimate >

Re: [HACKERS] 8.5 development schedule

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I'm in agreement that we should try to provide feedback (in general, to > > be honest) on patches/suggestions/ideas/designs/etc as quickly as > > possible. The commitfest approach is good for this when it's "in > > motion", but it

Re: [HACKERS] 8.5 development schedule

Josh Berkus wrote: One thing Peter forgot to mention here is that the next-to-last commitfest is the *last* commitfest for new major features. For the *last* commitfest, any patch introduced either has to be a resubmission of something we've seen at a prior CF, or has to be very "small" (

Re: [HACKERS] 8.5 development schedule

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Yeah. In core's private discussion of this, I too was arguing for >> running a CommitFest ASAP, in order to have some motion on the existing >> patch backlog. I don't know that we'd actually end up committing many, >> but we need

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 9:17 PM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> As I mentioned in the core discussion, I'm a bit concerned that this >> would have the effect of choking off development too soon.  We could >> have a situation where nothing major is supposed to be ge

Re: [HACKERS] 8.5 development schedule

* Tom Lane (t...@sss.pgh.pa.us) wrote: > As I mentioned in the core discussion, I'm a bit concerned that this > would have the effect of choking off development too soon. We could > have a situation where nothing major is supposed to be getting worked > on from Nov 15 to mid-May, which seems much

[HACKERS] [PATCH] SE-PostgreSQL Updates rev.2096

The SE-PostgreSQL patches are updated as follows: 01) http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.4-r2096.patch 02) http://sepgsql.googlecode.com/files/sepgsql-02-core-8.4-r2096.patch 03) http://sepgsql.googlecode.com/files/sepgsql-03-gram-8.4-r2096.patch 04) http://sepgsql.googlecode.

Re: [HACKERS] 8.5 development schedule

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I would like to propose aiming for a release around April/May 2010 ... > "in time for PGCon" if you like, but the main point is to have it out > before people start disappearing for summer break. We've already run > into problems with scheduling the 8.4 rel

Re: [HACKERS] 8.5 development schedule

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > What I think we have is a lot of people who are waiting > > for feedback, and we should try to give them some. I also know that > > reviewing 60 patches for the November CommitFest was a ton of work, > > and the reviewers (including

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Tue, Jun 30, 2009 at 03:16:09PM -0700, David Wheeler wrote: > On Jun 30, 2009, at 3:05 PM, David Fetter wrote: > Would this be the first C piece? If not, it might be worth doing. >>> >>> I don't understand the question. >> >> I was thinking of this as part of PgTAP. > > Oh. There is

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 3:05 PM, David Fetter wrote: Would this be the first C piece? If not, it might be worth doing. I don't understand the question. I was thinking of this as part of PgTAP. Oh. There is a piece of C, but it's just an implementation of pg_typeof() so that pgTAP can use it

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Tue, Jun 30, 2009 at 02:01:26PM -0700, David Wheeler wrote: > On Jun 30, 2009, at 1:40 PM, David Fetter wrote: > >>> Yes, that's my ideal, but Tom says I need to write C code to get that >>> information from RECORD objects, alas. :-( >> >> Would this be the first C piece? If not, it might be wo

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 1:40 PM, David Fetter wrote: Yes, that's my ideal, but Tom says I need to write C code to get that information from RECORD objects, alas. :-( Would this be the first C piece? If not, it might be worth doing. I don't understand the question. But yes, I think it'd be worth

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Tue, Jun 30, 2009 at 01:10:01PM -0700, David Wheeler wrote: > On Jun 30, 2009, at 11:54 AM, David Fetter wrote: > >>># Failed test 148 >>># Number of columns differs between queries >>># have: 4 columns >>># want: 3 columns >> >> Shouldn't that just read: >> >

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 11:54 AM, David Fetter wrote: # Failed test 148 # Number of columns differs between queries # have: 4 columns # want: 3 columns Shouldn't that just read: have: (int, int, text, point) want: (int, int, text) Yes, that's my ideal, but

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 11:48 AM, Tom Lane wrote: Is there a way to get a RECORD object to tell me what data types it contains? Not at the SQL level. Of course, if you're writing C, you can do something similar to what record_eq and friends do. Pity. I'm trying to keep C out of pgTAP (for the m

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 11:46 AM, Tom Lane wrote: For my results_eq() in pgTAP, it could output different diagnostics. Well, that's not terribly compelling ;-). Pllt. I wouldn't have any big objection to splitting out ERRCODE_COLUMN_COUNT_MISMATCH as a separate SQLSTATE for 8.5 and beyond,

Re: [HACKERS] Multi-Dimensional Histograms

> I'm finding myself unable to follow all the terminology on this thead. >  What's dimension reduction?  What's PCA? ( Sorry for the jargon - thanks Josh ) > It feels like what you might need is statistics for colB (MCVs and/or a > histogram) for certain particular values of colA. Certainly - th

Re: [HACKERS] 8.5 development schedule

Kevin Grittner wrote: Tom Lane wrote: I think we used to do it more or less like that, but people didn't like it because they couldn't do any long-range planning. Well, obviously the 8.4 release cycle did little to help them. As has already been observed, there is a crying need to say "no

Re: [HACKERS] 8.5 development schedule

Josh Berkus writes: > One thing Peter forgot to mention here is that the next-to-last > commitfest is the *last* commitfest for new major features. For the > *last* commitfest, any patch introduced either has to be a resubmission > of something we've seen at a prior CF, or has to be very "smal

Re: [HACKERS] 8.5 development schedule

Josh Berkus writes: >> I would propose to start CommitFests July 15th, September 15th, >> November 15th, and January 15th, planning all but the last to be one >> month long. The last CommitFest I would plan on closing up by March >> 1st, with release hopefully by June 1st. > This sounds good to

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Tue, Jun 30, 2009 at 11:27:20AM -0700, David Wheeler wrote: > On Jun 30, 2009, at 11:18 AM, Tom Lane wrote: > >> So really what you're wishing for is that we treat different-numbers- >> of- >> columns as a whole new SQLSTATE inside category 42. What's the >> argument >> for needing to handle

Re: [HACKERS] Inconsistent Errors on Row Comparisons

"David E. Wheeler" writes: > Is there a way > to get a RECORD object to tell me what data types it contains? Not at the SQL level. Of course, if you're writing C, you can do something similar to what record_eq and friends do. regards, tom lane -- Sent via pgsql-hacke

Re: [HACKERS] Inconsistent Errors on Row Comparisons

"David E. Wheeler" writes: > On Jun 30, 2009, at 11:18 AM, Tom Lane wrote: >> What's the argument >> for needing to handle this differently from DATATYPE_MISMATCH? > For my results_eq() in pgTAP, it could output different diagnostics. Well, that's not terribly compelling ;-). I wouldn't have

Re: [HACKERS] 8.5 development schedule

On 6/29/09 10:33 PM, Peter Eisentraut wrote: Now that 8.4.0 is out the door, development for 8.5devel will be opened any day now. But we haven't discussed the development timeline so far. The core team has several proposals: CommitFest Alpha Aug. 1 Sept. 1 Oct. 1 Nov. 1

Re: [HACKERS] 8.5 development schedule

I would propose to start CommitFests July 15th, September 15th, November 15th, and January 15th, planning all but the last to be one month long. The last CommitFest I would plan on closing up by March 1st, with release hopefully by June 1st. This sounds good to me. Anyone object? As for th

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 11:27 AM, David E. Wheeler wrote: # Failed test 148 # Number of columns differs between queries # have: 4 columns # want: 3 columns # Failed test 149 # Column types differ between queries # have: (integer,text) #

Re: [HACKERS] 8.5 development schedule

Kevin Grittner wrote: > It might actually help to do that on big patches if we don't let too > many tiny ones accumulate. I seem to remember the argument being tossed > about that "we might as well keep working on this one because there's > all these others to wrap up." Yeah, and the people who

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 11:18 AM, Tom Lane wrote: So really what you're wishing for is that we treat different-numbers- of- columns as a whole new SQLSTATE inside category 42. What's the argument for needing to handle this differently from DATATYPE_MISMATCH? For my results_eq() in pgTAP, it co

Re: [HACKERS] Inconsistent Errors on Row Comparisons

"David E. Wheeler" writes: > Yeah, that was just an aside. I liked that I got different errors when > there were different numbers of columns than when the data types of > the columns disagreed. I'm not sure that SYNTAX ERROR is a great code > for when the count disagrees, but at least it's

Re: [HACKERS] Inconsistent Errors on Row Comparisons

]On Jun 30, 2009, at 11:00 AM, Tom Lane wrote: Oh, you're complaining about the SQLSTATE not the error text. I guess that to the extent that any actual thought went into it (which may not have been much) the reasoning was that you'd have to change the syntax of your query in order to fix this.

Re: [HACKERS] 8.5 development schedule

Merlin Moncure wrote: > Given that there is also a lot of work on synchronous replication, is > it better to get the HS in so the SR stuff can use that as a baseline, > or to triage in both patches together? Whichever finishes first. Although they're very useful together, there is little if any co

Re: [HACKERS] Inconsistent Errors on Row Comparisons

"David E. Wheeler" writes: > On Jun 30, 2009, at 10:28 AM, Tom Lane wrote: >> Not for me: >> >> regression=# VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3); >> ERROR: each EXCEPT query must have the same number of columns > Turn on verbosity: > try=# \set VERBOSITY verbose > try=# VALUES (1, 2),

Re: [HACKERS] 8.5 development schedule

Robert Haas wrote: > In any case, we probably need some weigh-in from Heikki and Simon on > their plans for Hot Standby before we make any decisions... I'm planning to spend considerable amount of time reviewing and helping with hot standby and synchronous replication, but someone else will have t

Re: [HACKERS] 8.5 development schedule

Tom Lane wrote: > I think we used to do it more or less like that, but people > didn't like it because they couldn't do any long-range planning. Well, obviously the 8.4 release cycle did little to help them. As has already been observed, there is a crying need to say "no" at some point to ge

Re: [HACKERS] foreign.h is not installed

Itagaki Takahiro writes: > Header file "include/foreign/foreign.h" is not installed in 8.4.0. > Did we forget to add subdir "foreign" to Makefile? Applied, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 10:28 AM, Tom Lane wrote: VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3); Throws 42601 SYNTAX ERROR. Not for me: regression=# VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3); ERROR: each EXCEPT query must have the same number of columns Turn on verbosity: try=# \set

Re: [HACKERS] Inconsistent Errors on Row Comparisons

"David E. Wheeler" writes: > This is what I see. This query: > VALUES (1, 2), (3, 4) EXCEPT VALUES (1, 'foo'), (3, 'bar'); > Throws 42804 DATATYPE MISMATCH. Yeah ... > Meanwhile, this query: > VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3); > Throws 42601 SYNTAX ERROR. Not for me:

Re: [HACKERS] 8.5 development schedule

Robert Haas writes: > I agree. On the other hand, I think all of the proposed schedules are > somewhat optimistic about how long the final release will take. We > started the final CommitFest for 8.4 on November 1st and are set to > release July 1st. The proposed schedule for next time involves

[HACKERS] Inconsistent Errors on Row Comparisons

Howdy, I'm working on functions to compare result sets for pgTAP. In the process, I found what appears to be an inconsistency in error handling when comparing incomparable results. I'm testing in 8.4RC2, but the issue may go back for all I know. Perhaps it's intentional? This is what I se

Re: [HACKERS] 8.5 development schedule

"Joshua D. Drake" writes: > We already push and pull our release dates based are what in the queue, > we just do so informally. Why not just make it part of the process? That > way we are being up front and saying, "Yeah, we have no idea. We will > review in 6 months and that is when we decide our

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 12:37 PM, Tom Lane wrote: > "Joshua D. Drake" writes: >> On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote: >>> I would like to propose aiming for a release around April/May 2010 ... >>> "in time for PGCon" if you like, but the main point is to have it out >>> before people

Re: [HACKERS] 8.5 development schedule

On Tue, 2009-06-30 at 12:37 -0400, Tom Lane wrote: > > We are not a company. We don't have a deadline. Why can't we just > > develop and say, "Yeah, this looks like it would make a substantive > > release."? > > Well, then you might as well not have a schedule at all. The point of > setting up a

Re: [HACKERS] dependencies for generated header files

Robert Haas escribió: > Woops. It seems that patch generates some warnings on a vpath build > which I failed to notice. Corrected version that guards against same > is attached. Interestingly, this patch causes diffstat (at least my version of it) to attribute the line additions to src/backend/

Re: [HACKERS] 8.5 development schedule

"Joshua D. Drake" writes: > On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote: >> I would like to propose aiming for a release around April/May 2010 ... >> "in time for PGCon" if you like, but the main point is to have it out >> before people start disappearing for summer break. We've already run

Re: [HACKERS] 8.5 development schedule

On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > Now that 8.4.0 is out the door, development for 8.5devel will be opened any > > day now. But we haven't discussed the development timeline so far. The > > core > > team has several proposals: > > [ details snippe

Re: [HACKERS] 8.5 development schedule

On Tue, 2009-06-30 at 12:11 -0400, Tom Lane wrote: > I'm also not prepared to push a large and unstable feature into the tree > on the hope that it will get fixed. The general consensus among -core, > and I think most of -hackers as well, is that we want to try to keep CVS > HEAD pretty stable, s

Re: [HACKERS] 8.5 development schedule

Peter Eisentraut writes: > Now that 8.4.0 is out the door, development for 8.5devel will be opened any > day now. But we haven't discussed the development timeline so far. The core > team has several proposals: > [ details snipped ] ISTM there are two critical decisions here: when's the first

Re: [HACKERS] 8.5 development schedule

Greg Stark writes: > I would like to propose a different strategy. Instead of always > tackling all the smaller patches and leaving the big patches for last, > I would suggest we start with Hot Standby. > In fact I would suggest as Hot Standby has already gotten a first pass > review that we cons

Re: [HACKERS] 8.5 development schedule

Robert Haas writes: > What I think we have is a lot of people who are waiting > for feedback, and we should try to give them some. I also know that > reviewing 60 patches for the November CommitFest was a ton of work, > and the reviewers (including the committers) ran out of steam well > before w

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 10:11 AM, Peter Eisentraut wrote: > On Tuesday 30 June 2009 16:50:55 Kevin Grittner wrote: >> > However, if anything, I think if anything we should go the other way >> > and start the first CommitFest July 15th. >> >> I'm curious what the counter-arguments to this are.  Is i

Re: [HACKERS] 8.5 development schedule

Peter Eisentraut wrote: > Well, think about what could happen if we go this way. What you > basically have here are people who have essentially ignored the > commitfest and beta mandates and worked on new patches. And they > now get to say, because we already have enough patches, let's start

Re: [HACKERS] 8.5 development schedule

Hi, >> However, if anything, I think if anything we should go the other way >> and start the first CommitFest July 15th. > > I'm curious what the counter-arguments to this are.  Is it > review-fatigue from getting the release out, or is there an economy of > scale to building up a 100 patches bef

Re: [HACKERS] 8.5 development schedule

On Tuesday 30 June 2009 16:50:55 Kevin Grittner wrote: > > However, if anything, I think if anything we should go the other way > > and start the first CommitFest July 15th. > > I'm curious what the counter-arguments to this are. Is it > review-fatigue from getting the release out, or is there an

Re: [HACKERS] 8.5 development schedule

Robert Haas wrote: > Waiting until September for the first CommitFest seems like a really > bad idea. We already have almost 40 patches on the wiki page, and > there are some that haven't been added yet: I suspect we will have > over 50 in another week, and maybe closer to 60. If we wait two

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 8:12 AM, Greg Stark wrote: > On Tue, Jun 30, 2009 at 1:04 PM, Robert Haas wrote: >> If Hot Standby were ready to be applied, I would be all in favor of >> that, but in fact I don't believe that's the case.  There's been no >> movement on Hot Standby since February > > Well S

Re: [HACKERS] use of pg_stat_database

On Tue, Jun 30, 2009 at 7:13 AM, abdelhak benmohamed wrote: > Hellow, > > > > I like to track the number of committed transaction for my database > > So I use the following command > > Select * from pg_stat_database; > > > > The column xact_commit gives me the number of transaction committed > > >

Re: [HACKERS] pre-proposal: permissions made easier

* Andrew Dunstan [090630 09:08]: > > > Aidan Van Dyk wrote: >> >> *especially* if those grants remain "by reference", i.e. If I change the >> GRANTS/REVOKES on sensitive_table, those are automatically "apply" to all >> tables created with the "WITH GRANTS LIKE sensitive_table"... >> >> >> > > I

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 8:12 AM, Greg Stark wrote: > On Tue, Jun 30, 2009 at 1:04 PM, Robert Haas wrote: >> If Hot Standby were ready to be applied, I would be all in favor of >> that, but in fact I don't believe that's the case.  There's been no >> movement on Hot Standby since February > > Well S

Re: [HACKERS] pre-proposal: permissions made easier

Aidan Van Dyk wrote: *especially* if those grants remain "by reference", i.e. If I change the GRANTS/REVOKES on sensitive_table, those are automatically "apply" to all tables created with the "WITH GRANTS LIKE sensitive_table"... Isn't that exactly what Tom is objecting to, namely that

Re: [HACKERS] pre-proposal: permissions made easier

* Greg Stark [090630 00:18]: > Perhaps tieing it to the schema is wrong and we should actually > require the user to specify the template they want explicitly which > would be even better for that. So it would be something like "WITH > GRANTS LIKE sensitive_table". And, not having any experienc

Re: [HACKERS] How to register my function into backend?

Oh. Thanks for your instruction! Best regards. Bruce 2009/6/30 Robert Haas > On Mon, Jun 29, 2009 at 4:53 AM, Bruce YUAN wrote:rsd > > My function is to collect some backend information for user anlysis. > > How to register my function into backend? It make that we can called it > via > > libpg/

Re: [HACKERS] Hello to all postgresql developers :)

Sergej Galkin writes: > I am Oracle developer for 2 years, and I have a magister work - to realize TPR > index on RDBMS :) I desided to realize TPR index on PostgreSql RDBMS. I am > really new programmer in C language. I don't know what a TPR index is, but it could be that the following material

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 1:04 PM, Robert Haas wrote: > If Hot Standby were ready to be applied, I would be all in favor of > that, but in fact I don't believe that's the case.  There's been no > movement on Hot Standby since February Well Simon was happy with it as submitted so unless people are re

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 7:53 AM, Greg Stark wrote: > On Tue, Jun 30, 2009 at 12:22 PM, Robert Haas wrote: >> Waiting until September for the first CommitFest seems like a really >> bad idea.   We already have almost 40 patches on the wiki page, and >> there are some that haven't been added yet: I s

Re: [HACKERS] question about meaning of character varying without length

Konstantin Izmailov wrote: Delivery to the following recipient failed permanently: pgsql-gene...@postgresql.com should be pgsql-gene...@postgresql.org, not pgsql-gene...@postgresql.com. cheers andrew -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 12:22 PM, Robert Haas wrote: > Waiting until September for the first CommitFest seems like a really > bad idea.   We already have almost 40 patches on the wiki page, and > there are some that haven't been added yet: I suspect we will have > over 50 in another week, and maybe

Re: [HACKERS] use of pg_stat_database

In response to abdelhak benmohamed : > Hellow, > > > > I like to track the number of committed transaction for my database > > So I use the following command > > Select * from pg_stat_database; > > > > The column xact_commit gives me the number of transaction committed > > > > But if

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 1:33 AM, Peter Eisentraut wrote: > Now that 8.4.0 is out the door, development for 8.5devel will be opened any > day now.  But we haven't discussed the development timeline so far.  The core > team has several proposals: > > CommitFest      Alpha > Aug. 1          Sept. 1 >

[HACKERS] use of pg_stat_database

Hellow,   I like to track the number of committed transaction for my database So I use the following command Select * from pg_stat_database;   The column xact_commit gives me the number of transaction committed   But if I execute the same command another time, the column xact_commit gives me an o

Re: [HACKERS] [PATCH] user mapping extension to pg_ident.conf

> # MAPNAME SYSTEM-USERNAMEPG-USERNAME EFFECTIVE-USERNAME > gssapi-user/^(.*)@domain\.com$simple-role \1 > gssapi-user/^use...@domain\.com$ super-roleuser_a > gssapi-user/^use...@domain\.com$ super-roleuser_c My fault. The lower lines should be: gssapi-us

Re: [HACKERS] [PATCH] user mapping extension to pg_ident.conf

Am Montag, 29. Juni 2009 18:12:13 schrieben Sie: > Lars Kanis writes: > > The problem I have, is that I want to use an ordinary windows > > application, which connects to an arbitrary ODBC data source. This > > application stores a fixed username und password for the connection > > within it's own

Re: [HACKERS] Query progress indication - an implementation

On Mon, 2009-06-29 at 18:49 -0400, Tom Lane wrote: > Simon Riggs writes: > > On Mon, 2009-06-29 at 14:07 -0400, Tom Lane wrote: > >> I think this is pretty much nonsense --- most queries run all their plan > >> nodes concurrently to some extent. You can't usefully say that a query > >> is "on" s

Re: [HACKERS] Query progress indication - an implementation

On Tue, 2009-06-30 at 07:04 +0200, Dimitri Fontaine wrote: > Le 30 juin 2009 à 01:34, Greg Stark a écrit : > > Basically I disagree that imperfect progress reports annoy users. I > > think we can do better than reporting 250% done or having a percentage > > that goes backward though. It would be

Re: [HACKERS] Hello to all postgresql developers :)

On Tuesday 30 June 2009 10:06:49 Sergej Galkin wrote: > Hello, > I am Oracle developer for 2 years, and I have a magister work - to realize > TPR index on RDBMS :) I desided to realize TPR index on PostgreSql RDBMS. I > am really new programmer in C language. > what I done > 1 Installed Xubuntu on

Re: [HACKERS] [PATCH] [v8.5] Security checks on largeobjects

I concluded that the following issues should be solved when we apply largeobject-like interfaces on the big toasted data within general relations, not only pg_largeobject system catalog. At first, we need to add a new strategy to store the given varlena data on the external toast relation. If we t

[HACKERS] [PATCH v3] Avoid manual shift-and-test logic in AllocSetFreeIndex

Move the shift-and-test login into a separate fls() function, which can use __builtin_clz() if it's available. This requires a new check for __builtin_clz in the configure script. Results in a ~2% performance increase on PowerPC. Signed-off-by: Jeremy Kerr --- v3: respin as context diff ---

[HACKERS] Hello to all postgresql developers :)

Hello, I am Oracle developer for 2 years, and I have a magister work - to realize TPR index on RDBMS :) I desided to realize TPR index on PostgreSql RDBMS. I am really new programmer in C language. what I done 1 Installed Xubuntu on my computer. 2 build and installed PostgreSql. 3 Installed Anjuta