Re: [GENERAL] question about age()

Tom Lane wrote: > Andreas Kretschmer writes: > > '3 years' != '2 years 11 mons 30 days', but i got 0 rows, why? > > Well, actually: > > regression=# select '3 years'::interval = '2 years 11 mons 30 days'::interval; > ?column? > -- > t > (1 row) > > IIRC, interval comparison operato

[GENERAL] pgpool-ha not found in yum postgres repository

Hello to everybody. I've found there should be a package pgpool-ha in the full package list: http://yum.postgresql.org/news-packagelist.php I installed PostgreSQL yum repository by installing this RPM (red hat 6, x86_64): http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/pgdg-redhat92-9.2-7

[GENERAL] My Experiment of PG crash when dealing with huge amount of data

Hello: I have done the following experiment to test : PG's activity when dealing with data which is bigger in size than total memory of the whole os system. The result is: PG says: WARNING: terminating connection because of crash of another server process DETAIL:

Re: [GENERAL] Why is NULL = unbounded for rangetypes?

På fredag 30. august 2013 kl. 03:23:09, skrev Jeff Davis : On Tue, 2013-07-09 at 10:45 +0200, Andreas Joseph Krogh wrote: > I would expect the queries above to return FALSE and have to use > INFINITY to have them return TRUE. I don't understand what you mean by > ranges not all

Re: [GENERAL] My Experiment of PG crash when dealing with huge amount of data

This should be the operating system OOM kills pg process,check syslog On Fri 30 Aug 2013 05:10:42 PM CST, 高健 wrote: Hello: I have done the following experiment to test : PG's activity when dealing with data which is bigger in size than total memory of the whole os system. The result is: PG

Re: [GENERAL] Using of replication by initdb for both nodes?

On Thu, Aug 29, 2013 at 11:06 PM, Bocap wrote: > 1. Instead of using pg_basebackup for standby DB, i initdb for both standby > and primary. > 2. Create recovery.conf in standby DB, and start both nodes. > Now it work fine for me, but is it sure that no problem? A standby node *needs* to be based o

Re: [GENERAL] My Experiment of PG crash when dealing with huge amount of data

On Fri, Aug 30, 2013 at 6:10 PM, 高健 wrote: > In log, I can see the following: > LOG: background writer process (PID 3221) was terminated by signal 9: > Killed Assuming that no users on your server manually killed this process, or that no maintenance task you implemented did that, this looks like

[GENERAL] Unable to CREATE SCHEMA and INSERT data in table in that schema in same EXECUTE

Hi, I am using server 9.0.4, I am trying to 1. Create a new schema, 2. Create a table under that schema, and 3. Insert data in that schema, In the same EXECUTE and its failing. If I try CREATE OR REPLACE FUNCTION pg_temp.test( ) RETURNS void LANGUAGE plpgsql AS $BODY$ BEGIN EXECUTE 'CREATE SCHEMA

Re: [GENERAL] Unable to CREATE SCHEMA and INSERT data in table in that schema in same EXECUTE

vibhuti nataraj writes: > EXECUTE 'CREATE SCHEMA test; CREATE TABLE test.t (id integer ); INSERT INTO > test.t (id) VALUES (0);'; That's not going to work because the whole string is parsed before any of it is executed. In particular, parse analysis of the INSERT is going to spit up because neit

Re: [GENERAL] What is the relationship between checkpoint and wal

高健 wrote: > So I think that in a mission critical environment, it is not a > good choice to turn full_page_writes on. If full_page_writes is off, your database can be corrupted in the event of a crash of the hardware, OS, or VM (for example a power failure).  The only exception is if your enviro

Re: [GENERAL] virtualxid,relation lock

shanmugavel muthuvel wrote: > I have an issue with of "idle transaction" and one select > statement in backend. > How can fix the issue. There wasn't enough detail in the problem statement to make a detailed suggestion.  The general suggestion would be to make sure that transactions are never l

Re: [GENERAL] What is the relationship between checkpoint and wal

Hello: Thank you all. I have understood this. Best Regards 2013/8/31 Kevin Grittner > 高健 wrote: > > > So I think that in a mission critical environment, it is not a > > good choice to turn full_page_writes on. > > If full_page_writes is off, your database can be corrupted in the > event of