On Tue, Apr 20, 2010 at 10:41 PM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
I think committing a patch from a non-regular is a special case and
attaching the modified patch is reasonable in that case.
My 8.8 Richter ...
Or may be just mention the commit id for easy look up in
On Thu, 2010-04-22 at 08:57 +0300, Heikki Linnakangas wrote:
I think the assert is a good idea. If there's no real problem here,
the assert won't trip. It's just a safety precaution.
Right. And assertions also act as documentation, they are a precise and
compact way to document
btree_redo:
case XLOG_BTREE_DELETE:
/*
* Btree delete records can conflict with standby queries. You
* might think that vacuum records would conflict as well, but
* we've handled that already. XLOG_HEAP2_CLEANUP_INFO records
Can you still reproduce this or has some of the changes since then fixed
it? We never quite figured out the cause..
Erik Rijkers wrote:
On Thu, March 4, 2010 17:00, Erik Rijkers wrote:
in a 9.0devel, primary+standby, cvs from 2010.03.04 01:30
With three patches:
On Thu, 2010-04-22 at 10:24 +0300, Heikki Linnakangas wrote:
btree_redo:
case XLOG_BTREE_DELETE:
/*
* Btree delete records can conflict with standby queries. You
* might think that vacuum records would conflict as well, but
*
Simon Riggs wrote:
On Thu, 2010-04-22 at 10:24 +0300, Heikki Linnakangas wrote:
btree_redo:
/*
* Note that if all heap tuples were LP_DEAD then we will be
* returning InvalidTransactionId here. This seems very unlikely
* in practice.
*/
If none of the removed heap
On Thu, 2010-04-22 at 11:28 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2010-04-22 at 10:24 +0300, Heikki Linnakangas wrote:
btree_redo:
/*
* Note that if all heap tuples were LP_DEAD then we will be
* returning InvalidTransactionId here. This seems very unlikely
Simon Riggs wrote:
On Thu, 2010-04-22 at 11:28 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2010-04-22 at 10:24 +0300, Heikki Linnakangas wrote:
btree_redo:
/*
* Note that if all heap tuples were LP_DEAD then we will be
* returning InvalidTransactionId here. This
On Thu, 2010-04-22 at 11:56 +0300, Heikki Linnakangas wrote:
If none of the removed heap tuples were present anymore, we currently
return InvalidTransactionId, which kills/waits out all read-only
queries. But if none of the tuples were present anymore, the read-only
queries wouldn't have
Simon Riggs wrote:
On Thu, 2010-04-22 at 11:56 +0300, Heikki Linnakangas wrote:
If none of the removed heap tuples were present anymore, we currently
return InvalidTransactionId, which kills/waits out all read-only
queries. But if none of the tuples were present anymore, the read-only
On Thu, 2010-04-22 at 12:18 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2010-04-22 at 11:56 +0300, Heikki Linnakangas wrote:
If none of the removed heap tuples were present anymore, we currently
return InvalidTransactionId, which kills/waits out all read-only
queries.
On Wed, Apr 21, 2010 at 10:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Here's the fine patch. The actual code changes are simple and seem to
work as expected, but I struggled a bit with the phrasing of the
messages. Feel free to suggest improvements.
On Mon, Apr 19, 2010 at 10:52 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian br...@momjian.us wrote:
Peter Eisentraut wrote:
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
Basically, configure failed on their OpenBSD system because thread
On Sat, Apr 17, 2010 at 6:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote:
I will change the error message.
I gave a good deal of thought to trying to figure out a
On Wed, Apr 21, 2010 at 9:41 AM, Marc G. Fournier scra...@hub.org wrote:
On Wed, 21 Apr 2010, Robert Haas wrote:
Well, never mind that then. How about a beta next week?
I'm good for that ...
Anyone else want to weigh in for or against this?
...Robert
--
Sent via pgsql-hackers mailing list
On Thu, 22 Apr 2010, Robert Haas wrote:
On Wed, Apr 21, 2010 at 9:41 AM, Marc G. Fournier scra...@hub.org wrote:
On Wed, 21 Apr 2010, Robert Haas wrote:
Well, never mind that then. How about a beta next week?
I'm good for that ...
Anyone else want to weigh in for or against this?
We're
On Thu, Apr 22, 2010 at 12:18 PM, Marc G. Fournier scra...@hub.org wrote:
We're discussing scheduling on -core right now, triggered by your email, and
will put out a notice shortly ... although we did just do a back branch
release, we have a second one that has to be done, so we're trying to
On Sun, April 18, 2010 13:01, Simon Riggs wrote:
OK, I'll put a spinlock around access to the head of the array.
v2 patch attached
knownassigned_sortedarray.v2.diff applied to cvs HEAD (2010.04.21 22:36)
I have done a few smaller tests (scale 500, clients 1, 20):
init:
pgbench -h /tmp -p
While these can be handled at higher level, for example, by setting
up LDAP or as Hekki suggested, tricking DNS, the problem is that
I don't have control of how the user connect to the server. They
may not use LDAP. Solution like pgbouncer has advantages. User
just get one ip/port and
Hi, John,
The change will be on the libpq client side. I am not saying this is a general
solution for the distributed transaction/scale out. However, in many cases, it
is very useful. For example, in my case, I have about 100 departments each has
it own database. The balance machine can
Tom Lane escribió:
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
(You might want to look back at the archived discussions about how to
avoid storing entries for temp tables in these catalogs; that poses
many of the same
Erik Rijkers wrote:
This is the same behaviour (i.e. extreme slow standby) that I saw earlier (and
which caused the
original post, btw). In that earlier instance, the extreme slowness
disappeared later, after many
hours maybe even days (without bouncing either primary or standby).
Any
Greg Smith wrote:
Erik Rijkers wrote:
This is the same behaviour (i.e. extreme slow standby) that I saw
earlier (and which caused the
original post, btw). In that earlier instance, the extreme slowness
disappeared later, after many
hours maybe even days (without bouncing either primary or
On Thu, April 22, 2010 23:54, Mark Kirkwood wrote:
Greg Smith wrote:
Erik Rijkers wrote:
This is the same behaviour (i.e. extreme slow standby) that I saw
earlier (and which caused the
original post, btw). In that earlier instance, the extreme slowness
disappeared later, after many
hours
On Thu, 2010-04-22 at 20:39 +0200, Erik Rijkers wrote:
On Sun, April 18, 2010 13:01, Simon Riggs wrote:
any comment is welcome...
Please can you re-run with -l and post me the file of times
Please also rebuild using --enable-profile so we can see what's
happening.
Can you also try the
On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas robertmh...@gmail.com wrote:
One way we could fix this is use 2 bits rather than 1 for
XLogStandbyInfoMode. One bit could indicate that either
archive_mode=on or max_wal_senders0, and the second bit could
indicate that recovery_connections=on. If
Erik Rijkers wrote:
This is the same behaviour (i.e. extreme slow standby) that I saw earlier (and
which caused the
original post, btw). In that earlier instance, the extreme slowness
disappeared later, after many
hours maybe even days (without bouncing either primary or standby).
I have no
Given Relation rel, it looks to me like rel-rd_rel-relistemp will
always give the same answer as rel-rd_istemp. So why have both?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, April 22, 2010 09:53, Heikki Linnakangas wrote:
Can you still reproduce this or has some of the changes since then fixed
it? We never quite figured out the cause..
I don't know for sure:
Unfortunately, it does not happen always, or predictably.
The only thing that I established after
On Wed, Apr 21, 2010 at 2:54 AM, Greg Smith g...@2ndquadrant.com wrote:
Jim Nasby wrote:
I've also seen large shared buffer settings perform poorly outside of IO
issues, presumably due to some kind of internal lock contention. I tried
running 8.3 with 24G for a while, but dropped it back down
Robert Haas robertmh...@gmail.com writes:
Given Relation rel, it looks to me like rel-rd_rel-relistemp will
always give the same answer as rel-rd_istemp. So why have both?
Might be historical --- relistemp is pretty new.
regards, tom lane
--
Sent via pgsql-hackers
31 matches
Mail list logo
