Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On 21 June 2012 12:41, Andres Freund wrote: > 2.) > Keep the decoding site up2date by replicating the catalog via normal HS > recovery > mechanisms. > > Advantages: > * most of the technology is already there > * minimal overhead (space, performance) > * no danger of out of sync catalogs > * no s

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

Andres Freund Sent: Thursday, June 21, 2012 5:11 PM > 4.) > Log enough information in the walstream to make decoding possible using only > the walstream. What I understood is that enough information is catalog data. Is that right or something else? > Advantages: > * Decoding can optionally be do

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

Hello. > > The attached ugly patch does it. We seem should put NO_LOCALE=1 > > on the 'make check' command line for the encodings not compatible > > with the environmental locale, although it looks work. > > +REGRESS_LC0 = $(subst .sql,,$(shell cd sql; ls plperl_lc_$(shell echo snip. > Hrm, that'

Re: [HACKERS] COMMUTATOR doesn't seem to work

On 12-06-22 12:22 AM, Tom Lane wrote: Um, an operator with different types on left and right cannot be its own commutator. Understood. I completely misunderstood the purpose of COMMUTATOR. I thought that it was telling the system that the procedure could be called with the arguments reversed

Re: [HACKERS] COMMUTATOR doesn't seem to work

"D'Arcy Cain" writes: > On 12-06-21 12:18 PM, Tom Lane wrote: >> Did you actually create a "text = chkpass" function and operator? >> This declaration merely promises that you will provide one eventually. >> The system does not have the ability to make one for you. > I guess I am missing the poin

Re: [HACKERS] Skip checkpoint on promoting from streaming replication

Hello, > Is it guaranteed that all the files (e.g., the latest timeline history file) > required for such crash recovery exist in pg_xlog? If yes, your > approach might work well. Particularly regarding the promotion, the files reuiqred are the history file of the latest timeline, the WAL file in

Re: [HACKERS] COMMUTATOR doesn't seem to work

On 12-06-21 12:18 PM, Tom Lane wrote: Did you actually create a "text = chkpass" function and operator? This declaration merely promises that you will provide one eventually. The system does not have the ability to make one for you. I guess I am missing the point of COMMUTATOR then. The docs s

Re: [HACKERS] [PATCH] Allow breaking out of hung connection attempts

(2012/05/01 0:30), Ryan Kelly wrote: On Mon, Apr 30, 2012 at 09:02:33AM -0400, Alvaro Herrera wrote: Well, do *you* want it? Of course. That way I can stop patching my psql and go back to using the one that came with my release :) Here is result of my review of v4 patch. Submission -

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

Andrew Dunstan writes: > On 06/21/2012 07:43 PM, Tom Lane wrote: >> I didn't understand that then, and I still don't. > If something else holds a lock on the table (e.g. another CREATE INDEX) > the ALTER TABLE will block until it's done, waiting for an ACCESS > EXCLUSIVE lock. The whole method

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

On 06/21/2012 07:43 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/21/2012 06:25 PM, Tom Lane wrote: Hm, I guess I've forgotten that one? See I didn't understand that then, and I still don't. The ALTER TABLE CLUSTER migh

Re: [HACKERS] [PATCH 04/16] Add embedded list interface (header only)

On 22 June 2012 01:04, Tom Lane wrote: > This is nonsense.  There are at least three buildfarm machines running > compilers that do not "pretend to be gcc" (at least, configure > recognizes them as not gcc) and are not MSVC either. So those three don't have medium to high degrees of compatibility

Re: [HACKERS] [PATCH 04/16] Add embedded list interface (header only)

Peter Geoghegan writes: > All of the less popular compilers we support we support precisely > because they pretend to be GCC, with the sole exception, as always, of > the Microsoft product, in this case MSVC. This is nonsense. There are at least three buildfarm machines running compilers that do

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

Andrew Dunstan writes: > On 06/21/2012 06:25 PM, Tom Lane wrote: >> Hm, I guess I've forgotten that one? > See I didn't understand that then, and I still don't. The ALTER TABLE CLUSTER might need exclusive lock, but it's not go

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

On 06/21/2012 06:25 PM, Tom Lane wrote: Andrew Dunstan writes: (There's another bug to do with parallel pg_restore and clustering that Andrew Hammond raised back in January, that I want to fix when I get some time.) Hm, I guess I've forgotten that one? See

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

Andrew Dunstan writes: > If I'm understanding you correctly, fixing the bogus dependency thing is > more an insurance policy than fixing a case (other than the constraint > dependency) that is known to be broken. Right. That's the only *known* broken case, and it does seem like we'd have heard

Re: [HACKERS] [PATCH 04/16] Add embedded list interface (header only)

On 20 June 2012 14:38, Andres Freund wrote: > It incurs a rather high performance overhead due to added memory allocations > and added pointer indirections. Thats fine for most of the current users of > the List interface, but certainly not for all. In other places you cannot even > have memory al

Re: [HACKERS] pg_dump and dependencies and --section ... it's a mess

On 06/21/2012 02:13 PM, Tom Lane wrote: Don't know if everybody on this list has been paying attention to the pgsql-bugs thread about bug #6699. The shortest example of the problem is create table t1 (f1 int primary key, f2 text); create view v1 as select f1, f2 from t1 group by f1; The view

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

On 21 June 2012 19:13, Jaime Casanova wrote: > On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai wrote: >> 2012/6/8 Simon Riggs : >> >>> I have a prototype that has some of these characteristics, so I see >>> our work as complementary. >>> >>> At present, I don't think this patch would be committable

Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree

Alexander Korotkov writes: > On Thu, Jun 21, 2012 at 11:12 AM, Heikki Linnakangas < > heikki.linnakan...@enterprisedb.com> wrote: >> I don't think we want to expose TrickFunctionCall2(). Not with that name, >> anyway. Perhaps we should refactor the functions called this way, >> range_adjacent, ran

Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree

On Thu, Jun 14, 2012 at 2:56 AM, Alexander Korotkov wrote: > attached patch implements quad-tree on ranges. Some performance results in > comparison with current GiST indexing. > Index creation is slightly slower. Probably, it need some investigation. > Search queries on SP-GiST use much more page

Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree

On Thu, Jun 21, 2012 at 11:12 AM, Heikki Linnakangas < heikki.linnakan...@enterprisedb.com> wrote: > On 14.06.2012 01:56, Alexander Korotkov wrote: > >> Hackers, >> >> attached patch implements quad-tree on ranges. Some performance results in >> comparison with current GiST indexing. >> > > @@ -7

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

Excerpts from Alex Hunsaker's message of jue jun 21 10:27:41 -0400 2012: > > On Wed, Jun 20, 2012 at 1:15 PM, Alvaro Herrera > wrote: > > Excerpts from Alex Hunsaker's message of vie feb 10 16:53:05 -0300 2012: > > > >> Seems like we missed the fact that we still did SvUTF8_on() in sv2cstr > >>

Re: [HACKERS] Btree or not btree? That is the question

I dug through the logs and found some other occurances of the "could not read block" errors. Some on dirt simple SELECT queries. Nothing else has generated the btree error yet. About 35 found in the last month. > This theory would be more plausible if you're wrong about the second-case > table

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

Excerpts from Kyotaro HORIGUCHI's message of jue jun 21 07:22:43 -0400 2012: > Hello, > > > > Seems like we missed the fact that we still did SvUTF8_on() in sv2cstr > > > and SvPVUTF8() when turning a perl string into a cstring. > > > > Right. > > I spent a bit longer time catching on pl/perl a

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

Excerpts from Kyotaro HORIGUCHI's message of jue jun 21 08:02:58 -0400 2012: > > Ouch! > > > # UtfToLocal() seems to have a bug that always report illegal > > # encoding was "UTF8" regardless of the real encoding. But > > # plper_lc_*.(sql|out) increases if the bug is fixed. > > This is not a b

Re: [HACKERS] Incorrect behaviour when using a GiST index on points

On Wed, Feb 22, 2012 at 5:56 PM, Alexander Korotkov wrote: > Attached patch fixes GiST behaviour without altering operators behaviour. > I think we definitely should apply this patch before 9.2 release, because it is a bug fix. Otherwise people will continue produce incorrect GiST indexes with in

Re: [HACKERS] Btree or not btree? That is the question

Greg Sabino Mullane writes: >>> ERROR: index "pg_class_oid_index" is not a btree >> That means you got bogus data while reading the metapage. >> I'm beginning to wonder about the hardware on this server ... > This happened again, and this time I went back through > the logs and found that it is

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai wrote: > 2012/6/8 Simon Riggs : > >> I have a prototype that has some of these characteristics, so I see >> our work as complementary. >> >> At present, I don't think this patch would be committable in CF1, but >> I'd like to make faster progress with

[HACKERS] pg_dump and dependencies and --section ... it's a mess

Don't know if everybody on this list has been paying attention to the pgsql-bugs thread about bug #6699. The shortest example of the problem is create table t1 (f1 int primary key, f2 text); create view v1 as select f1, f2 from t1 group by f1; The view's query is legal only because of the primar

Re: [HACKERS] Btree or not btree? That is the question

> > ERROR: index "pg_class_oid_index" is not a btree > > That means you got bogus data while reading the metapage. > I'm beginning to wonder about the hardware on this server ... This happened again, and this time I went back through the logs and found that it is always the exact same query cau

Re: [HACKERS] Release versioning inconsistency

On tor, 2012-06-21 at 16:17 +0200, Magnus Hagander wrote: > I don't recall the reason why using 9.2.0betax was actually wrong - i > realize that's not the name of the version, so thereby the directory > was wrong. But in what way would it be wrong to call the version that? It's not the beta for 9.

Re: [HACKERS] Release versioning inconsistency

On tor, 2012-06-21 at 16:19 +0200, Magnus Hagander wrote: > On Wed, Jun 20, 2012 at 1:35 PM, Dickson S. Guedes > wrote: > > 2012/6/20 Magnus Hagander : > >> On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp wrote: > >>> On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander > >>> wrote: > (I do

Re: [HACKERS] Release versioning inconsistency

2012/6/21 Magnus Hagander : > On Wed, Jun 20, 2012 at 1:35 PM, Dickson S. Guedes > wrote: >> 2012/6/20 Magnus Hagander : >>> On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp wrote: On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander wrote: > (I do believe that using the v9.2.0beta

Re: [HACKERS] COMMUTATOR doesn't seem to work

On Jun21, 2012, at 17:46 , D'Arcy Cain wrote: > Maybe I am using it wrong but I get no error message when I use it. I > have a type called chkpass (a version is in the additional supplied > modules) and I create the equality operator like this: > ... > > So while it created the operator it didn

Re: [HACKERS] COMMUTATOR doesn't seem to work

"D'Arcy Cain" writes: > Maybe I am using it wrong but I get no error message when I use it. I > have a type called chkpass (a version is in the additional supplied > modules) and I create the equality operator like this: > CREATE OPERATOR = ( > PROCEDURE = eq, > LEFTARG = chkpa

Re: [HACKERS] Reseting undo/redo logs

Thanks. I was going down this route, so just your confirmation that this is the right path is helpful. Edmon On Thu, Jun 21, 2012 at 11:58 AM, Tom Lane wrote: > Edmon Begoli writes: >> One of the Greenplum segments went down and it cannot recover because >> "PANIC        XX000 invalid redo/undo

Re: [HACKERS] Reseting undo/redo logs

Edmon Begoli writes: > One of the Greenplum segments went down and it cannot recover because > "PANICXX000 invalid redo/undo record in shutdown checkpoint > (xlog.c:6576)" > I am posting this question here because most casual users of > Postgres/Greenplum are telling me that database is h

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On Thursday, June 21, 2012 04:05:54 PM Florian Pflug wrote: > On Jun21, 2012, at 13:41 , Andres Freund wrote: > > 5.) > > The actually good idea. Yours? > > What about a mixure of (3b) and (4), which writes the data not to the WAL > but to a separate logical replication log. More specifically: >

[HACKERS] COMMUTATOR doesn't seem to work

Maybe I am using it wrong but I get no error message when I use it. I have a type called chkpass (a version is in the additional supplied modules) and I create the equality operator like this: CREATE OPERATOR = ( PROCEDURE = eq, LEFTARG = chkpass, RIGHTARG = text,

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On Thursday, June 21, 2012 03:56:54 PM Florian Pflug wrote: > On Jun21, 2012, at 13:41 , Andres Freund wrote: > > 3b) > > Ensure that enough information in the catalog remains by fudging the xmin > > horizon. Then reassemble an appropriate snapshot to read the catalog as > > the tuple in question h

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On Thursday, June 21, 2012 05:25:41 PM Simon Riggs wrote: > On 21 June 2012 16:13, Andres Freund wrote: > > On Thursday, June 21, 2012 05:05:04 PM Simon Riggs wrote: > >> On 21 June 2012 15:53, Andres Freund wrote: > >> >> ISTM we should maintain a lookup table on target system that has the > >>

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On 21 June 2012 16:13, Andres Freund wrote: > On Thursday, June 21, 2012 05:05:04 PM Simon Riggs wrote: >> On 21 June 2012 15:53, Andres Freund wrote: >> >> ISTM we should maintain a lookup table on target system that has the >> >> minimal required information on it. >> > >> > You need just about

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On Thursday, June 21, 2012 05:05:04 PM Simon Riggs wrote: > On 21 June 2012 15:53, Andres Freund wrote: > >> ISTM we should maintain a lookup table on target system that has the > >> minimal required information on it. > > > > You need just about the whole catalog because the *_out procs might ne

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On 21 June 2012 15:53, Andres Freund wrote: >> ISTM we should maintain a lookup table on target system that has the >> minimal required information on it. > You need just about the whole catalog because the *_out procs might need to > lookup types, operators and such again. > Unless you want to

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

On Thu, Jun 21, 2012 at 5:22 AM, Kyotaro HORIGUCHI wrote: >> So I played a bit with this patch, and touched it a bit mainly >> [...] functions in Util.xs might leak some memory, so I made an attempt to > Ok, Is it ok to look into the newer patch including fix of leaks > at first? Yeah :-). > V

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

Hi, On Thursday, June 21, 2012 04:39:21 PM Simon Riggs wrote: > On 21 June 2012 12:41, Andres Freund wrote: > > 3) > > Multi-Versioned catalog > > > > Below are two possible implementation strategies for that concept > > > > Advantages: > > * Decoding is done on the master in an asynchronous fa

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On 21 June 2012 12:41, Andres Freund wrote: > 3) > Multi-Versioned catalog > > Below are two possible implementation strategies for that concept > > Advantages: > * Decoding is done on the master in an asynchronous fashion > * low overhead during normal DML execution, not much additional code in

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

On Wed, Jun 20, 2012 at 1:15 PM, Alvaro Herrera wrote: > Excerpts from Alex Hunsaker's message of vie feb 10 16:53:05 -0300 2012: > >> Seems like we missed the fact that we still did SvUTF8_on() in sv2cstr >> and SvPVUTF8() when turning a perl string into a cstring. > > Right. > > So I played a bi

Re: [HACKERS] Pruning the TODO list

On 21 June 2012 15:00, Tom Lane wrote: > Simon Riggs writes: >> On 21 June 2012 08:30, Peter Eisentraut wrote: >>> Nonetheless, it would be a good idea to prune the TODO list regularly, >>> such as after a release.  We used to do that a bit, not so much lately, >>> perhaps.  But everyone is invi

Re: [HACKERS] Release versioning inconsistency

On Wed, Jun 20, 2012 at 1:35 PM, Dickson S. Guedes wrote: > 2012/6/20 Magnus Hagander : >> On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp wrote: >>> On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander >>> wrote: (I do believe that using the v9.2.0beta marker is *better*, because then

Re: [HACKERS] Release versioning inconsistency

On Wed, Jun 20, 2012 at 5:20 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On ons, 2012-06-20 at 13:26 +0200, Magnus Hagander wrote: >>> That might actually be a good idea. We can't really change the way we >>> named the betas, but it's not too late to consider naming the actual >>> release a

[HACKERS] Reseting undo/redo logs

I have this issue on Greenplum which is a MPP hybrid build from postgres 8.2, and the issue I am seeing is 100% from pg code. One of the Greenplum segments went down and it cannot recover because "PANIC XX000 invalid redo/undo record in shutdown checkpoint (xlog.c:6576)" I am posting this questi

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On Jun21, 2012, at 13:41 , Andres Freund wrote: > 5.) > The actually good idea. Yours? What about a mixure of (3b) and (4), which writes the data not to the WAL but to a separate logical replication log. More specifically: There's a per-backend queue of change notifications. Whenever a non-catal

Re: [HACKERS] Pruning the TODO list

Simon Riggs writes: > On 21 June 2012 08:30, Peter Eisentraut wrote: >> Nonetheless, it would be a good idea to prune the TODO list regularly, >> such as after a release. We used to do that a bit, not so much lately, >> perhaps. But everyone is invited to contribute to that. > The idea is to r

Re: [HACKERS] Catalog/Metadata consistency during changeset extraction from wal

On Jun21, 2012, at 13:41 , Andres Freund wrote: > 3b) > Ensure that enough information in the catalog remains by fudging the xmin > horizon. Then reassemble an appropriate snapshot to read the catalog as the > tuple in question has seen it. The ComboCID machinery makes that quite a bit harder, I

Re: [HACKERS] Resource Owner reassign Locks

On 18.06.2012 13:59, Heikki Linnakangas wrote: On 10.06.2012 23:39, Jeff Janes wrote: I found the interface between resowner.c and lock.c a bit confusing. resowner.c would sometimes call LockReassignCurrentOwner() to reassign all the locks, and sometimes it would call LockReassignCurrentOwner() o

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

Ouch! > # UtfToLocal() seems to have a bug that always report illegal > # encoding was "UTF8" regardless of the real encoding. But > # plper_lc_*.(sql|out) increases if the bug is fixed. This is not a bug. The error message "invalid byte sequence for encoding "UTF8"" meant "invalid INPUT byte seq

[HACKERS] Catalog/Metadata consistency during changeset extraction from wal

Hi Robert, Hi all, Robert and I talked quite a bit about different methods of providing enough information to extract tuples from wal. I don't think either of us is yet really convinced of any individual method, so I want to recap our discussion in one email so others can chime in without readi

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

Hello, > > Seems like we missed the fact that we still did SvUTF8_on() in sv2cstr > > and SvPVUTF8() when turning a perl string into a cstring. > > Right. I spent a bit longer time catching on pl/perl and now understand what is the problem... > So I played a bit with this patch, and touched it

Re: [HACKERS] not null validation option in contrib/file_fdw

I rebased the patch to current head. Attached is an updated version of the patch. Best regards, Etsuro Fujita > -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita > Sent: Tuesday, April 17, 2012 2:40 PM >

Re: [HACKERS] sortsupport for text

On 21 June 2012 11:40, Florian Pflug wrote: > At this point, my theory is that your choice of "random" strings prevents > strxfrm() from ever winning over strcoll(). The reason being that you pick > each letter uniformly distributed from a-z, resulting in a probability of > two string differing in

Re: [HACKERS] sortsupport for text

On Jun21, 2012, at 11:55 , Peter Geoghegan wrote: > On 21 June 2012 10:24, Florian Pflug wrote: >> On Jun21, 2012, at 02:22 , Peter Geoghegan wrote: >>> I've written a very small C++ program, which I've attached, that >>> basically proves that this can still make a fairly large difference - >>> I

Re: [HACKERS] sortsupport for text

On 21 June 2012 10:24, Florian Pflug wrote: > On Jun21, 2012, at 02:22 , Peter Geoghegan wrote: >> I've written a very small C++ program, which I've attached, that >> basically proves that this can still make a fairly large difference - >> I hope it's okay that that it's C++, but that allowed me t

Re: [HACKERS] sortsupport for text

On Jun21, 2012, at 02:22 , Peter Geoghegan wrote: > I've written a very small C++ program, which I've attached, that > basically proves that this can still make a fairly large difference - > I hope it's okay that that it's C++, but that allowed me to write the > program quickly, with no dependencie

Re: [HACKERS] Allow WAL information to recover corrupted pg_controldata

>>> The reason I'm concerned about selecting a next-LSN that's certainly beyond >>> every LSN in the database is that not doing >>> so could result in introducing further corruption, which would be entirely >>> avoidable with more care in choosing the >>> next-LSN. >> The further corruption ca

Re: [HACKERS] [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes

Hi Steve, On Thursday, June 21, 2012 02:16:57 AM Steve Singer wrote: > On 12-06-13 07:28 AM, Andres Freund wrote: > > From: Andres Freund > > > > The individual changes need to be identified by an xid. The xid can be a > > subtransaction or a toplevel one, at commit those can be reintegrated by >

Re: [HACKERS] Pruning the TODO list

On 21 June 2012 08:30, Peter Eisentraut wrote: > Nonetheless, it would be a good idea to prune the TODO list regularly, > such as after a release.  We used to do that a bit, not so much lately, > perhaps.  But everyone is invited to contribute to that. The idea is to remove contentious issues fr

Re: [HACKERS] Too frequent message of pgbench -i?

> On Wed, Jun 20, 2012 at 4:04 AM, Tatsuo Ishii wrote: >> Currently pgbench -i prints following message every 10k tuples created. >> >>                        fprintf(stderr, "%d tuples done.\n", j); >> >> I think it's long time ago when the frequency of message seemed to be >> appropriate because

Re: [HACKERS] sortsupport for text

On Jun20, 2012, at 19:38 , Peter Geoghegan wrote: > On 20 June 2012 17:41, Tom Lane wrote: >> In any case, if you have to redefine the meaning of equality in order >> to justify a performance patch, I'm prepared to walk away at the start. > > The advantage of my proposed implementation is precise

Re: [HACKERS] Pruning the TODO list

On tor, 2012-06-21 at 15:01 +0800, Simon Riggs wrote: > ISTM that we should prune the list right down to nothing, or very, > very few entries. We must have a TODO list that we can trust to save > us time. I don't want to see any more people waste their time on > issues that aren't really wanted. At

Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree

On 14.06.2012 01:56, Alexander Korotkov wrote: Hackers, attached patch implements quad-tree on ranges. Some performance results in comparison with current GiST indexing. @@ -788,7 +774,7 @@ range_super_union(TypeCacheEntry *typcache, RangeType * r1, R angeType * r2) * part of the relcache

Re: [HACKERS] Allow WAL information to recover corrupted pg_controldata

Amit Kapila writes: >> The reason I'm concerned about selecting a next-LSN that's certainly beyond >> every LSN in the database is that not doing >> so could result in introducing further corruption, which would be entirely >> avoidable with more care in choosing the >> next-LSN. > The furthe

[HACKERS] Pruning the TODO list

On 15 June 2012 03:10, Robert Haas wrote: > On Thu, Jun 14, 2012 at 11:39 AM, Amit Kapila wrote: >> I am planning to work on the below Todo list item... ... >> Suggest me if my understanding is correct? > > I guess my first question is: why do we need this?  There are lots of > things in the TOD