On 15 June 2012 03:10, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 14, 2012 at 11:39 AM, Amit Kapila amit.kap...@huawei.com 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?
Amit Kapila amit.kap...@huawei.com 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.
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
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
On Jun20, 2012, at 19:38 , Peter Geoghegan wrote:
On 20 June 2012 17:41, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 20, 2012 at 4:04 AM, Tatsuo Ishii is...@postgresql.org 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
On 21 June 2012 08:30, Peter Eisentraut pete...@gmx.net 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
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 Freundand...@anarazel.de
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
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 can only be
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 dependencies
On 21 June 2012 10:24, Florian Pflug f...@phlo.org 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
On Jun21, 2012, at 11:55 , Peter Geoghegan wrote:
On 21 June 2012 10:24, Florian Pflug f...@phlo.org 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 -
On 21 June 2012 11:40, Florian Pflug f...@phlo.org 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
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
To:
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 a bit
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
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 sequence as
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()
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
Simon Riggs si...@2ndquadrant.com writes:
On 21 June 2012 08:30, Peter Eisentraut pete...@gmx.net 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
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
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
On Wed, Jun 20, 2012 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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
On Wed, Jun 20, 2012 at 1:35 PM, Dickson S. Guedes lis...@guedesoft.net wrote:
2012/6/20 Magnus Hagander mag...@hagander.net:
On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp ma...@juffo.org wrote:
On Wed, Jun 20, 2012 at 12:18 PM, Magnus Hagander mag...@hagander.net
wrote:
(I do believe
On 21 June 2012 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 21 June 2012 08:30, Peter Eisentraut pete...@gmx.net 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
On Wed, Jun 20, 2012 at 1:15 PM, Alvaro Herrera
alvhe...@commandprompt.com 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.
On 21 June 2012 12:41, Andres Freund and...@2ndquadrant.com 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
Hi,
On Thursday, June 21, 2012 04:39:21 PM Simon Riggs wrote:
On 21 June 2012 12:41, Andres Freund and...@2ndquadrant.com wrote:
3)
Multi-Versioned catalog
Below are two possible implementation strategies for that concept
Advantages:
* Decoding is done on the master in an
On Thu, Jun 21, 2012 at 5:22 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp 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
On 21 June 2012 15:53, Andres Freund and...@2ndquadrant.com 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.
On Thursday, June 21, 2012 05:05:04 PM Simon Riggs wrote:
On 21 June 2012 15:53, Andres Freund and...@2ndquadrant.com 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
On 21 June 2012 16:13, Andres Freund and...@2ndquadrant.com wrote:
On Thursday, June 21, 2012 05:05:04 PM Simon Riggs wrote:
On 21 June 2012 15:53, Andres Freund and...@2ndquadrant.com wrote:
ISTM we should maintain a lookup table on target system that has the
minimal required information on
On Thursday, June 21, 2012 05:25:41 PM Simon Riggs wrote:
On 21 June 2012 16:13, Andres Freund and...@2ndquadrant.com wrote:
On Thursday, June 21, 2012 05:05:04 PM Simon Riggs wrote:
On 21 June 2012 15:53, Andres Freund and...@2ndquadrant.com wrote:
ISTM we should maintain a lookup table
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 has seen
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,
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:
There's
Edmon Begoli ebeg...@gmail.com 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
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 t...@sss.pgh.pa.us wrote:
Edmon Begoli ebeg...@gmail.com writes:
One of the Greenplum segments went down and it cannot recover because
PANIC
D'Arcy Cain da...@druid.net 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
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't
2012/6/21 Magnus Hagander mag...@hagander.net:
On Wed, Jun 20, 2012 at 1:35 PM, Dickson S. Guedes lis...@guedesoft.net
wrote:
2012/6/20 Magnus Hagander mag...@hagander.net:
On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp ma...@juffo.org wrote:
On Wed, Jun 20, 2012 at 12:18 PM, Magnus
On tor, 2012-06-21 at 16:19 +0200, Magnus Hagander wrote:
On Wed, Jun 20, 2012 at 1:35 PM, Dickson S. Guedes lis...@guedesoft.net
wrote:
2012/6/20 Magnus Hagander mag...@hagander.net:
On Wed, Jun 20, 2012 at 11:23 AM, Marti Raudsepp ma...@juffo.org wrote:
On Wed, Jun 20, 2012 at 12:18 PM,
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
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 causing
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
On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/6/8 Simon Riggs si...@2ndquadrant.com:
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
Greg Sabino Mullane g...@endpoint.com 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
On Wed, Feb 22, 2012 at 5:56 PM, Alexander Korotkov aekorot...@gmail.comwrote:
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
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 bug. The
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 and now
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
tables
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
alvhe...@commandprompt.com 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()
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.
@@ -788,7 +774,7 @@
On Thu, Jun 14, 2012 at 2:56 AM, Alexander Korotkov aekorot...@gmail.comwrote:
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
Alexander Korotkov aekorot...@gmail.com 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,
On 21 June 2012 19:13, Jaime Casanova ja...@2ndquadrant.com wrote:
On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/6/8 Simon Riggs si...@2ndquadrant.com:
I have a prototype that has some of these characteristics, so I see
our work as complementary.
At present,
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
On 20 June 2012 14:38, Andres Freund and...@2ndquadrant.com 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
Andrew Dunstan and...@dunslane.net 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
On 06/21/2012 06:25 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
Andrew Dunstan and...@dunslane.net writes:
On 06/21/2012 06:25 PM, Tom Lane wrote:
Hm, I guess I've forgotten that one?
See http://archives.postgresql.org/pgsql-hackers/2012-01/msg00561.php
I didn't understand that then, and I still don't. The ALTER TABLE
CLUSTER might need exclusive lock,
Peter Geoghegan pe...@2ndquadrant.com 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
On 22 June 2012 01:04, Tom Lane t...@sss.pgh.pa.us 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
On 06/21/2012 07:43 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 06/21/2012 06:25 PM, Tom Lane wrote:
Hm, I guess I've forgotten that one?
Seehttp://archives.postgresql.org/pgsql-hackers/2012-01/msg00561.php
I didn't understand that then, and I still don't. The ALTER
Andrew Dunstan and...@dunslane.net 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
(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
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
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
D'Arcy Cain da...@druid.net 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
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
70 matches
Mail list logo
