On Thu, July 31, 2008 10:07 am, Chris wrote:
> Garg, Manjit wrote:
> Check out slony (http://slony.info/) - it's a master->multiple slave
> replication system and seems to work pretty well.
You can also try SkyTools (http://pgfoundry.org/projects/skytools/) - it's
far simpler to use and to manage
On Tue, July 8, 2008 3:14 am, spellberg_robert wrote:
> at the risk of ridicule, i don't read release notes online.
> i read them when i unpack a tarball.
Consider yourself ridiculed! :))
I remember years ago (must be 6.x days) moaning about (to the pg people,
either in the list, or as an email t
On Mon, June 30, 2008 9:45 pm, Tom Lane wrote:
> "Henry - Zen Search SA" <[EMAIL PROTECTED]> writes:
>> The problem was this: a silly SQL error (misuse of OR and missing
>> parentheses) resulted in a massive result set which resulted in OOM - if
>> the sel
On Mon, June 30, 2008 4:51 pm, Tom Lane wrote:
> The string "out of balance" appears nowhere in the PG 8.2.x sources.
> So I suppose it must have come from some add-on code, or perhaps got
> inserted on the client side. What data type is that column, and what
> non-core code is involved?
I have n
Hello,
PG: 8.2.7 (then upgraded to 8.2.9 to try and resolve with same result)
Linux 2.6.25
Our selects which have run normally for a very long time suddenly started:
- consuming all memory.
- crashing (oom) if the select was run directly.
- producing "out of balance" results in one of the colum
On Tue, June 24, 2008 8:41 am, Adrian Moisey wrote:
> Hi
>
> We have a 100GB database (16GB dumped) running on 8.2.
>
> Since the bandwidth in South Africa isn't that freely available it is
> difficult for us to get a new copy of out DB in our office (our fastest
> link in the office is 4Mbps).
>
>
On Fri, June 13, 2008 7:05 pm, Tom Lane wrote:
> How soon is "bang"?
I'll run it again and post back.
> The memory overhead per subtransaction is
> not zero, though I think it's fairly small if you don't have any
> triggers pending as a result of the insert.
Two triggers are fired for each inser
On Mon, June 2, 2008 6:53 pm, Tom Lane wrote:
> I don't think your problem has anything to do with dblink per se.
> The repeated begin/exception blocks are apparently managing to leak
> some memory per iteration. I can't tell whether this represents
> a known (and perhaps already fixed) bug; it ve
