On Mon, Apr 4, 2011 at 12:35 AM, Shoaib Mir wrote:
> From my limited knowledge I think we need a shared location where the master
> node is putting the WAL files in and the slave nodes also look at the same
> folder to get new WAL logs to replay the files. Now if we cant have that
> shared locatio
Hi Everyone,
I am trying to setup Hot Standby for a customer site and got a small
question about the setup:
>From my limited knowledge I think we need a shared location where the master
node is putting the WAL files in and the slave nodes also look at the same
folder to get new WAL logs to replay
On 04/04/11 12:43, Annamalai Gurusami wrote:
> What we are trying to achieve is that a single application can work as
> an ordinary client or an embedded client.
That makes a lot of sense, and would be useful for testing too.
> I have no clue as to why you have recommended BerkeleyDB in this
> c
On 2 April 2011 11:17, John R Pierce wrote:
> what you describe is neither postgres nor SQL
>
> perhaps you should look at a storage engine like BerkeleyDB
I hope that not everybody dismisses this mail thread because of the
above response. We are deriving our product from pgsql. And since we
a
On Sun, Apr 3, 2011 at 2:39 PM, Joshua D. Drake wrote:
> On Sat, 2 Apr 2011 19:26:56 +0200, "Henry C." wrote:
>> On Sat, April 2, 2011 14:17, Jens Wilke wrote:
>>> Nevertheless since at least 8.4 IMO there's no need to bother with
>>> manual vacuum any more.
>
> Uhh, this is entirely untrue. Ther
On Sat, 2 Apr 2011 19:26:56 +0200, "Henry C." wrote:
> On Sat, April 2, 2011 14:17, Jens Wilke wrote:
>> Nevertheless since at least 8.4 IMO there's no need to bother with
>> manual vacuum any more.
Uhh, this is entirely untrue. There are plenty of cases where 8.4
autovacuum can't cut it.
>
> S
After dumping a database (pg_dump -F c database > dump), trying to restore
it (pg_restore dump) gives:
> pg_restore: [archiver (db)] Error from TOC entry 2463; 0 58451 TABLE DATA
table user
> pg_restore: [archiver (db)] COPY failed: ERROR: invalid byte sequence for
encoding "UTF8": 0xe3273a
> HIN
Sven Haag wrote on 03.04.2011 16:13:
Original-Nachricht
Datum: Sun, 03 Apr 2011 15:37:17 +0200
Von: Thomas Kellerer
An: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] Table lock while adding a column and clients are logged
in
Alban Hertroys wrote on 03.04.2011 11:17:
Original-Nachricht
> Datum: Sun, 03 Apr 2011 15:37:17 +0200
> Von: Thomas Kellerer
> An: pgsql-general@postgresql.org
> Betreff: Re: [GENERAL] Table lock while adding a column and clients are
> logged in
> Alban Hertroys wrote on 03.04.2011 11:17:
> > On 2 Apr 2011, at 12:44,
Alban Hertroys wrote on 03.04.2011 11:17:
On 2 Apr 2011, at 12:44, Thomas Kellerer wrote:
Even after a plain SELECT you should issue a COMMIT (or ROLLBACK)
to end the transaction that was implicitely started with the
SELECT.
Sorry, but you're wrong about that. A statement that implicitly
star
Alban Hertroys wrote on 03.04.2011 11:31:
On 3 Apr 2011, at 11:22, Alban Hertroys wrote:
Oracle and SQL server don't "suffer" from this because they do not
handle DDL statements transactionally (I could be mistaken about
SQL server, I don't know it all that well).
I forgot to mention, if you
On Sat, April 2, 2011 22:30, Tom Lane wrote:
>> Have you tried upping the aggressiveness of autovacuum?
>>
>
> I'm wondering about poor selection of the cost_delay settings in
> particular. It's quite easy to slow autovacuum to the point that it takes
> forever to do anything.
It's been on the de
On 3 Apr 2011, at 11:22, Alban Hertroys wrote:
> Oracle and SQL server don't "suffer" from this because they do not handle DDL
> statements transactionally (I could be mistaken about SQL server, I don't
> know it all that well).
I forgot to mention, if you perform DDL in Oracle all your curren
On 2 Apr 2011, at 11:09, Sven Haag wrote:
> hello pg fans,
>
> we have an application that communicates via ODBC directly to the postgres
> database.
>
> if i'm trying to add an additional column to a table in pgadmin while clients
> are logged in, pgadmin hangs. only if all cients are logged
On 2 Apr 2011, at 12:44, Thomas Kellerer wrote:
> Even after a plain SELECT you should issue a COMMIT (or ROLLBACK) to end the
> transaction that was implicitely started with the SELECT.
Sorry, but you're wrong about that. A statement that implicitly starts a
transaction also implicitly COMMIT
15 matches
Mail list logo
