Hello,
On Wed, Aug 13, 2014 at 5:28 PM, Marti Raudsepp wrote:
> On Wed, Aug 13, 2014 at 9:44 AM, Albe Laurenz
> wrote:
> > Set wal_buffers to 16MB so that a whole WAL segment will fit.
>
> No need, wal_buffers is automatically tuned now. If your
> shared_buffers is 512MB or larger, wal_buffers
On 08/13/2014 11:10 PM, Patrick Dung wrote:
Thanks all for the help.
BTW, letter casing is just a preference.
Some people liked to use all small caps, some liked to use all big caps.
I sometimes found that mixed case is more meaningful for the filed (eg.
serialnumber vs serialNumber)
What is yo
On Thu, Aug 14, 2014 at 1:17 AM, John R Pierce wrote:
> On 8/13/2014 10:59 PM, Andrew Bartley wrote:
>
> I need this because it is a customer requirement. The underlying tables the
> api will query are dynamically created, they are period/content partitioned
> and distributed across multiple serv
On 14 August 2014 08:10, Patrick Dung wrote:
> Thanks all for the help.
>
> BTW, letter casing is just a preference.
> Some people liked to use all small caps, some liked to use all big caps.
> I sometimes found that mixed case is more meaningful for the filed (eg.
> serialnumber vs serialNumber)
Hello,
pg_get_functiondef() can be used quite easily by using a cast to regprocedure,
like this:
select pg_get_functiondef('public.foo(text, text, text)'::regprocedure);
However if the function is defined with an out parameter like this:
create or replace function foo(p1 text, p2 out te
Thomas Kellerer writes:
> Hello,
> pg_get_functiondef() can be used quite easily by using a cast to
> regprocedure, like this:
> select pg_get_functiondef('public.foo(text, text, text)'::regprocedure);
> However if the function is defined with an out parameter like this:
> create or re
Tom Lane wrote on 14.08.2014 17:33:
Leave out the OUT parameters altogether:
select pg_get_functiondef('public.foo(text, text)'::regprocedure);
Only IN parameters contribute to the function's identity; OUT parameters
are just a variant method of specifying its return type.
Ah, great. I didn't
I'm using Postgresql 9.0, and my pg_stat_activity.query seems to always be
showing when no query is being run.
Is there a way for it to show the last query, even if it was run a while
ago?
--
Si Chen
Open Source Strategies, Inc.
twitter.com/opentaps
Unify social, email, and business communicat
Hi everyone,
I had a question about some best practices. Our situation is that we want
to be able to clone a database server. Our single database server is hosted
in AWS, we take EBS snapshots every so often, and upload our WAL logs to
S3. We want to be able to start a new server from a snapshot,
Si Chen writes:
> I'm using Postgresql 9.0, and my pg_stat_activity.query seems to always be
> showing when no query is being run.
> Is there a way for it to show the last query, even if it was run a while
> ago?
More recent versions act that way. There is no way to make 9.0.x do it
short of p
I am working on implementing Selectivity hints feature in PostgreSQL 9.3.4.
I am working on this only for using it in my academic research. I have
decided to give selectivity information per relation as part of query like
shown below.
select * from lineitem, orders where l_extendedprice <=2400 and
We are running our own Postgres server on AWS as well (since amazon RDS doesn't
support read replicas yet)
In out case, simply having a streaming replication standby works - and we do
our pg_dump from that -- or simply snapshot the machine and then promote the
replica to master to use full data
Why don't you try using Barman? It allows you to take snapshots and do
PITR. Not to mention you can use it as it's intended purpose as a backup
engine.
-Joseph
On Thu, Aug 14, 2014 at 1:53 PM, Bill Mitchell wrote:
> We are running our own Postgres server on AWS as well (since amazon RDS
> does
13 matches
Mail list logo
