Re: [HACKERS] NULL input for array_agg()?

2009/11/15 Andrew Gierth : >> "Hitoshi" == Hitoshi Harada writes: > >  Hitoshi> Hi, During reviewing aggregates ORDER BY, I was reading spec >  Hitoshi> and found description like: > >  Hitoshi> == snip == > >  Hitoshi> Of the rows in the aggregation, the following do not qualify: >  Hitoshi>

[HACKERS] Summary and Plan for Hot Standby

After some time thinking about the best way forward for Hot Standby, I have some observations and proposals. First, the project is very large. We have agreed ways to trim the patch, yet it remains large. Trying to do everything in one lump is almost always a bad plan, so we need to phase things.

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, Nov 15, 2009 at 09:06, Simon Riggs wrote: > * Issues relating to handling of prepared transactions > There are some delicate issues surrounding what happens at the end of > recovery if there is a prepared transaction still holding an access > exclusive lock. It is straightforward to say, a

[HACKERS] commitfest patch move unavailable

After consulting with some other members of the community, I tried to post my fk error string patch to the current commitfest, but mistakenly posted it to the current commitfest, not the open one. When I tried to correct this by moving the patch to the open 2010-01 commitfest, I could not submit t

Re: [HACKERS] Postgres and likewise authentication

On Sat, Nov 14, 2009 at 21:07, u235sentinel wrote: > I'm curious if anyone has tried to link postgres authentication with a > product called likewise. > > Likesoft software will allow a linux/unix system to authenticate against a > windows domain.  I have it working on several flavors of linux and

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 10:00 +0100, Magnus Hagander wrote: > What does the time depend on? We need to wait for all current transactions to complete. (i.e. any backend that has (or could) take an xid or an AccessExclusiveLock before it commits.). Similar-ish to the wait for a CREATE INDEX CONCURREN

Re: [HACKERS] Summary and Plan for Hot Standby

On Sunday, November 15, 2009, Simon Riggs wrote: > On Sun, 2009-11-15 at 10:00 +0100, Magnus Hagander wrote: > >> What does the time depend on? > > We need to wait for all current transactions to complete. (i.e. any > backend that has (or could) take an xid or an AccessExclusiveLock before > it co

Re: [HACKERS] Hot standby, overflowed snapshots, testing

On Sat, 2009-11-14 at 08:43 -0800, Robert Hodges wrote: > I can help set up automated basic tests for hot standby using 1+1 setups on > Amazon. I¹m already working on tests for warm standby for our commercial > Tungsten implementation and need to solve the problem of creating tests that > adapt

Re: [HACKERS] Aggregate ORDER BY patch

Here's my first review. The patch was in context diff format and applied cleanly with a little 3 hunks in parse_expr.c. make succeeded without any warnings and make check passed all 121 tests. It implements as advertised, following SQL spec with extension of both DISTINCT clause and ORDER BY clau

Re: [HACKERS] Hot standby, race condition between recovery snapshot and commit

Simon Riggs wrote: > On Sat, 2009-11-14 at 14:59 +0200, Heikki Linnakangas wrote: >> I can't see any obvious way around that. > > Huh? We're only doing this strict locking approach because you insisted > that the looser approach was not acceptable. Take it easy, Simon. By obvious, I meant "trivi

Re: [HACKERS] commitfest patch move unavailable

On Sun, Nov 15, 2009 at 4:21 AM, George Gensure wrote: > After consulting with some other members of the community, I tried to > post my fk error string patch to the current commitfest, but > mistakenly posted it to the current commitfest, not the open one. > > When I tried to correct this by movi

Re: [HACKERS] Hot standby, race condition between recovery snapshot and commit

Oh, forgot to mention another thing that I've been pondering: Currently, the running-xacts record is written to the WAL after the checkpoint record. There's a small chance that you get an xlog switch in between. If that happens, it might take a long time after the checkpoint record until the stand

Re: [HACKERS] Python 3.1 support

On fre, 2009-11-13 at 11:27 -0700, James Pye wrote: > Some are TODOs, so in part by other people. Some were briefly touched > on in the recent past discussions(around the time that I announced the > WIP). Native typing vs conversion, function fragments vs function > modules. I'm of course only one

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > We need to wait for all current transactions to complete. (i.e. any > backend that has (or could) take an xid or an AccessExclusiveLock before > it commits.). Similar-ish to the wait for a CREATE INDEX CONCURRENTLY. > > The standby already performs this wait in the case where

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > * Issues relating to handling of prepared transactions > There are some delicate issues surrounding what happens at the end of > recovery if there is a prepared transaction still holding an access > exclusive lock. Can you describe in more detail what problem this is again? We

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, Nov 15, 2009 at 3:06 AM, Simon Riggs wrote: > Please can we agree a way forwards? I don't have a strong position on the technical issues, but I am very much in favor of getting something committed, even something with limitations, as soon as we practically can. Getting this feature into

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > There are two remaining areas of significant thought/effort: Here's a list of other TODO items I've collected so far. Some of them are just improvements or nice-to-have stuff, but some are more serious: - If WAL recovery runs out of lock space while acquiring an AccessExclusi

[HACKERS] Re: Hot standby, race condition between recovery snapshot and commit

On Sun, 2009-11-15 at 14:43 +0200, Heikki Linnakangas wrote: > This isn't absolutely necessary for the first version, but it's > something to keep in mind... Do I take that as agreement to the phased plan? > In general, I'd like to remove as many as possible of those cases > where the standby st

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > There are two remaining areas of significant thought/effort: > > Here's a list of other TODO items I've collected so far. Some of them > are just improvements or nice-to-have stuff, but some are more serious: >

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, Nov 15, 2009 at 2:32 PM, Simon Riggs wrote: >> - The "standby delay" is measured as current timestamp - timestamp of >> last replayed commit record. If there's little activity in the master, >> that can lead to surprising results. For example, imagine that >> max_standby_delay is set to 8

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote: >> - If WAL recovery runs out of lock space while acquiring an >> AccessExclusiveLock on behalf of a transaction that ran in the master, >> it will FATAL and abort recovery, bringing down the standby. Seems like >> it

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 14:47 +, Greg Stark wrote: > On Sun, Nov 15, 2009 at 2:32 PM, Simon Riggs wrote: > >> - The "standby delay" is measured as current timestamp - timestamp of > >> last replayed commit record. If there's little activity in the master, > >> that can lead to surprising results

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 16:50 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote: > >> - If WAL recovery runs out of lock space while acquiring an > >> AccessExclusiveLock on behalf of a transaction that ran in the master, > >> it wil

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, Nov 15, 2009 at 9:50 AM, Heikki Linnakangas wrote: > Simon Riggs wrote: >> On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote: >>> - If WAL recovery runs out of lock space while acquiring an >>> AccessExclusiveLock on behalf of a transaction that ran in the master, >>> it will FAT

Re: [HACKERS] Listen / Notify rewrite

On Thu, 12 Nov 2009 11:22:32 -0500 Andrew Chernow wrote: > > > However I share Greg's concerns that people are trying to use NOTIFY > > as a message queue which it is not designed to be. > > When you have an established libpq connection waiting for notifies it > is not unreasonable to expect/de

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

George Gensure writes: > I've put together a small patch to provide a schema name in an fk > violation in deference to the todo item "Report the schema along table > name in a referential failure error message" This is not the way forward; if it were, we would have done it years ago. Despite the

Re: [HACKERS] Summary and Plan for Hot Standby

Robert Haas wrote: > OK, but... there will always be things that will bring down the > stand-by, just as there will always be things that can bring down the > primary. A bucket of ice-water will probably do it, for example. I > mean, it would be great to make it better, but is it so bad that we >

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote: > The assumption that b-tree vacuum records don't need conflict > resolution because we did that with the additional cleanup-info record > works ATM, but it hinges on the fact that we don't delete any tuples > marked as killed while we d

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote: > >> The assumption that b-tree vacuum records don't need conflict >> resolution because we did that with the additional cleanup-info record >> works ATM, but it hinges on the fact that we don't delete any tuples >>

[HACKERS] named parameters in SQL functions

At Tom's suggestion I am looking at allowing use of parameter names in SQL functions instead of requiring use of $1 etc. That raises the question of how we would disambiguate a parameter name from a column name. Essentially, ISTM, we could use some special marker such as @ (c.f. SQL Server) o

Re: [HACKERS] named parameters in SQL functions

Andrew Dunstan wrote: At Tom's suggestion I am looking at allowing use of parameter names in SQL functions instead of requiring use of $1 etc. That raises the question of how we would disambiguate a parameter name from a column name. Essentially, ISTM, we could use some special marker such as

Re: [HACKERS] named parameters in SQL functions

2009/11/15 Andrew Dunstan : > > At Tom's suggestion I am looking at allowing use of parameter names in SQL > functions instead of requiring use of $1 etc. That raises the question of > how we would disambiguate a parameter name from a column name. Essentially, > ISTM, we could use some special mark

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 19:36 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote: > > > >> The assumption that b-tree vacuum records don't need conflict > >> resolution because we did that with the additional cleanup-info record > >>

Re: [HACKERS] named parameters in SQL functions

2009/11/15 Andrew Chernow : > Andrew Dunstan wrote: >> >> At Tom's suggestion I am looking at allowing use of parameter names in SQL >> functions instead of requiring use of $1 etc. That raises the question of >> how we would disambiguate a parameter name from a column name. Essentially, >> ISTM, w

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 12:37 PM, Andrew Dunstan wrote: > At Tom's suggestion I am looking at allowing use of parameter names in SQL > functions instead of requiring use of $1 etc. That raises the question of > how we would disambiguate a parameter name from a column name. Essentially, > ISTM, we

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

On Sun, Nov 15, 2009 at 11:21 AM, Tom Lane wrote: > George Gensure writes: >> I've put together a small patch to provide a schema name in an fk >> violation in deference to the todo item "Report the schema along table >> name in a referential failure error message" > > This is not the way forward

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, Nov 15, 2009 at 11:49 AM, Heikki Linnakangas wrote: > Agreed. Believe me, I'd like to have this committed as much as everyone > else. But once I do that, I'm also committing myself to fix all the > remaining issues before the release. The criteria for committing is: is > it good enough tha

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 5:49 PM, Andrew Chernow wrote: > Andrew Dunstan wrote: >> >> At Tom's suggestion I am looking at allowing use of parameter names in SQL >> functions instead of requiring use of $1 etc. That raises the question of >> how we would disambiguate a parameter name from a column n

[HACKERS] Listen / Notify - what to do when the queue is full

We still need to decide what to do with queue full situations in the proposed listen/notify implementation. I have a new version of the patch to allow for a variable payload size. However, the whole notification must fit into one page so the payload needs to be less than 8K. I have also added the

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 10:19 AM, Greg Stark wrote: >> I like the special marker idea. A '$' would be nice because its already in >> use for similar purposes, but I think that would lead to ambiguity with >> dollar quoting. > > I think that would be a big break with everything else and very > non-sq

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 19:36 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote: >>> The assumption that b-tree vacuum records don't need conflict resolution because we did that with the additional cle

Re: [HACKERS] Listen / Notify rewrite

On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote: > 3. Every distinct notification is delivered. > Regarding performance, the slru-queue is not fsync-ed to disk These two statements seem to be in opposition. How do you know a notification will be delivered if the queue is non-recoverabl

Re: [HACKERS] Summary and Plan for Hot Standby

Robert Haas wrote: > But a > query getting canceled because it touches a lot of tables sounds more > like a limitation than an outright bug, It's not that the query might get canceled. It will abort WAL recovery, kill all backends, and bring the whole standby down. -- Heikki Linnakangas Ent

Re: [HACKERS] named parameters in SQL functions

2009/11/15 David E. Wheeler : > On Nov 15, 2009, at 10:19 AM, Greg Stark wrote: > >>> I like the special marker idea.  A '$' would be nice because its already in >>> use for similar purposes, but I think that would lead to ambiguity with >>> dollar quoting. >> >> I think that would be a big break w

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

George Gensure wrote: This begs a bigger question: what's *really* easy or low barrier to entry for very light contributors like myself? - I've got time, I like the product, I need to know what's going to get you a win, I may not be gunning particularly for the feature myself. The TODO li

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 13:15 -0500, Robert Haas wrote: > I know Simon has said that he feels that the effort > to finish the HS and SR patches for 9/15 was somewhat of an artificial > deadline, but ISTM that with only 3 months remaining until the close > of the final CommitFest for this release, and

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule wrote: >> Personally, I like $var, but @var would be okay, and @@var is acceptable. >> But I'm JAPH, so my biases should be obvious. > > @var or @@var should be a break for people from MySQL. @var are r/w in > MySQL and @@var are global in T-SQL. So

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler wrote: > Personally, I like $var, but @var would be okay, and @@var is acceptable. But > I'm JAPH, so my biases should be obvious. I'm japh too -- but that doesn't mean grabbing one little aesthetic from Perl without copying the whole concept be

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: > The LSN doesn't help there, because when an itemid is marked as dead, > the LSN is not updated. I was thinking we could update the index block LSN without writing WAL using the LSN of the heap block that leads to the killed tuple. Pre

Re: [HACKERS] named parameters in SQL functions

2009/11/16 Andrew Dunstan : > At Tom's suggestion I am looking at allowing use of parameter names in SQL > functions instead of requiring use of $1 etc. That raises the question of > how we would disambiguate a parameter name from a column name. Essentially, > ISTM, we could use some special marker

Re: [HACKERS] named parameters in SQL functions

2009/11/15 Greg Stark : > On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule > wrote: >>> Personally, I like $var, but @var would be okay, and @@var is acceptable. >>> But I'm JAPH, so my biases should be obvious. >> >> @var or @@var should be a break for people from MySQL. @var are r/w in >> MySQL

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 10:54 AM, Greg Stark wrote: > I'm japh too -- but that doesn't mean grabbing one little aesthetic > from Perl without copying the whole concept behind it makes any sense. > Perl sigils are an important part of the language and are a basic part > of the syntax. They aren't just

Re: [HACKERS] named parameters in SQL functions

I like the special marker idea. A '$' would be nice because its already in use for similar purposes, but I think that would lead to ambiguity with dollar quoting. no, it should be safe (if you don't use for dollar quoting some like $variablename$) Actually, I was thinking of something like

Re: [HACKERS] named parameters in SQL functions

2009/11/15 Andrew Chernow : > >>> I like the special marker idea.  A '$' would be nice because its already >>> in >>> use for similar purposes, but I think that would lead to ambiguity with >>> dollar quoting. >> >> no, it should be safe (if you don't use for dollar quoting some like >> $variablena

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: > >> The LSN doesn't help there, because when an itemid is marked as dead, >> the LSN is not updated. > > I was thinking we could update the index block LSN without writing WAL > using the LSN of the heap block that

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler wrote: >> Moreover you would still have conflicts possible because sql can quote >> identifiers so people can have columns named "$foo". You would have a >> weird syntactic detail where "$foo" would mean something different >> than $foo even though

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 11:21 AM, Greg Stark wrote: > No, that's not the same. > > The point is that $ is a perfectly valid SQL identifier character and > $foo is a perfectly valid identifier. You can always quote any > identifier (yes, after case smashing) so you would expect if $foo is a > valid id

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 20:37 +0200, Heikki Linnakangas wrote: > Robert Haas wrote: > > But a > > query getting canceled because it touches a lot of tables sounds more > > like a limitation than an outright bug, > > It's not that the query might get canceled. It will abort WAL recovery, > kill all

Re: [HACKERS] ALTER ROLE/DATABASE RESET ALL versus security

Tom Lane wrote: > It looks to me like the code in AlterSetting() will allow an ordinary > user to blow away all settings for himself. Even those that are for > SUSET variables and were presumably set for him by a superuser. Isn't > this a security hole? I would expect that an unprivileged user s

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 7:25 PM, David E. Wheeler wrote: > On Nov 15, 2009, at 11:21 AM, Greg Stark wrote: > > > $foo should be killed off as a valid identifier, IMNSHO. > > But failing that, some other sigil would be most welcome. I don't think SQL is the height of language design either. But tr

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, Nov 15, 2009 at 7:29 PM, Simon Riggs wrote: > You agree there should be two phases? > I don't understand this repeated suggestion of "phases". Nobody's every suggested that we would refuse to add new features to HS after the initial commit or the 8.5 release. Of course there should be lat

Re: [HACKERS] named parameters in SQL functions

David E. Wheeler wrote: $foo should be killed off as a valid identifier, IMNSHO. It's only legal when quoted. Unquoted indetifiers can't begin with $. see scan.l: ident_start [A-Za-z\200-\377_] ident_cont [A-Za-z\200-\377_0-9\$] identifier

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 21:20 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: > > > >> The LSN doesn't help there, because when an itemid is marked as dead, > >> the LSN is not updated. > > > > I was thinking we could update the

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > You agree there should be two phases? I'm hesitant to say 'yes', because then you will harass me with "but you said that you would be OK with fixing X, Y, Z later! Why don't you commit already!". Of course there should be several phases! We've *already* punted a lot of stuff

Re: [HACKERS] named parameters in SQL functions

The point is that $ is a perfectly valid SQL identifier character and $foo is a perfectly valid identifier. You can always quote any identifier (yes, after case smashing) so you would expect if $foo is a valid identifier then "$foo" would refer to the same identifier. This case already exists

Re: [HACKERS] Aggregate ORDER BY patch

> "Hitoshi" == Hitoshi Harada writes: Hitoshi> Questions here: Hitoshi> - agglevelsup? Hitoshi> We have aggregate capability that all arguments from upper Hitoshi> level query in downer level aggregate makes aggregate call Hitoshi> itself to upper level call, as a constant value in down

Re: [HACKERS] named parameters in SQL functions

On Sun, Nov 15, 2009 at 7:56 PM, Andrew Chernow wrote: >> The point is that $ is a perfectly valid SQL identifier character and >> $foo is a perfectly valid identifier. You can always quote any >> identifier (yes, after case smashing) so you would expect if $foo is a >> valid identifier then "$foo

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 21:20 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote: >>> The LSN doesn't help there, because when an itemid is marked as dead, the LSN is not updated. >>> I was thinking we

[HACKERS] Re: Hot standby, race condition between recovery snapshot and commit

On Sun, 2009-11-15 at 21:37 +0200, Heikki Linnakangas wrote: > Am I missing anything? Will review. > I also experimented with including the running-xacts information in the > checkpoint record itself. That somehow feels more straightforward to me, > but it wasn't really any less code, and it wou

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 12:09 PM, Greg Stark wrote: > 1) Error messages which mention column names are supposed to quote the > column name to set it apart from the error string. This also > guarantees that weird column names are referenced correctly as "foo > bar" or "$foo" so the reference in the err

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 11:35 AM, Greg Stark wrote: > I don't think SQL is the height of language design either. But trying > to turn it into another language piece by piece is not gong to make it > any nicer. I don't know of anyone suggesting such a thing. > A sigil here doesn't accomplish anything

Re: [HACKERS] Hot standby, race condition between recovery snapshot and commit

Simon Riggs wrote: > On Sun, 2009-11-15 at 21:37 +0200, Heikki Linnakangas wrote: > >> Am I missing anything? > > Will review. Thanks! Please use the head of git branch, I already found one major oversight in what I posted that's fixed there... I should go to bed already. -- Heikki Linnakang

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 21:56 +0200, Heikki Linnakangas wrote: > If you actually want to help, can you please focus on fixing the > must-fix bugs we know about? We can then discuss which of the > remaining known issues we're willing to live with. I intend to work on all of the issues, so not sure w

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > Right now, I don't know which you > consider to be the must-fix issues, hence the thread. Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the index pages after the last b-tree vacuum record? Thanks. -- Heikki Linnakangas EnterpriseDB http://www.ente

Re: [HACKERS] commitfest patch move unavailable

Robert Haas wrote: (Maybe I should automatically create a "Miscellaneous" topic when each new CF is added?) I'm surprised you're populating each one from scratch every time, that seems like duplicated effort begging to be automated. Couldn't you just come up with a stock list of the most comm

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > Right now, I don't know which you > > consider to be the must-fix issues, hence the thread. > > Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the > index pages after the last b-tree vacuum r

Re: [HACKERS] Summary and Plan for Hot Standby

On 11/15/09 12:58 PM, Simon Riggs wrote: > On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> Right now, I don't know which you >>> consider to be the must-fix issues, hence the thread. >> Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the >>

Re: [HACKERS] Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 23:14 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: > >> Simon Riggs wrote: > >>> Right now, I don't know which you > >>> consider to be the must-fix issues, hence the thread. > >> Ok, could you tackle th

Re: [HACKERS] Writeable CTE patch

I wrote: Attached is the latest version of this patch. Here's that same patch in context diff format. Sorry for the noise. Regards, Marko Tiikkaja *** a/doc/src/sgml/queries.sgml --- b/doc/src/sgml/queries.sgml *** *** 1499,1505 SELECT 3, 'three'; SELECT select_list FRO

[HACKERS] CommitFest 2009-11 Closed; Initial assignments

With some lazy Sunday slack, the 2009-11 CommitFest is now officially closed. Due to a bumper crop of review volunteers, almost all patches are already assigned an initial reviewer. Here are the notable exceptions: SE-PostgreSQL/Lite: It's hard to find a reviewer willing to take on a patch

Re: [HACKERS] named parameters in SQL functions

Andrew Dunstan writes: > At Tom's suggestion I am looking at allowing use of parameter names in > SQL functions instead of requiring use of $1 etc. That raises the > question of how we would disambiguate a parameter name from a column > name. Throw error if ambiguous. We already resolved this

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >>> Right now, I don't know which you >>> consider to be the must-fix issues, hence the thread. >> Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the >> index pages after the

Re: [HACKERS] Listen / Notify rewrite

Simon Riggs writes: > On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote: >> 3. Every distinct notification is delivered. >> Regarding performance, the slru-queue is not fsync-ed to disk > These two statements seem to be in opposition. How do you know a > notification will be delivered if t

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

Andrew Dunstan writes: > George Gensure wrote: >> This begs a bigger question: what's *really* easy or low barrier to >> entry for very light contributors like myself? > The TODO list at doesn't seem to > have a huge number or [E] items. Maybe we need a b

[HACKERS] proposal: using PQexecParams in psql (using variables as real params)

Hello I propose to add possibility to use psql variables as real query parameters. The goal of this proposal is simplification of creating psql based commands. Current using of psql variables based on substitution has large area of using, but has some risks. a) there are possible sql injection, b)

Re: [HACKERS] [COMMITTERS] pgsql: /home/peter/commit-msg

David Fetter writes: > On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote: >> Peter Eisentraut wrote: >>> /home/peter/commit-msg >> er, what? > I'm suspecting a misfired script somewhere. No doubt "cvs commit -m ~/commit-msg" instead of "cvs commit -F ~/commit-msg" ... I think I've ma

Re: [HACKERS] Summary and Plan for Hot Standby

Josh Berkus writes: > So I'm in favor of committing part of the HS code even if there are > known failure conditions, as long as those conditions are well-defined. If we're thinking of committing something that is known broken, I would want to have a clearly defined and trust-inspiring escape str

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

2009/11/16 Tom Lane : > The real problem with the entry that George picked up on was that it was > misdescribed and mislabeled as easy because whoever put it in ignored > the fact that there was not a consensus to do a half-baked fix ... > this is a problem with a wiki TODO list :-( Wouldn't it be

Re: [HACKERS] Listen / Notify rewrite

On Sun, 2009-11-15 at 16:48 -0500, Tom Lane wrote: > Simon Riggs writes: > > On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote: > >> 3. Every distinct notification is delivered. > >> Regarding performance, the slru-queue is not fsync-ed to disk > > > These two statements seem to be in oppo

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

Brendan Jurd writes: > However, I'm not sure how productive the [E]asy marker can really be. > Items end up on the TODO generally because a) we couldn't settle on a > way forward, or b) nobody was keen to do it right away. There just > aren't many genuinely "easy" items in there, easy ones usuall

Re: [HACKERS] Listen / Notify rewrite

Simon Riggs writes: > On Sun, 2009-11-15 at 16:48 -0500, Tom Lane wrote: >> You misunderstand the requirements. LISTEN notifications are *not* >> meant to survive a database crash, and never have been. However, >> so long as both client and server stay up, they must be reliable. >> If the client

Re: [HACKERS] Aggregate ORDER BY patch

> "Andrew" == Andrew Gierth writes: Andrew> Performance. Andrew> tuplesort_getdatum etc. seems to be substantially faster than Andrew> tuplesort_gettupleslot especially for the case where you're Andrew> sorting a pass-by-value datum such as an integer (since the Andrew> datum is then st

Re: [HACKERS] Summary and Plan for Hot Standby

On Nov 15, 2009, at 2:17 PM, Tom Lane wrote: >> So I'm in favor of committing part of the HS code even if there are >> known failure conditions, as long as those conditions are well-defined. > > If we're thinking of committing something that is known broken, I would > want to have a clearly defin

Re: [HACKERS] Summary and Plan for Hot Standby

"David E. Wheeler" writes: > On Nov 15, 2009, at 2:17 PM, Tom Lane wrote: >> I agree with Heikki that it would be better not to commit as long as >> any clear showstoppers remain unresolved. > If ever there were an argument for topic branches, *this is it*. How so? They've got a perfectly good

Re: [HACKERS] Summary and Plan for Hot Standby

On Nov 15, 2009, at 4:19 PM, Simon Riggs wrote: On Sun, 2009-11-15 at 23:14 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: Right now, I don't know which you consider to be the must-fix issues, hence the thr

Re: [HACKERS] Hot standby, overflowed snapshots, testing

On 11/15/09 2:25 AM PST, "Simon Riggs" wrote: > On Sat, 2009-11-14 at 08:43 -0800, Robert Hodges wrote: > >> I can help set up automated basic tests for hot standby using 1+1 setups on >> Amazon. I¹m already working on tests for warm standby for our commercial >> Tungsten implementation and ne

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

On Sun, Nov 15, 2009 at 12:50:14AM +, Roger Leigh wrote: > On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote: > > Roger Leigh writes: > > > The side effect from this change is that some of the testsuite > > > expected data will need updating due to the extra pad spaces > > > > No, we a

Re: [HACKERS] Aggregate ORDER BY patch

On Sun, Nov 15, 2009 at 11:23 PM, Andrew Gierth wrote: > Future performance enhancements (which I have no particular plans to > tackle) would involve having the planner consult the desired aggregate > orderings and estimating the cost of sorting as opposed to the cost of > producing a plan with th

Re: [HACKERS] Patch committers

Magnus Hagander wrote: > On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote: > > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander > > wrote: > >> How about we add specific feature(s) about tihs to the commitfest > >> management tool? Like the possibility to directly link a git > >> repo/branch wit

Re: [HACKERS] patch - Report the schema along table name in a referential failure error message

Tom Lane wrote: Yeah, that is a real problem for new would-be contributors --- there simply isn't that much low-hanging fruit waiting for them, unless they focus on areas that no one else has taken much interest in; and even then there are few really small tasks.

  1   2   >