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 documen
On Tue, Apr 20, 2010 at 10:41 PM, Alvaro Herrera 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 the git log.
Thanks,
Robert Haas wrote:
> On Wed, Apr 21, 2010 at 9:37 AM, Simon Riggs wrote:
>> On Wed, 2010-04-21 at 15:27 +0300, Heikki Linnakangas wrote:
>>
>>> Given the discussion about the cyclic nature of XIDs, it would be good
>>> to add an assertion that when a new XID is added to the array, it is
>>>
>>> a)
feng tian wrote:
> Hi,
>
> I want to load balance a postgres server on 4 physical machines, say
> 127.0.0.11-14. I can set up a pgbouncer on 127.0.0.10 and connection pooling
> to my four boxes. However, the traffic from/to clients will go through an
> extra hop. Another way to do this, is t
On Fri, 2010-04-16 at 23:18 -0700, Scott Bailey wrote:
> Well I've been doing a lot of work with range abstract data types in
> Oracle lately. And I've got to say that the OO features in Oracle make
> it really nice. Of course its Oracle, so its like a half baked OO in
> cobol syntax, lol. But I
On Thu, Apr 22, 2010 at 11:01 AM, 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
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 wording? I don't really see a need to change it.
Takahiro Itagaki wrote:
> Revised patch attached. Please test it.
I applied this version of the patch.
Please check wheter the bug is fixed and any buildfarm failures.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Wed, Apr 21, 2010 at 1:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> ...shouldn't we move the "tests", plural, rather than just the one?
>> It seems right to reject new SR connections during shutdown.
>
> Yeah; you'd also need to adjust both of them to consider am_walsender.
> (IOW, we want
On Apr 20, 2010, at 10:03 PM, feng tian wrote:
> Another way to do this, is to send the client an "redirect" message. When
> client connect to 127.0.0.10, instead of accepting the connection, it can
> reply to client telling it to reconnect to one of the server on
> 127.0.0.11-14.
ISTM that
feng tian wrote:
Hi,
I want to load balance a postgres server on 4 physical machines, say
127.0.0.11-14. I can set up a pgbouncer on 127.0.0.10 and connection
pooling to my four boxes. However, the traffic from/to clients will
go through an extra hop. Another way to do this, is to send the
I wrote:
> Well, if there are no other comments, I'll push forward with the fix
> proposed here:
> http://archives.postgresql.org/pgsql-hackers/2009-11/msg00531.php
Done. I did not make the change I speculated about of allowing
completely unknown variables (those that don't even match
custom_vari
Hi,
I want to load balance a postgres server on 4 physical machines, say
127.0.0.11-14. I can set up a pgbouncer on 127.0.0.10 and connection pooling
to my four boxes. However, the traffic from/to clients will go through an
extra hop. Another way to do this, is to send the client an "redire
On Tue, 2010-04-20 at 19:06 -0400, Tom Lane wrote:
> Should we change this? It seems to me to be a good thing on security
> grounds if replication connections can't be made through a generic
> pg_hba entry.
That's a good change.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsq
2010/4/21 Jehan-Guillaume (ioguix) de Rorthais :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/04/2010 18:10, David Fetter wrote:
>> On Sat, Apr 03, 2010 at 03:17:30PM +0200, Markus Schiltknecht wrote:
>>> Hi,
>>>
>>> Michael Tharp wrote:
I have been spending a little time making
Robert Haas writes:
> ...shouldn't we move the "tests", plural, rather than just the one?
> It seems right to reject new SR connections during shutdown.
Yeah; you'd also need to adjust both of them to consider am_walsender.
(IOW, we want to treat SR connections as non-superuser for both tests.)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2010 18:10, David Fetter wrote:
> On Sat, Apr 03, 2010 at 03:17:30PM +0200, Markus Schiltknecht wrote:
>> Hi,
>>
>> Michael Tharp wrote:
>>> I have been spending a little time making the internal SQL parser
>>> available to clients via a C-lan
On Wed, Apr 21, 2010 at 12:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> Thanks for the heads up. It doesn't look hard to put a similar test
>> in the walsender code path, but is there any reason to duplicate the
>> code? Seems like we might be able to just put this test (with the
>> necessar
On Wed, 2010-04-21 at 11:53 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Wed, 2010-04-21 at 14:37 +0300, Heikki Linnakangas wrote:
> >> I also think we shouldn't be fiddling with this at this stage in the
> >> release cycle.
>
> > OK, but not because I see a problem with the technique.
>
Robert Haas writes:
> Thanks for the heads up. It doesn't look hard to put a similar test
> in the walsender code path, but is there any reason to duplicate the
> code? Seems like we might be able to just put this test (with the
> necessary modification) right before this comment:
Hm, actually
On Tue, Apr 20, 2010 at 7:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Current logic says we hit the connection limit if:
>
>> if (!am_superuser &&
>> ReservedBackends > 0 &&
>> !HaveNFreeProcs(ReservedBackends))
>
>> Couldn't we just change this to:
>
>
2010/4/20 Pavel :
> For now I know it is not commitable in actual state, but for my thesis it is
> enough and I know it will not be commitable with this design at all. In case
> of GSoC it will depends on the time I will be able to spend on it, if I will
> consider some other design.
I am not sure
Simon Riggs writes:
> On Wed, 2010-04-21 at 14:37 +0300, Heikki Linnakangas wrote:
>> I also think we shouldn't be fiddling with this at this stage in the
>> release cycle.
> OK, but not because I see a problem with the technique.
You made that plain already, but you have not convinced anyone e
On Apr 21, 2010, at 16:49 , Simon Riggs wrote:
> On Wed, 2010-04-21 at 16:22 +0200, marcin mank wrote:
>
>> Is that not a good idea that (at least for dev-builds, like with
>> enable-cassert) the xid counter start at like 2^31 - 1000 ? It could
>> help catch some bugs.
>
> It is a good idea, I'm
On Wed, Apr 21, 2010 at 10:12 AM, Simon Riggs wrote:
> On Wed, 2010-04-21 at 09:51 -0400, Robert Haas wrote:
>> >
>> > Adding an assertion isn't going to do much because it's unlikely anybody
>> > is going to be running for 2^31 transactions with asserts enabled.
>> >
>
>> I think the assert is a
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 know what a good search term migh
On Wed, 2010-04-21 at 16:22 +0200, marcin mank wrote:
> Is that not a good idea that (at least for dev-builds, like with
> enable-cassert) the xid counter start at like 2^31 - 1000 ? It could
> help catch some bugs.
It is a good idea, I'm sure that would help catch bugs.
It wouldn't help here be
On Wed, Apr 21, 2010 at 4:12 PM, Simon Riggs wrote:
> On Wed, 2010-04-21 at 09:51 -0400, Robert Haas wrote:
>> >
>> > Adding an assertion isn't going to do much because it's unlikely anybody
>> > is going to be running for 2^31 transactions with asserts enabled.
>> >
>
>> I think the assert is a g
On Wed, 2010-04-21 at 09:51 -0400, Robert Haas wrote:
> >
> > Adding an assertion isn't going to do much because it's unlikely anybody
> > is going to be running for 2^31 transactions with asserts enabled.
> >
> I think the assert is a good idea. If there's no real problem here,
> the assert won'
On Wed, Apr 21, 2010 at 8:20 AM, Heikki Linnakangas
wrote:
> The locking seems overly complex to me.
I tend to agree.
! /*
!* Callers must hold either ProcArrayLock in Exclusive mode or
!* ProcArrayLock in Shared mode *and* known_assigned_xids_lck
!* to update these
On Wed, Apr 21, 2010 at 9:37 AM, Simon Riggs wrote:
> On Wed, 2010-04-21 at 15:27 +0300, Heikki Linnakangas wrote:
>
>> Given the discussion about the cyclic nature of XIDs, it would be good
>> to add an assertion that when a new XID is added to the array, it is
>>
>> a) larger than the biggest va
On Wed, 21 Apr 2010, Robert Haas wrote:
Well, never mind that then. How about a beta next week?
I'm good for that ...
Marc G. FournierHub.Org Hosting Solutions S.A.
scra...@hub.org http://www.hub.org
Yahoo:yscrappySkype: h
On Wed, 2010-04-21 at 15:27 +0300, Heikki Linnakangas wrote:
> Given the discussion about the cyclic nature of XIDs, it would be good
> to add an assertion that when a new XID is added to the array, it is
>
> a) larger than the biggest value already in the array
> (TransactionIdFollows(new, head)
On Wed, 2010-04-21 at 15:20 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sun, 2010-04-18 at 08:24 +0100, Simon Riggs wrote:
> >> On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote:
> >>> Simon Riggs writes:
> What I'm not clear on is why you've used a spinlock everywhere when o
Simon Riggs wrote:
> On Sun, 2010-04-18 at 08:24 +0100, Simon Riggs wrote:
>> On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote:
>>> Simon Riggs writes:
What I'm not clear on is why you've used a spinlock everywhere when only
weak-memory thang CPUs are a problem. Why not have a weak-memo
Simon Riggs wrote:
> On Sun, 2010-04-18 at 08:24 +0100, Simon Riggs wrote:
>> On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote:
>>> Simon Riggs writes:
What I'm not clear on is why you've used a spinlock everywhere when only
weak-memory thang CPUs are a problem. Why not have a weak-memo
On Tue, Apr 20, 2010 at 1:53 PM, Marc G. Fournier wrote:
> On Tue, 20 Apr 2010, Robert Haas wrote:
>
>> /me pushes luck
>>
>> And how about a set of back-branch releases while we're at it?
>
> We tend to try and avoid overlapping a "release" with a "beta" to avoid
> confusion ... but didn't we jus
On Wed, 2010-04-21 at 14:37 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2010-04-20 at 21:03 -0400, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> Following patch writes a new WAL record that just says "copy foo to
> >>> newts" and during replay we flush buffers and then re-ex
Simon Riggs wrote:
> On Tue, 2010-04-20 at 21:03 -0400, Tom Lane wrote:
>> Simon Riggs writes:
>>> Following patch writes a new WAL record that just says "copy foo to
>>> newts" and during replay we flush buffers and then re-execute the copy
>>> (but only when InArchiveRecovery). So the copy happe
39 matches
Mail list logo
