Robert Haas 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 mailing list (pgs
On Wed, Apr 21, 2010 at 2:54 AM, Greg Smith 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 to our defa
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 aft
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:
http://www.postgresql.org/mailpref/pgsql-h
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
On Fri, Apr 23, 2010 at 1:04 AM, Robert Haas 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_senders>0, and the second bit could
> indicate that recovery_connections=on. If the second bit is
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 enclo
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
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 sta
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 pos
Tom Lane escribió:
> Robert Haas writes:
> > On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane 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 issues.)
>
> > Do you happen to
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 just
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 everyt
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 /
On Thu, Apr 22, 2010 at 12:18 PM, Marc G. Fournier 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
> balance sched
On Thu, 22 Apr 2010, Robert Haas wrote:
On Wed, Apr 21, 2010 at 9:41 AM, Marc G. Fournier 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 discussing sche
On Wed, Apr 21, 2010 at 9:41 AM, Marc G. Fournier 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 (pgsql-hac
On Sat, Apr 17, 2010 at 6:52 PM, Robert Haas wrote:
> On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs 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 cleaner
>>> solution to this
On Mon, Apr 19, 2010 at 10:52 AM, Robert Haas wrote:
> On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian 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
>>> > safety is on but the libx
On Wed, Apr 21, 2010 at 10:01 PM, Tom Lane wrote:
> Robert Haas 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.
>
> Stick with the original wordin
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
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, t
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
> que
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 InvalidTrans
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 se
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
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
> >
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:
>>
>> new_smart_shutdo
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 reco
29 matches
Mail list logo
