Hello all,
We are exploring possible strategies on deploying PostgreSQL with
application which will store fairly much data (current implementation
stores around 345 GB of data, and it will be subject of up to 10 times
more data stored in the database).
Now, not to go into too much details to avo
On Wed, Apr 10, 2013 at 9:07 AM, Vedran Krivokuca wrote:
> 1) we can go with different instances of PostgreSQL service, let's say
> (for pure theory) 10 of them on the same HA cluster setup. Every
> instance would hold let's say 1/10th of that big recordset, and around
> 3.000 database tables (thi
On Wed, Apr 10, 2013 at 10:10 AM, Vedran Krivokuca wrote:
> On Wed, Apr 10, 2013 at 9:07 AM, Vedran Krivokuca
> wrote:
> > 1) we can go with different instances of PostgreSQL service, let's say
> > (for pure theory) 10 of them on the same HA cluster setup. Every
> > instance would hold let's say
All,
We have to migrate to a new hardware infrastructure and we want to use a
Postgres version of EnterpriseDB in the new hardware infrastructure.
On the old infrastructure, postgres comes from postgresql.org
The version of postgres on the old and new infrastructure is the same, 9.1
(old 9.1.5
I'd agree, certainly in my experiences.
You need to ensure OS parameters such as the max open files
(fs.file-max if we're talking Linux) is set appropriately. Baring
in mind each user will have an open file on each underlying
datafile for the databas
Yes, the log shipping/streaming replication is possible between these
versions as the major versions are same i.e 9.1.X
**
*Thanks & Regards,*
*** *
*Prashanth Ranjalkar*
*Database Consultant & Architect*
*Skype:prashanth.ranjalkar*
*www.postgresdba.net*
On Wed, Apr 10, 2013 at 1:58 PM, Herman
Hello,
Yes, it's possible, but I recommend you to update the current version
coming soon.
Regards
2013/4/10 Prashanth Ranjalkar
> Yes, the log shipping/streaming replication is possible between these
> versions as the major versions are same i.e 9.1.X
>
> **
> *Thanks & Regards,*
> *** *
> *P
On Wed, Apr 10, 2013 at 10:43 AM, Dale Betts wrote:
>
> I'd agree, certainly in my experiences.
>
> You need to ensure OS parameters such as the max open files (fs.file-max if
> we're talking
> Linux) is set appropriately. Baring in mind each user will have an open file
> on each
> underlying da
Every table or index is created in the form of OS files therefore max open
files need to be set appropriately in order to achieve the larger table
count. There would be no limitation for creation of tables in PostgreSQL
and performance would be the major criteria as catalogs get overburdened.
**
*
On 10-04-2013 13:58, Herman Pool wrote:
All,
We have to migrate to a new hardware infrastructure and we want to use
a Postgres version of EnterpriseDB in the new hardware infrastructure.
On the old infrastructure, postgres comes from postgresql.org
The version of postgres on the old and new i
Hi all,
Can someone please point me to detailed documentation on how to secure/encrypt
connections between PGBouncer and Postgresql database (version 8.4.3)?
Thanks in advance!
Bhanu M. Gandikota
Cell: (415) 420-7740
AFAIK, you have to use stunnel to do it (which is not hard to setup, but
it almost makes you wonder whether you should go to the trouble of using
pgbouncer at all).
I just went through this and I ended up just testing direct connections
through the tunnel without pgbouncer in the middle. It w
On Wed, Apr 10, 2013 at 11:06:32AM -0700, Bhanu Murthy wrote:
> Hi all,
>
> Can someone please point me to detailed documentation on how to
> secure/encrypt connections between PGBouncer and Postgresql database (version
> 8.4.3)?
>
> Thanks in advance!
>
> Bhanu M. Gandikota
> Cell: (415)
Hi,
Could some please explain what these warnings mean in postgres.
I see these messages a lot when automatic vacuum runs.
1 tm:2013-04-10 11:39:20.074 UTC db: pid:13766 LOG: automatic vacuum
of table "DB1.nic.pvxt": could not (re)acquire exclusive lock for truncate
scan
1 tm:2013-04
That's just that some other process has some DML going on in the table that is
supposed to be truncated. No lock, no truncate.
HTH,
Bambi.
From: pgsql-admin-ow...@postgresql.org
[mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Nik Tek
Sent: Wednesday, April 10, 2013 4:58 PM
To: pgsql-per
Hi Bambi,
Thank you the prompt reply.
This table is very volatile, lot of inserts/updates happen on this
tables(atleast 20~30 inserts/min).
When auto vacuum tries to run on this table, I get this warning.
Is there a way, I force it to happen, because the table/indexes statistics
are becoming sta
Not sure this is the right list to vent about this but here you go:
I) select regexp_replace('BEFORE.AFTER','(.*)\..*','\1','g') "Substring"
II) select regexp_replace('BEFORE.AFTER','(.*)\\..*','\\1','g') "Substring"
Executing (II) against pg 8.4.4 or 9.0.4 yields 'BEFORE', but in order for
9.1.7
On Wed, Apr 10, 2013 at 4:59 PM, Armin Resch wrote:
> Not sure this is the right list to vent about this but here you go:
>
> I) select regexp_replace('BEFORE.AFTER','(.*)\..*','\1','g') "Substring"
> II) select regexp_replace('BEFORE.AFTER','(.*)\\..*','\\1','g') "Substring"
>
> Executing (II) a
Thx for clarification, Craig. Your Perl snippet comes in handy, too.
-ar
On Apr 10, 2013, at 8:08 PM, Craig James wrote:
> On Wed, Apr 10, 2013 at 4:59 PM, Armin Resch wrote:
>> Not sure this is the right list to vent about this but here you go:
>>
>> I) select regexp_replace('BEFORE.AFTER','(
Hello everybody:
After I switch the slave to the master , I can not get the stats
information by the below sql and the pg_stat_reset() does not work on the New
Master,
And I vacuum by hand,it's still not work! I need some help.Could you give me
any idea?
the stat sql:
SELECT st.re
On Thursday, April 11, 2013, X.H.WANG <82661...@qq.com> wrote:
> Hello everybody:
>
> After I switch the slave to the master , I can not get the stats
> information by the below sql and the pg_stat_reset() does not work on the
> New Master,
> And I vacuum by hand,it's still not work! I ne
21 matches
Mail list logo
