Re: [HACKERS] Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.

Simon Riggs wrote: > On Sat, 2010-01-23 at 21:40 +, Greg Stark wrote: >> On Sat, Jan 23, 2010 at 8:28 PM, Simon Riggs wrote: >>> What is your proposed way of handling buffer pin deadlocks? That will be >>> acceptable and working to some extent in the next week? >>> >>> Wait forever isn't alway

Re: [HACKERS] default_language

2010/1/25 Peter Eisentraut : > On mån, 2010-01-25 at 08:09 +0100, Pavel Stehule wrote: >> 2010/1/25 Peter Eisentraut : >> > On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote: >> >> Why do we have a parameter called "default_do_language" when we don't >> >> have a parameter called "default_langua

Re: [HACKERS] default_language

On mån, 2010-01-25 at 08:09 +0100, Pavel Stehule wrote: > 2010/1/25 Peter Eisentraut : > > On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote: > >> Why do we have a parameter called "default_do_language" when we don't > >> have a parameter called "default_language"? > > > > According to the SQL s

Re: [HACKERS] default_language

2010/1/25 Peter Eisentraut : > On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote: >> Why do we have a parameter called "default_do_language" when we don't >> have a parameter called "default_language"? > > According to the SQL standard, the default language for CREATE FUNCTION > is SQL.  Should

Re: [HACKERS] default_language

On sön, 2010-01-24 at 20:32 +, Simon Riggs wrote: > Why do we have a parameter called "default_do_language" when we don't > have a parameter called "default_language"? According to the SQL standard, the default language for CREATE FUNCTION is SQL. Should we implement that? -- Sent via pgsq

Re: [HACKERS] Streaming Replication on win32

Tom Lane wrote: > Magnus Hagander writes: >> 2010/1/24 Joe Conway : >>> Sorry for being thick -- I'm still missing something. I don't understand >>> why any user program using libpq/PQexec running on Windows does not have >>> the same issue. Or to put it another way, why does this only apply to >>

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

(2010/01/25 14:08), Robert Haas wrote: > 2010/1/24 KaiGai Kohei: >> It seems to me the result is different from Bernd's report. > > Well, you tested something different, so you got a different answer. > Your case doesn't have any multiple inheritance. If it tries ALTER TABLE xxx RENAME TO on any

Re: [HACKERS] Review: listagg aggregate

I don't think. When we have function, with same parameters, same behave like some Oracle function, then I am strongly prefer Oracle name. I don't see any benefit from different name. It can only confuse developers and add the trable to people who porting applications. Meh. If the name is terri

Re: [HACKERS] Mammoth in Core?

Tom Lane wrote: > It's going to be a really, really, *really* hard sell to get us to > export any sort of external API to the parser internals. At least > if by "API" you mean something other than "we will whack this around > to an indefinite degree on no notice, and don't even think about > co

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

2010/1/24 KaiGai Kohei : > It seems to me the result is different from Bernd's report. Well, you tested something different, so you got a different answer. Your case doesn't have any multiple inheritance. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

Re: [HACKERS] Mammoth in Core?

Takahiro Itagaki writes: > Tatsuo Ishii wrote: >> For example, see below from above URL: This means that we expect >> PostgreSQL exports it's parser so that existing cluster softwares can >> use it. Not opposite direction. > I think they says the same practically -- at least have the same impact

Re: [HACKERS] Mammoth in Core?

Tatsuo Ishii wrote: > "splitting existing projects into some 'modules', and getting the > modules one by one into core" was not the concluion, actually. > > For example, see below from above URL: This means that we expect > PostgreSQL exports it's parser so that existing cluster softwares can >

Re: [HACKERS] RADIUS authentication

(2010/01/24 23:29), Magnus Hagander wrote: > 2010/1/20 KaiGai Kohei: >> (2010/01/20 0:19), Magnus Hagander wrote: * I think this comment is right. + for (i = 0; iv

Re: [HACKERS] Mammoth in Core?

> On 1/19/10 9:28 AM, Greg Smith wrote: > > Takahiro Itagaki wrote: > >> The conclusion is splitting existing projects into some 'modules', > >> and getting the modules one by one into core. Voted features are here: > >> http://wiki.postgresql.org/wiki/ClusterFeatures "splitting existing projects

Re: [HACKERS] commit fests

> Greg Stark wrote: >> Tom Lane wrote: >> What I think we really need for beta, and could reasonably hope to >> get, is a larger and better-organized beta testing effort. But we >> are not going to get that if people are thinking about new >> development and commit fests instead of testing what

Re: [HACKERS] Mammoth in Core?

On 1/19/10 9:28 AM, Greg Smith wrote: > Takahiro Itagaki wrote: >> The conclusion is splitting existing projects into some 'modules', >> and getting the modules one by one into core. Voted features are here: >> http://wiki.postgresql.org/wiki/ClusterFeatures >> > This page was a bit messy for so

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

(2010/01/25 8:45), KaiGai Kohei wrote: > (2010/01/25 4:01), Bernd Helmle wrote: >> >> >> --On 24. Januar 2010 19:45:33 +0100 Bernd Helmle >> wrote: >> >>> I don't see where this should be related to the number of tables not >>> part of the inheritance tree (or inheritance at all). >> >> To answer t

[HACKERS] Syntax supplements for SET options

I found a couple of incomplete syntax when I was adjusting psql automatic tab completion for HEAD. 1. We cannot specify tablespace options on "CREATE TABLESPACE" though "ALTER TABLESPACE" supports generic options by SET (...). 2. Should we still support "ALTER COLUMN SET STATISTICS" though

Re: [HACKERS] default_language

On Sun, 2010-01-24 at 23:59 +, Greg Stark wrote: > On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs wrote: > > I would prefer having the option, but removing it completely does at > > least solve the bizarre inconsistency I've highlighted. > > > > I don't see it as much of an inconsistency. The

Re: [HACKERS] commit fests

Dimitri Fontaine wrote: > And there's already pgfouine to get the scenarios from the logs and > tsung to act as a recording proxy: > http://pgfouine.projects.postgresql.org/tsung.html > http://tsung.erlang-projects.org/user_manual.html#htoc34 > > So maybe it would be a good idea to have dtester

Re: [HACKERS] MySQL-ism help patch for psql

Hi Cédric, On Sun, Jan 24, 2010 at 5:11 PM, Cédric Villemain wrote: > 'psql --help mysql' (or 'psql --tips mysql' ) might be good to call a > special helper : I don't see the point to introduce that kind of > things when it is useless for most of our users. I think it's good to go beyond what's

Re: [HACKERS] default_language

Greg Stark wrote: On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs wrote: I would prefer having the option, but removing it completely does at least solve the bizarre inconsistency I've highlighted. I don't see it as much of an inconsistency. The whole point of DO is to be convenient,

Re: [HACKERS] default_language

On Sun, Jan 24, 2010 at 11:18 PM, Simon Riggs wrote: > I would prefer having the option, but removing it completely does at > least solve the bizarre inconsistency I've highlighted. > I don't see it as much of an inconsistency. The whole point of DO is to be convenient, whereas CREATE FUNCTION is

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

(2010/01/25 4:01), Bernd Helmle wrote: > > > --On 24. Januar 2010 19:45:33 +0100 Bernd Helmle > wrote: > >> I don't see where this should be related to the number of tables not >> part of the inheritance tree (or inheritance at all). > > To answer that myself: it seems get_attname() introduce

Re: [HACKERS] default_language

On Sun, 2010-01-24 at 17:04 -0500, Tom Lane wrote: > > If we have a default (for DO and CREATE FUNCTION), why not hard-wire the > > default to plpgsql? > > I don't see any strong argument for having a default for CREATE > FUNCTION. The original argument for having a GUC for DO was that > plpgsql

Re: [HACKERS] Streaming Replication on win32

Magnus Hagander writes: > 2010/1/24 Joe Conway : >> Sorry for being thick -- I'm still missing something. I don't understand >> why any user program using libpq/PQexec running on Windows does not have >> the same issue. Or to put it another way, why does this only apply to >> libpq calls from back

Re: [HACKERS] Streaming Replication on win32

2010/1/24 Joe Conway : > On 01/21/2010 11:19 PM, Heikki Linnakangas wrote: >> Joe Conway wrote: >>> OK, so now I see why we want this fixed for dblink and walreceiver, but >>> doesn't this approach leave every other WIN32 libpq client out in the >>> cold? Is there nothing that can be done for the g

Re: [HACKERS] Streaming Replication on win32

On 01/21/2010 11:19 PM, Heikki Linnakangas wrote: > Joe Conway wrote: >> OK, so now I see why we want this fixed for dblink and walreceiver, but >> doesn't this approach leave every other WIN32 libpq client out in the >> cold? Is there nothing that can be done for the general case, or is it a >> SM

Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL

I wrote: I don't actually have a horse in this race, I can live with either name. In the interests of full disclosure, I should point out that I in fact do have a horse in the race, although I wasn't thinking of it when I wrote the above. As an officer in a corporation with "PostgreSQL" in

Re: [HACKERS] MySQL-ism help patch for psql

2010/1/24 Baron Schwartz : > David Fetter just pointed this thread out to me.  I think anything > that makes PostgreSQL more accessible could be a good thing.  In some > sense it's harder to learn a technology when you are very familiar > with another similar one already.  Is it easier to learn to

Re: [HACKERS] default_language

On Jan 24, 2010, at 2:04 PM, Tom Lane wrote: > I don't see any strong argument for having a default for CREATE > FUNCTION. The original argument for having a GUC for DO was that > plpgsql wasn't built in; now that it is, I think a case could > be made for dropping default_do_language in favor of

Re: [HACKERS] default_language

Jeff Davis writes: > I would actually lean the other way and say that we shouldn't be > introducing behavior-changing GUCs (except for the special case of > supporting legacy behavior, like standard_conforming_strings). Yeah --- GUCs that affect semantics (as opposed to performance) of SQL constr

Re: [HACKERS] further explain changes

Robert Haas writes: > Care to suggest a format? As much like the sort case as possible ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] default_language

Simon Riggs writes: > Please can we have "default_language"? That sounds like something I could want to use someday. > Or "language_path" so we can tell > CREATE FUNCTION to try the languages in order? Or better still, try all > the installed languages that the user has rights to in alphabetic

Re: [HACKERS] default_language

On Sun, 2010-01-24 at 20:32 +, Simon Riggs wrote: > Or "language_path" so we can tell > CREATE FUNCTION to try the languages in order? Or better still, try all > the installed languages that the user has rights to in alphabetic > order? What do you mean "try"? It seems a little dangerous to j

Re: [HACKERS] further explain changes

On Sun, Jan 24, 2010 at 12:30 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova >>> why not let it go in ANALYZE, just as the sort info > >> It's kinda long-winded - it adds like 4 extra lines for each hash >> join.  I don't think I want to add that muc

[HACKERS] default_language

Why do we have a parameter called "default_do_language" when we don't have a parameter called "default_language"? This is remarkably inconsistent. Why the difference? 5 years from now, whatever reason we had will seem just strange. Please can we have "default_language"? Or "language_path" so we

Re: [HACKERS] tab completion for prepared transactions?

Bruce Momjian wrote: > Heikki Linnakangas wrote: >> Bruce Momjian wrote: >>> Heikki Linnakangas wrote: Right, I vaguely recall that the idea of tab-completion for those commands was rejected when 2PC was added because of that. A user sitting at a psql terminal is not supposed to prep

Re: [HACKERS] MySQL-ism help patch for psql

David Fetter just pointed this thread out to me. I think anything that makes PostgreSQL more accessible could be a good thing. In some sense it's harder to learn a technology when you are very familiar with another similar one already. Is it easier to learn to type on Dvorak, or to learn QWERTY

Re: [HACKERS] tab completion for prepared transactions?

Peter Eisentraut wrote: > What is the > difference between a transaction manager and an application that opens > multiple connections and does PREPARE + COMMIT PREPARED across them? It's what happens if your application crashes after issuing the PREPARE. A correctly configured transaction manager

Re: [HACKERS] commit fests

"Kevin Grittner" writes: > Andrew Dunstan wrote: > >> As for getting more coverage of Beta, part of my trouble in >> testing applications on Beta is that there aren't good tools I >> know of for capture and replay of usage scenarios. Now there would >> be a good project for someone, and it wou

Re: [HACKERS] tab completion for prepared transactions?

Tom Lane wrote: > Heikki Linnakangas writes: >> Hmm, that's a good point though. Maybe it would make sense to add tab >> completion for ROLLBACK/COMMIT PREPARED, but not for PREPARE TRANSACTION? > > Huh? PREPARE TRANSACTION creates a new gxid, so there's nothing for it > to complete against. We

Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL

Robert Treat wrote: On Saturday 23 January 2010 16:19:11 Andrew Dunstan wrote: Robert Treat wrote: I'm not saying there aren't downsides, but having a name the community can unify on is a definite plus, and imho that name has to be Postgres. Translation: "we'll only be unified

Re: [HACKERS] tab completion for prepared transactions?

On sön, 2010-01-24 at 19:43 +0200, Heikki Linnakangas wrote: > "PREPARE TRANSACTION is not intended for use in applications or in > interactive sessions. It's purpose is to allow an external transaction > manager to perform atomic global transactions across multiple > databases > or other transacti

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

On Sun, Jan 24, 2010 at 2:01 PM, Bernd Helmle wrote: > --On 24. Januar 2010 19:45:33 +0100 Bernd Helmle > wrote: >>  I don't see where this should be related to the number of tables not >> part of the inheritance tree (or inheritance at all). > To answer that myself: it seems get_attname() introd

Re: [HACKERS] Resetting a single statistics counter

2010/1/24 Euler Taveira de Oliveira : > Tom Lane escreveu: >> That implies that the operations wouldn't work against system tables; >> which they do.  I think a bigger problem is that "reset_single_table" >> seems like it might be talking about something like a TRUNCATE, ie, >> it's not clear that

Re: [HACKERS] 8.5 vs. 9.0, Postgres vs. PostgreSQL

On Saturday 23 January 2010 16:19:11 Andrew Dunstan wrote: > Robert Treat wrote: > > I'm not saying there aren't > > downsides, but having a name the community can unify on is a definite > > plus, and imho that name has to be Postgres. > > Translation: "we'll only be unified if everyone agrees with

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

--On 24. Januar 2010 19:45:33 +0100 Bernd Helmle wrote: I don't see where this should be related to the number of tables not part of the inheritance tree (or inheritance at all). To answer that myself: it seems get_attname() introduces the overhead here (forgot about that). Creating add

Re: [HACKERS] Resetting a single statistics counter

Tom Lane escreveu: > That implies that the operations wouldn't work against system tables; > which they do. I think a bigger problem is that "reset_single_table" > seems like it might be talking about something like a TRUNCATE, ie, > it's not clear that it means to reset counters rather than data.

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

--On 24. Januar 2010 13:23:14 -0500 Tom Lane wrote: I think my concern about the original proposal was that the time to perform an ALTER RENAME would increase with the number of tables in the database, even if they were entirely unrelated to the one you're trying to rename. Uhm, find_column

Re: [HACKERS] Review: listagg aggregate

2010/1/24 David E. Wheeler : > On Jan 24, 2010, at 1:19 AM, Pavel Stehule wrote: > >> can I help with it, please. My English is terrible. > > Yes, I added a bit in the patch I submitted. > >> array user functions are used more time in pg core. The complexity of >> array functions are much higher, s

Re: [HACKERS] Review: listagg aggregate

Simon Riggs writes: > On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote: >> No performance issues > ISTM that this class of function is inherently dangerous performance > wise. > * It looks incredibly easy to construct enormous lists. We should test > the explosion limit of this to see h

Re: [HACKERS] Resetting a single statistics counter

2010/1/24 Tom Lane : > Magnus Hagander writes: >> 2010/1/24 Tom Lane : >>> The pg_stat_ prefix is some help but not enough IMO.  So I suggest >>> pg_stat_reset_table_counters and pg_stat_reset_function_counters. > >> Doesn't the pg_stat_ part already say this? > > My objection is that "reset_table

Re: [HACKERS] Review: listagg aggregate

2010/1/24 Simon Riggs : > On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote: >> No performance issues > > ISTM that this class of function is inherently dangerous performance > wise. there is potencial risk, but this risk isn't new. The almost all what you say is true for array aggregates.

Re: [HACKERS] Resetting a single statistics counter

Magnus Hagander writes: > 2010/1/24 Tom Lane : >> The pg_stat_ prefix is some help but not enough IMO.  So I suggest >> pg_stat_reset_table_counters and pg_stat_reset_function_counters. > Doesn't the pg_stat_ part already say this? My objection is that "reset_table" sounds like something you do

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

Michael Meskes írta: > On Fri, Jan 22, 2010 at 06:11:51PM +0100, Boszormenyi Zoltan wrote: > >>> Why does the preproc spit out ECPGset_var's but no ECPGget_var's in this >>> test case? >>> >>> >> Because there's no ECPGget_var()s emitted for >> - global variables >> - variables in th

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

Bernd Helmle writes: > --On 24. Januar 2010 08:37:13 -0500 Robert Haas > wrote: >> I think the problem case here might be something like this... > Did that with a crude pl/pgsql script, and got the following numbers: I think my concern about the original proposal was that the time to perform a

Re: [HACKERS] Resetting a single statistics counter

2010/1/24 Tom Lane : > Euler Taveira de Oliveira writes: >> Magnus Hagander escreveu: >>> Off to make it two separate functions.. (seems much more user-friendly >>> than a single function with an extra argument, IMHO) > >> +1. But as Simon said _single_ is too ugly. What about >> pg_stat_reset_use

Re: [HACKERS] commit fests

Kevin Grittner wrote: Andrew Dunstan wrote: As for getting more coverage of Beta, part of my trouble in testing applications on Beta is that there aren't good tools I know of for capture and replay of usage scenarios. Now there would be a good project for someone, and it would be unaffec

Re: [HACKERS] tab completion for prepared transactions?

On Sun, 2010-01-24 at 12:54 -0500, Tom Lane wrote: > Simon Riggs writes: > > I would like a mechanism in the server to prevent a session from > > accepting anything other than COMMIT or ROLLBACK PREPARED after a > > PREPARE. Otherwise it's possible to screw up your prepared xact and > > leave it h

Re: [HACKERS] Resetting a single statistics counter

Euler Taveira de Oliveira writes: > Magnus Hagander escreveu: >> Off to make it two separate functions.. (seems much more user-friendly >> than a single function with an extra argument, IMHO) > +1. But as Simon said _single_ is too ugly. What about > pg_stat_reset_user_{function,relation}? That

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

--On 24. Januar 2010 08:37:13 -0500 Robert Haas wrote: I agree - the requirements here are much looser than for, say, SELECT or UPDATE.  But it still has to not suck. Yeah, i think the meaning of "suck" can be much weakier than for a DML command. However, if it would degrade the perform

Re: [HACKERS] Largeobject Access Controls (r2460)

"Kevin Grittner" writes: > Tom Lane wrote: >> It might be better to try a test case with lighter-weight objects, >> say 5 million simple functions. > So the current database is expendable? Yeah, I think it was a bad experimental design anyway... regards, tom lane --

Re: [HACKERS] Resetting a single statistics counter

Magnus Hagander escreveu: >> Off to make it two separate functions.. (seems much more user-friendly >> than a single function with an extra argument, IMHO) > +1. But as Simon said _single_ is too ugly. What about pg_stat_reset_user_{function,relation}? Another thing that is not a problem of your

Re: [HACKERS] Resetting a single statistics counter

Magnus Hagander writes: > Here goes. Looks much saner. One minor stylistic gripe: +Datum +pg_stat_reset_single_table(PG_FUNCTION_ARGS) +{ + pgstat_reset_single_counter(PG_GETARG_OID(0), RESET_TABLE); + + PG_RETURN_VOID(); +} I don't like sticking PG_GETARG calls inline in the body

Re: [HACKERS] Review: listagg aggregate

On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote: > No performance issues ISTM that this class of function is inherently dangerous performance wise. * It looks incredibly easy to construct enormous lists. We should test the explosion limit of this to see how it is handled. Perhaps we nee

Re: [HACKERS] Largeobject Access Controls (r2460)

Tom Lane wrote: > It might be better to try a test case with lighter-weight objects, > say 5 million simple functions. So the current database is expendable? I'd just as soon delete it before creating the other one, if you're fairly confident the other one will do it. -Kevin -- Sent via p

Re: [HACKERS] tab completion for prepared transactions?

Simon Riggs writes: > I would like a mechanism in the server to prevent a session from > accepting anything other than COMMIT or ROLLBACK PREPARED after a > PREPARE. Otherwise it's possible to screw up your prepared xact and > leave it hanging there. Uh, what? That makes no sense at all.

Re: [HACKERS] Largeobject Access Controls (r2460)

"Kevin Grittner" writes: > I'm afraid pg_dump didn't get very far with this before: > pg_dump: WARNING: out of shared memory > pg_dump: SQL command failed > Given how fast it happened, I suspect that it was 2672 tables into > the dump, versus 26% of the way through 5.5 million tables. Yeah,

Re: [HACKERS] tab completion for prepared transactions?

Heikki Linnakangas writes: > Peter Eisentraut wrote: >> The scenario that I encountered is that you go around manually cleaning >> them up when the XA software fails for some reason. > Hmm, that's a good point though. Maybe it would make sense to add tab > completion for ROLLBACK/COMMIT PREPARED,

Re: [HACKERS] tab completion for prepared transactions?

On Sun, 2010-01-24 at 19:29 +0200, Heikki Linnakangas wrote: > Peter Eisentraut wrote: > > On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote: > >> Peter Eisentraut writes: > >>> Was there a designed-in reason not to have psql tab completion for > >>> COMMIT/ROLLBACK PREPARED ...? It does complete

Re: [HACKERS] Resetting a single statistics counter

2010/1/24 Magnus Hagander : > 2010/1/24 Tom Lane : >> Magnus Hagander writes: >>> In the spirit of finishing off small patches, attached is the one that >>> implements pg_stat_reset_single(), to be able to reset stats for a >>> single table or function. I kind of thought it would be included in >>

Re: [HACKERS] tab completion for prepared transactions?

Heikki Linnakangas wrote: > Bruce Momjian wrote: > > Heikki Linnakangas wrote: > >> Right, I vaguely recall that the idea of tab-completion for those > >> commands was rejected when 2PC was added because of that. A user sitting > >> at a psql terminal is not supposed to prepare a transaction. That'

Re: [HACKERS] tab completion for prepared transactions?

Bruce Momjian wrote: > Heikki Linnakangas wrote: >> Right, I vaguely recall that the idea of tab-completion for those >> commands was rejected when 2PC was added because of that. A user sitting >> at a psql terminal is not supposed to prepare a transaction. That's >> application server's business.

Re: [HACKERS] commit fests

Andrew Dunstan wrote: > As for getting more coverage of Beta, part of my trouble in > testing applications on Beta is that there aren't good tools I > know of for capture and replay of usage scenarios. Now there would > be a good project for someone, and it would be unaffected by the > Beta cycl

Re: [HACKERS] Resetting a single statistics counter

On Sun, 2010-01-24 at 18:25 +0100, Magnus Hagander wrote: > 2010/1/24 Tom Lane : > > Magnus Hagander writes: > >> In the spirit of finishing off small patches, attached is the one that > >> implements pg_stat_reset_single(), to be able to reset stats for a > >> single table or function. I kind of

Re: [HACKERS] Largeobject Access Controls (r2460)

Tom Lane wrote: > I'm not so worried about the amount of RAM needed as whether > pg_dump's internal algorithms will scale to large numbers of TOC > entries. Any O(N^2) behavior would be pretty painful, for > example. No doubt we could fix any such problems, but it might > take more work than w

Re: [HACKERS] tab completion for prepared transactions?

Heikki Linnakangas wrote: > Peter Eisentraut wrote: > > On l?r, 2010-01-23 at 12:42 -0500, Tom Lane wrote: > >> Peter Eisentraut writes: > >>> Was there a designed-in reason not to have psql tab completion for > >>> COMMIT/ROLLBACK PREPARED ...? It does complete the "PREPARED" but not > >>> the t

Re: [HACKERS] further explain changes

Robert Haas writes: > On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova >> why not let it go in ANALYZE, just as the sort info > It's kinda long-winded - it adds like 4 extra lines for each hash > join. I don't think I want to add that much clutter to regular E-A > output. Well, that would only

Re: [HACKERS] tab completion for prepared transactions?

Peter Eisentraut wrote: > On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote: >> Peter Eisentraut writes: >>> Was there a designed-in reason not to have psql tab completion for >>> COMMIT/ROLLBACK PREPARED ...? It does complete the "PREPARED" but not >>> the transaction identifiers. Maybe it's no

Re: [HACKERS] Resetting a single statistics counter

2010/1/24 Tom Lane : > Magnus Hagander writes: >> In the spirit of finishing off small patches, attached is the one that >> implements pg_stat_reset_single(), to be able to reset stats for a >> single table or function. I kind of thought it would be included in >> the patch from Greg Smith for sha

Re: [HACKERS] commit fests

Kevin Grittner wrote: You've as much as said that it's a given that many of the contributors will continue to work on new patches during this period to earn a living, while hopefully volunteering to help with getting the release out the door on their own time. As I understand the arguments, ha

Re: [GENERAL] [HACKERS] Sugerencia de opcion

Robert Haas writes: > 2009/1/22 Informatica-Cooperativa Cnel. Oviedo : >>     SELECT id, sum(salario) as SumaSalario >>     FROM salarios >>     GROUP BY id >>     HAVING SumaSalario>500; > I've wished for that syntax once or twice myself, but I'm assuming > there's a reason we haven't implemente

Re: [HACKERS] Resetting a single statistics counter

Magnus Hagander writes: > In the spirit of finishing off small patches, attached is the one that > implements pg_stat_reset_single(), to be able to reset stats for a > single table or function. I kind of thought it would be included in > the patch from Greg Smith for shared counters so I put it as

Re: [HACKERS] Review: listagg aggregate

On Jan 24, 2010, at 1:19 AM, Pavel Stehule wrote: > can I help with it, please. My English is terrible. Yes, I added a bit in the patch I submitted. > array user functions are used more time in pg core. The complexity of > array functions are much higher, so I don't think we need special > file.

[HACKERS] Resetting a single statistics counter

In the spirit of finishing off small patches, attached is the one that implements pg_stat_reset_single(), to be able to reset stats for a single table or function. I kind of thought it would be included in the patch from Greg Smith for shared counters so I put it aside, but I guess I misunderstood

Re: [HACKERS] commit fests

Kevin Grittner wrote: > Greg Smith wrote: > > > Developing new features is fun and tends to attract sponsorship > > dollars. Testing a frozen release, finding bugs, and resolving them > > is boring, and no one sponsors it. Therefore, if you let both > > things go on at once, I guarantee you almo

Re: [HACKERS] handling contrib directories as modules not shared libraries

On lör, 2010-01-23 at 18:00 -0700, Brook Milligan wrote: > It seems that src/Makefile.shlib has special cases for several > directories that build loadable modules rather than shared libraries. > The contrib/adminpack is one of the special cases, but none of the > other contrib directories are. As

Re: [HACKERS] RADIUS authentication

2010/1/24 Magnus Hagander : > 2010/1/20 KaiGai Kohei : >> As Tom pointed out, it is fundamentally same. >> The matter is this random() invocation is the first time after >> initialization of random seed by srandom(). It means an external observer >> can estimate the random value uniquely using pid

Re: [HACKERS] Red-black tree for GIN

Would it be OK if I went through here and hacked on the comments and sent this back to you? Feel free to edit the patch. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-h

Re: [HACKERS] commit fests

Greg Smith wrote: > Developing new features is fun and tends to attract sponsorship > dollars. Testing a frozen release, finding bugs, and resolving them > is boring, and no one sponsors it. Therefore, if you let both > things go on at once, I guarantee you almost all of the community > attentio

Re: [HACKERS] Red-black tree for GIN

2010/1/24 Teodor Sigaev : >> 3. This code could really use some more comments, and maybe some of >> the variable names could be better chosen, too.  It's far from obvious >> what is going on here.  I studied rbtrees in college and I still >> remember more or less how they work, but, boy, this is ha

Re: [HACKERS] commit fests

Andrew Dunstan wrote: >>> Perhaps it isn't that five months is outrageous, but that it >>> doesn't really benefit from an unorganized swarm of activity by >>> all the developers, and we've not worked out a reasonable >>> framework for who should do what during that time to best benefit >>> the p

Re: [HACKERS] Sugerencia de opcion

2009/1/22 Informatica-Cooperativa Cnel. Oviedo : > Buenos Dias todos, > >                             Soy un usuario de postgres de Paraguay, consulto > sobre la posibilidad de inclucion en la futura version la siguiente > sentencia(Uso de alias en la condicion HAVING ): > > >     SELECT id, sum(sa

Re: [HACKERS] Red-black tree for GIN

1. I think rb_free_recursive is missing a pfree(). Fixed, thank you 2. We already have a definition of NIL in the PG source base. I think this one needs to be named something else. RBNIL, maybe. fixed 3. This code could really use some more comments, and maybe some of the variable names

Re: [HACKERS] RADIUS authentication

2010/1/20 KaiGai Kohei : > (2010/01/20 0:19), Magnus Hagander wrote: >>> * I think this comment is right. >>>   +   for (i = 0; i<  RADIUS_VECTOR_LENGTH; i++) >>>   +       /* XXX: Generate a more secure random string? */ >>>   +       packet->vector[i] = random() % 255; >>> >>>   The random seed i

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

On Fri, Jan 22, 2010 at 06:11:51PM +0100, Boszormenyi Zoltan wrote: > > Why does the preproc spit out ECPGset_var's but no ECPGget_var's in this > > test case? > > > > Because there's no ECPGget_var()s emitted for > - global variables > - variables in the same function > > ECPGget_var() is o

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

On Sun, Jan 24, 2010 at 8:36 AM, Robert Haas wrote: > On Sat, Jan 23, 2010 at 10:48 PM, KaiGai Kohei wrote: >> (2010/01/24 12:29), Robert Haas wrote: >>> I don't think this is ready for committer, becauseTom previously >>> objected to the approach taken by this patch here, and no one has >>> answ

Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

On Sat, Jan 23, 2010 at 10:48 PM, KaiGai Kohei wrote: > (2010/01/24 12:29), Robert Haas wrote: >> I don't think this is ready for committer, becauseTom previously >> objected to the approach taken by this patch here, and no one has >> answered his objections: >> >> http://archives.postgresql.org/p

Re: [HACKERS] further explain changes

On Sun, Jan 24, 2010 at 12:06 AM, Jaime Casanova wrote: > On Sat, Jan 23, 2010 at 10:08 PM, Robert Haas wrote: >> >> I was also thinking about the possibility of adding a new option >> called "output" and making that control whether the "Output" line gets >> printed.  It's kind of annoying to use

  1   2   >