synchronous_commit is "on"
Thanks
VB
On Thu, Feb 2, 2012 at 12:31 PM, Raghavendra <
raghavendra@enterprisedb.com> wrote:
> What is the value of synchronous_commit ?
>
> ---
> Regards,
> Raghavendra
> EnterpriseDB Corporation
> Blog: http://raghavt.blogspot.com/
>
>
>
> On Thu, Feb 2, 2012 at
Its because of pg_upgrade, 'in place' upgrade capabilities that are in
pg since 8.4. For that to work you need both old and new (current) set
of postgresql binaries. Etc.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgre
What is the value of synchronous_commit ?
---
Regards,
Raghavendra
EnterpriseDB Corporation
Blog: http://raghavt.blogspot.com/
On Thu, Feb 2, 2012 at 12:21 PM, Venkat Balaji wrote:
> Hello,
>
> I was testing the Postgres-9.1.1 synchronous streaming replication on our
> UAT system.
>
> Without
Hello,
I was testing the Postgres-9.1.1 synchronous streaming replication on our
UAT system.
Without synchronous replication, everything was working fine.
But, when i enabled synchronous_replication_names='*', the "create table"
started hanging for long time.
When i pressed "Ctrl+C" i got the f
Yeah, it's strange because we definitely have periods of high iowait but
this is not when the locks are happening. If I could correlate it directly
to that it would be so much easier. Thanks again for the response!
On Wed, Feb 1, 2012 at 8:42 PM, Alan Hodgson wrote:
> On Wednesday, February 01
On Wednesday, February 01, 2012 05:13:15 PM Christopher Opena wrote:
> Do you mean 6-12% of total iowait, or per cpu? Our average iowait in the
> last week is 34.31% of a total 1600% with an average idle of 1451.76%. Our
> iowait *does* spike occasionally (today it went up to 148.01%) but it
> do
Do you mean 6-12% of total iowait, or per cpu? Our average iowait in the
last week is 34.31% of a total 1600% with an average idle of 1451.76%. Our
iowait *does* spike occasionally (today it went up to 148.01%) but it
doesn't coincide with the lock happening. At the time of the lock we were
at 1
Hi,
On 2 February 2012 11:38, Christopher Opena wrote:
> We've been running into some very strange issues of late with our PostgreSQL
> database(s). We have an issue where a couple of queries push high CPU on a
> few of our processors and the entire database locks (reads, writes, console
> canno
It was installed from pgrpms.org's repository.
On Wed, Feb 1, 2012 at 4:55 PM, Carlos Mennens wrote:
> On Wed, Feb 1, 2012 at 7:51 PM, Christopher Opena
> wrote:
> > It's CentOS 5.5, PostgreSQL version 9.0.4 (x86_64).
>
> That seems extremely bleeding edge for CentOS. Did you compile this
> pack
Hi all,
Problem resolved. The postgres server now starts automatically when my OSX
Lion machine reboots. Hopefully the following info will be useful for anyone
contemplating a macports installation of PostgreSQL.
The biggest impediment to getting the relaunch behavior I expected was from
in
On Wed, Feb 1, 2012 at 7:38 PM, Christopher Opena
wrote:
> > Hello folks,
> >
> > We've been running into some very strange issues of late with our
> > PostgreSQL database(s). We have an issue where a couple of queries
> > push high CPU on a few of our processors and the entire database locks
On Wed, Feb 1, 2012 at 7:51 PM, Christopher Opena wrote:
> It's CentOS 5.5, PostgreSQL version 9.0.4 (x86_64).
That seems extremely bleeding edge for CentOS. Did you compile this
package from source RPM or some 3rd party package maintainer for
PostgreSQL?
--
Sent via pgsql-general mailing list
It's CentOS 5.5, PostgreSQL version 9.0.4 (x86_64).
On Wed, Feb 1, 2012 at 4:44 PM, Carlos Mennens wrote:
> On Wed, Feb 1, 2012 at 7:38 PM, Christopher Opena
> wrote:
> > Hello folks,
> >
> > We've been running into some very strange issues of late with our
> PostgreSQL
> > database(s). We have
On Wednesday, February 01, 2012 4:55:46 am Nykolyn, Andy (AS) wrote:
>
> Tom,
>
> It is version 8.4.1 and it has been that for almost 3 years. I have
> attached a script that will create and load the tables as well as the
> store procedure required to run the case that sometimes causes this err
On Wed, Feb 1, 2012 at 7:38 PM, Christopher Opena wrote:
> Hello folks,
>
> We've been running into some very strange issues of late with our PostgreSQL
> database(s). We have an issue where a couple of queries push high CPU on a
> few of our processors and the entire database locks (reads, write
Hello folks,
We've been running into some very strange issues of late with our
PostgreSQL database(s). We have an issue where a couple of queries push
high CPU on a few of our processors and the entire database locks (reads,
writes, console cannot be achieved unless the high CPU query procs are
k
On Wed, Feb 1, 2012 at 1:31 PM, Tom Lane wrote:
> Philip Rhoades writes:
> > On 2012-02-02 02:52, Tom Lane wrote:
> >> Anyway the solution is to connect to template1 and drop any cruft
> >> that's lying around in it.
>
> > I haven't done any manual messing around with template1 as far as I
> > k
On Wed, Feb 1, 2012 at 4:27 PM, Scott Marlowe wrote:
> On Wed, Feb 1, 2012 at 3:29 PM, Christian Ramseyer wrote:
>> Hello list
>>
>> I'm trying to build a little trigger-based auditing for various web
>> applications. They have many users in the application layer, but they
>> all use the same Pos
On Wed, Feb 1, 2012 at 3:29 PM, Christian Ramseyer wrote:
> Hello list
>
> I'm trying to build a little trigger-based auditing for various web
> applications. They have many users in the application layer, but they
> all use the same Postgres DB and DB user.
>
> So I need some kind of session stor
Hello list
I'm trying to build a little trigger-based auditing for various web
applications. They have many users in the application layer, but they
all use the same Postgres DB and DB user.
So I need some kind of session storage to save this application level
username for usage in my triggers, w
Philip Rhoades writes:
> On 2012-02-02 02:52, Tom Lane wrote:
>> Anyway the solution is to connect to template1 and drop any cruft
>> that's lying around in it.
> I haven't done any manual messing around with template1 as far as I
> know . .
Well, the behavior you describe indicates pretty str
Hi,
Sorry to be late in the thread, I'm too busy right now. Cédric called
it to my immediate attention though.
Martijn van Oosterhout writes:
> Perhaps a better way of dealing with this is providing a way of dumping
> extensions explicitly. Then you could say:
>
> pg_dump --extension=postgis -s
Tom Lane wrote:
Maxim Boguk writes:
I know there is issue with statistics over intarrays (it was there
very long time and sometime it's complicating things a lot).
However, the 100x cost difference between:
SELECT * from test order by id limit 100; (over "primary key (id)" btree
On Wed, 2012-02-01 at 11:44 -0200, Pablo Fulco wrote:
> Hi all, im very new to postgres, and im having a problem with postgres 8.1.
>
> The thing is that the server wont start, when I checked the log it said:
>
>
>
> Received fast shutdown request
>
> Aborting any active transaction
>
> FATA
Hi all, im very new to postgres, and im having a problem with postgres 8.1.
The thing is that the server wont start, when I checked the log it said:
Received fast shutdown request
Aborting any active transaction
FATAL: terminating connection due ti administrator command
FATAL: terminating c
Tom,
On 2012-02-02 02:52, Tom Lane wrote:
Merlin Moncure writes:
On Wed, Feb 1, 2012 at 8:52 AM, Chris Travers
wrote:
ext_test=# CREATE EXTENSION tablefunc;
ERROR: type "tablefunc_crosstab_2" already exists
This lead me to conclude that we needed to CREATE EXTENSION FROM
UNPACKAGED
thin
"Nykolyn, Andy (AS)" writes:
>> 8.4.what exactly, and did you update versions around the time this
>> started happening? I'm worried that this may represent a
>> newly-introduced bug. Can you provide a self-contained test case?
>> It doesn't matter if it only fails occasionally, as long as we ca
Merlin Moncure writes:
> On Wed, Feb 1, 2012 at 8:52 AM, Chris Travers wrote:
>> ext_test=# CREATE EXTENSION tablefunc;
>> ERROR: type "tablefunc_crosstab_2" already exists
>>
>> This lead me to conclude that we needed to CREATE EXTENSION FROM UNPACKAGED
>> thinking this might be an upgrade iss
Hello to everyone,
I'm trying to use variables in psql script to create some stored funtions.
The problem is that psql variables are not expanded if it is into a dollar
quoted string. This is my example:
\set my_schema foo
CREATE OR REPLACE FUNCTION foo() RETURNS VOID AS
$BODY$
SELECT * F
On Wed, Feb 1, 2012 at 8:52 AM, Chris Travers wrote:
> Hi all;
>
> We have gotten a report from a user who is having issues with CREATE
> EXTENSION tablefunc. I figured I would ask for additional insight and
> assistance at this point.
>
> When the user tries to run CREATE EXTENSION tablefunc; th
Hi all;
We have gotten a report from a user who is having issues with CREATE
EXTENSION tablefunc. I figured I would ask for additional insight and
assistance at this point.
When the user tries to run CREATE EXTENSION tablefunc; the following occurs:
-bash-4.2$ dropdb ext_test
-bash-4.2$ created
On Mon, Jan 30, 2012 at 20:55, Tulio wrote:
> I have 2 servers, working with Hot-Standby and Streaming Replication...
> and when we executed some query much large returns a message..
> "canceling statement due to statement timeout"
> I want know, how can I calculate the better value to
> "vacuum_
We get around this issue by creating a symbolic link called "current" that
points to the version of Postgres that we want our servers to use by
default:
ln -s /var/lib/pgsql/9.1 /var/lib/pgsql/current
The symbolic link is changed whenever we do an upgrade so it doesn't
interfere with anything tha
Nick wrote:
I have a pretty well tuned setup, with appropriate indexes and 16GB of
available RAM. Should this be taking this long? I forced it to not use
a sequential scan and that only knocked a second off the plan.
QUERY
PLAN
---
Herouth Maoz wrote:
> We are looking at a replication solution aimed at high availability.
>
> So we want to use PostgreSQL 9's streaming replication/hot standby.
> But I seem to be missing a very basic piece of information: suppose
> the primary is host1 and the secondary is host2. Suppose that
We are looking at a replication solution aimed at high availability.
So we want to use PostgreSQL 9's streaming replication/hot standby. But I seem
to be missing a very basic piece of information: suppose the primary is host1
and the secondary is host2. Suppose that when host1 fails host2 detect
36 matches
Mail list logo
