On 14.02.2012 04:57, Dan Ports wrote:
Looking over the SSI 2PC code recently, I noticed that I overlooked a
case that could lead to non-serializable behavior after a crash.
When we PREPARE a serializable transaction, we store part of the
SERIALIZABLEXACT in the statefile (in addition to the
(2012/02/14 15:15), Shigeru Hanada wrote:
(2012/02/13 20:50), Etsuro Fujita wrote:
The patches have been applied, but role-related regression tests failed
in my environment. I fixed it in a similar fashion of
/src/test/regress/sql/foreign_data.sql. Please find attached a updated
patch for
On Sat, Feb 11, 2012 at 11:34 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Wed, Feb 8, 2012 at 1:01 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
On Sun, Jan 15, 2012 at 4:59 PM, Jeff Janes jeff.ja...@gmail.com wrote:
The attached patch allows it to reuse that memory. On my meager
system
2012/2/14 Robert Haas robertmh...@gmail.com:
On Mon, Feb 13, 2012 at 7:51 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I rebased the patch due to the updates of pg_proc.h.
Please see the newer one. Thanks,
Thanks, committed. I think, though, that some further adjustment is
needed here,
(2012/02/14 17:40), Etsuro Fujita wrote:
OK. But my question was about the PlanForeignScan API.
Sorry for misunderstanding. :(
As discussed at
that thread, it would have to change the PlanForeignScan API to let the
FDW generate
(2012/02/14 19:42), Shigeru Hanada wrote:
(2012/02/14 17:40), Etsuro Fujita wrote:
As discussed at
that thread, it would have to change the PlanForeignScan API to let the
FDW generate multiple paths and dump them all to add_path instead
Excerpts from Jaime Casanova's message of mar feb 14 04:10:58 -0300 2012:
On Thu, Feb 2, 2012 at 2:32 AM, Magnus Hagander mag...@hagander.net wrote:
I haven't looked through the code in detail, but one direct comment:
do we really need/want to send this through the stats collector? It
On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I could not find out where is the origin of grammer conflicts, although
it does not conflict with any options within ALTER FUNCTION.
Do you think the idea of ALTER ... NOT LEAKPROOF should be
integrated within v9.2
2012/2/14 Robert Haas robertmh...@gmail.com:
On Tue, Feb 14, 2012 at 4:55 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I could not find out where is the origin of grammer conflicts, although
it does not conflict with any options within ALTER FUNCTION.
Do you think the idea of ALTER ... NOT
Shigeru Hanada shigeru.han...@gmail.com writes:
(2012/02/14 17:40), Etsuro Fujita wrote:
As discussed at
that thread, it would have to change the PlanForeignScan API to let the
FDW generate multiple paths and dump them all to add_path instead of
returning a FdwPlan struct.
Multiple valuable
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 14.02.2012 04:57, Dan Ports wrote:
Looking over the SSI 2PC code recently, I noticed that I
overlooked a case that could lead to non-serializable behavior
after a crash.
When we PREPARE a serializable transaction, we store part
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
This would tend to be more than a little inconvenient until the
prepared statements pending at crash or shutdown were all
committed or rolled back.
[sigh]
Probably obvious, but to avoid confusion:
s/prepared statements/prepared
On Mon, Feb 13, 2012 at 09:54:06PM -0500, Bruce Momjian wrote:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Instead of or in addition to a fixed number operations per test, maybe
we should cut off each test after a certain amount of
Last year at this time, I was investigating things like ext3 vs xfs, how
well Linux's dirty_bytes parameter worked, and how effective a couple of
patches were on throughput latency. The only patch that ended up
applied for 9.1 was for fsync compaction. That was measurably better in
terms of
On 02/14/2012 01:45 PM, Greg Smith wrote:
scale=1000, db is 94% of RAM; clients=4
Version TPS
9.0 535
9.1 491 (-8.4% relative to 9.0)
9.2 338 (-31.2% relative to 9.1)
A second pass through this data noted that the maximum number of buffers
cleaned by the background writer is =2785 in
On Tue, Feb 07, 2012 at 07:58:28PM -0500, Bruce Momjian wrote:
I was initially concerned that tuning advice in this part of the docs
would look out of place, but now see the 25% shared_buffers
recommentation, and it looks fine, so we are OK. (Should we caution
against more than 8GB of shared
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized buffer. That should
be true because we're inserting index tuples from up to down while
splits propagate from down to up.
if (!found)
{
/*
* Node buffer should exist at
Andrew Dunstan and...@dunslane.net writes:
On 02/13/2012 11:00 AM, Tom Lane wrote:
This is surely fixable by passing a bit more information down. If you
(Andrew) have something that covers everything but this issue, pass it
over and I'll take a whack at it.
What I have fixes one of the
Alexander Korotkov aekorot...@gmail.com writes:
ITSM, I found the problem. This piece of code is triggering an error. It
assumes each page of corresponding to have initialized buffer. That should
be true because we're inserting index tuples from up to down while
splits propagate from down to
Bruce Momjian br...@momjian.us writes:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
+1, I was about to suggest the same thing. Running any of these tests
for a fixed number of iterations will result in drastic degradation of
accuracy as soon as the machine's behavior changes
On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
+1, I was about to suggest the same thing. Running any of these tests
for a fixed number of iterations will result in drastic
On Tue, Feb 14, 2012 at 10:04:15AM +0200, Heikki Linnakangas wrote:
Perhaps it would be simpler to add the extra information to the commit
records of the transactions that commit after the first transaction is
prepared. In the commit record, you would include a list of prepared
transactions
On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 14.02.2012 04:57, Dan Ports wrote:
The easiest answer would be to just treat every prepared
transaction found during recovery as though it had a conflict in
and
On 13/02/2012 08:26, Greg Smith wrote:
On 02/11/2012 08:14 PM, Gaetano Mendola wrote:
The trend is to have server capable of running CUDA providing GPU via
external hardware (PCI Express interface with PCI Express switches),
look for example at PowerEdge C410x PCIe Expansion Chassis from DELL.
On Wed, Feb 15, 2012 at 01:35:05AM +0200, Marko Kreen wrote:
On Tue, Feb 14, 2012 at 05:59:06PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, Feb 13, 2012 at 08:28:03PM -0500, Tom Lane wrote:
+1, I was about to suggest the same thing. Running any of these tests
Hi,
I am checking a performance problem encountered after porting old embeded
DB to postgreSQL. While the system is real-time sensitive, we are
concerning for per-query cost. In our environment sequential scanning
(select * from ...) for a table with tens of thousands of record costs 1 -
2
On 02/14/2012 05:39 PM, Tom Lane wrote:
OK, I fixed this up and committed it. I made some cosmetic changes
(the most notable being that the definition of RowExpr is really
changing here, and so should its comment). The adjust_appendrel_attrs
situation was fixed by passing in the PlannerInfo,
On Fri, Feb 10, 2012 at 10:30 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
[ new patch ]
I spent quite a bit of time looking at this today - the patch
specifically, and the issue of making quicksort fast more generally.
It seemed to me that if we're going to have separate copies of the
Hi,
I have tried unix domain socket and the performance is similar with TCP
socket. It is MIPS architecture so memory copy to/from kernel can occupy
much time, and apparently using unit domain socket has no difference than
TCP in terms of memory copy.
But it is still unbelievable for the
29 matches
Mail list logo
