Jim Nasby-5 wrote
> Which is it? Is the vacuum process is using 1.2GB (5% of memory) or is
> it using 90% (~22GB)?
i ran the job 2-3 times.
- first with 18GB swap too. I heared it thrashing, performance went extremly
down and after 2 hours i killed the job (reboot system, no other way to do
it)
On Fri, 6 Mar 2015 10:04:38 +0530
Medhavi Mahansaria wrote:
>
> I need to enter the date in null column based on the results obtained.
>
> but my date gets inserted as 01/01/0001 in postgresql 9.3 when there is no
> value.
> I need to enter NULL in the column.
This isn't how PostgreSQL behave
hi,
waiting for the index (104/121GB), i read his document
http://www.postgresql.org/docs/9.4/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
and will do some changes before the next analyze:
some comments:
- the OOM did not kill the Postmaster but the Analyze-Job.
- started with 24GB real
Hi Bill,
Here are the details of the table and the query i want to insert.
aml_db=> \d+ check_date
Table "public.check_date"
Column |Type | Modifiers | Storage | Stats
target | Description
---+-+---
On Fri, 6 Mar 2015 15:24:28 +0530
Medhavi Mahansaria wrote:
> Hi Bill,
>
> Here are the details of the table and the query i want to insert.
>
>
> aml_db=> \d+ check_date
> Table "public.check_date"
> Column |Type | Modifiers | Stora
On Fri, Mar 06, 2015 at 03:24:28PM +0530, Medhavi Mahansaria wrote:
> aml_db=> \d+ check_date
> Table "public.check_date"
> Column |Type | Modifiers | Storage | Stats
> target | Description
> ---+-+--
Hi,
Yes true. I agree with you.
I am porting my application from oracle to postgresql. in oracle it enters
as NULL and hence this problem was not faced.
Now my problem is that my bind variables are of string type and when the
get a NULL value is converts it into an empty string in C++ programm
On Fri, Mar 06, 2015 at 02:39:34AM -0700, wambacher wrote:
> some comments:
>
> - the OOM did not kill the Postmaster but the Analyze-Job.
> - started with 24GB real and 18GB Swap - that must be enought! --> killed
"Back in the days" it was conventional wisdom to have twice
as much swap as you'v
Karsten Hilbert wrote
> Of course, I am
> not suggesting you provide 48GB of swap and your problem is
> magically solved _but_ one thing we might take away from that
> old adage is that one might "hope things to work better"
> (say, while debugging) if there is at least as much swap as
> there is p
I have deleted a large number of records from my_table, which originally had
288 MB. Then I ran vacuum full to make the table size smaller. After this
operation size of the table remains the same, despite of the fact that table
contains now only 241 rows and after rewriting it in classic way: CREAT
wambacher wrote
> hi,
>
> waiting for the index (104/121GB), i read his document
> http://www.postgresql.org/docs/9.4/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
> and will do some changes before the next analyze:
>
> some comments:
>
> - the OOM did not kill the Postmaster but the Anal
Medhavi Mahansaria wrote:
> Now my problem is that my bind variables are of string type and
> when the get a NULL value is converts it into an empty string in
> C++ programming.
> Example:
> insert into check_date values
> (to_date(:h1,'mmddhh24miss'),
>1,
>to_date(:h2,'mmddhh2
Resend.
How to quickly compare the similarity of two tsvector?
On Monday, March 2, 2015 11:01 PM, Patrick Dung
wrote:
Hello,
I had a database with articles or attachment stored in bytea format.I also had
a trigger: it insert/update the tsv column when a record is added/updated.The
pinker wrote:
> I have deleted a large number of records from my_table, which originally had
> 288 MB. Then I ran vacuum full to make the table size smaller. After this
> operation size of the table remains the same, despite of the fact that table
> contains now only 241 rows and after rewriting it
Query output is empty...
--
View this message in context:
http://postgresql.nabble.com/VACUUM-FULL-doesn-t-reduce-table-size-tp5840782p5840797.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
pinker wrote:
> Query output is empty...
I hope you read the whole paragraph, not just the last phrase.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@post
On Fri, Mar 6, 2015 at 5:05 PM, Patrick Dung wrote:
> Resend.
>
> How to quickly compare the similarity of two tsvector?
>
check http://www.sai.msu.su/~megera/postgres/talks/pgcon-2012.pdf
>
> On Monday, March 2, 2015 11:01 PM, Patrick Dung
> wrote:
>
>
> Hello,
>
> I had a database with artic
Hi all,
We have an application based on DB2 database, We are testing this same
application on PostgreSQL database. By default we are in autocommit on
mode.
On DB2 (and Oracle), the query SELECT FOR UPDATE locks the row until the
resultset is closed. On PostgreSQL database (all versions) this sam
On 03/06/2015 08:27 AM, Philippe EMERIAUD wrote:
Hi all,
We have an application based on DB2 database, We are testing this same
application on PostgreSQL database. By default we are in autocommit on
mode.
On DB2 (and Oracle), the query SELECT FOR UPDATE locks the row until the
resultset is closed
Can you point me to the source of that quote ?
The documentation here
http://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html does not
specify anything about ResultSet closing, or completion ?
Short version is that the driver does not hold the lock past the return of
the result set, so
Attempting to upgrade a large (>3TB) postgressql database from 9.3 to
9.4 on Ubuntu 14.04 LTS, but the process fails fairly early on. The
error message instructs me to look at the last few lines of
pg_upgrade_utility.log for more info, and the last two lines there (the
only ones that don't succ
On 03/06/2015 10:11 AM, Matt Landry wrote:
Attempting to upgrade a large (>3TB) postgressql database from 9.3 to
9.4 on Ubuntu 14.04 LTS, but the process fails fairly early on. The
error message instructs me to look at the last few lines of
pg_upgrade_utility.log for more info, and the last two l
Matt,
In your existing environment, do you have template0 set to allow
connections (datallowconn)?
That's not a good idea in general, but I suspect that's why pg_dumpall
is including it based on a quick look at the code.
Thanks!
* Matt Landry (lelnet.m...@gmail.com) wrote:
> Attempting to upgra
Philippe EMERIAUD wrote on 06.03.2015 17:27:
Hi all,
We have an application based on DB2 database, We are testing this
same application on PostgreSQL database. By default we are in
autocommit on mode.
On DB2 (and Oracle), the query SELECT FOR UPDATE locks the row until
the resultset is closed.
Adrian,
* Adrian Klaver (adrian.kla...@aklaver.com) wrote:
> On 03/06/2015 10:11 AM, Matt Landry wrote:
> >Attempting to upgrade a large (>3TB) postgressql database from 9.3 to
> >9.4 on Ubuntu 14.04 LTS, but the process fails fairly early on. The
> >error message instructs me to look at the last
On 03/06/2015 10:35 AM, Stephen Frost wrote:
Adrian,
* Adrian Klaver (adrian.kla...@aklaver.com) wrote:
On 03/06/2015 10:11 AM, Matt Landry wrote:
Attempting to upgrade a large (>3TB) postgressql database from 9.3 to
9.4 on Ubuntu 14.04 LTS, but the process fails fairly early on. The
error mes
On 03/06/2015 12:37 PM, Adrian Klaver wrote:
Agreed, I am just trying to figure out how you get:
CREATE DATABASE "template0" WITH TEMPLATE = template0 ..
Seems to be a snake eating its tail:)
Yes. It does. And it's pretty obvious why having this would be a
problem...not quite so obvious how
On 03/06/2015 11:22 AM, Matt Landry wrote:
On 03/06/2015 12:37 PM, Adrian Klaver wrote:
Agreed, I am just trying to figure out how you get:
CREATE DATABASE "template0" WITH TEMPLATE = template0 ..
Seems to be a snake eating its tail:)
Yes. It does. And it's pretty obvious why having this wou
On Fri, Mar 6, 2015 at 5:59 AM, pinker wrote:
> I have deleted a large number of records from my_table, which originally
> had
> 288 MB. Then I ran vacuum full to make the table size smaller. After this
> operation size of the table remains the same, despite of the fact that
> table
>
If your re
On 03/06/2015 11:22 AM, Matt Landry wrote:
On 03/06/2015 12:37 PM, Adrian Klaver wrote:
Agreed, I am just trying to figure out how you get:
CREATE DATABASE "template0" WITH TEMPLATE = template0 ..
Seems to be a snake eating its tail:)
Yes. It does. And it's pretty obvious why having this wou
On 03/06/2015 01:55 PM, Adrian Klaver wrote:
So on the original cluster, log in using psql and do \l and post the
results here. Thanks.
[...]
Meant to add to previous post, to check with issue that Stephen
mentioned do:
select datname, datallowconn from pg_database ;
postgres=# \l
On 3/6/2015 2:12 AM, Medhavi Mahansaria wrote:
I am porting my application from oracle to postgresql. in oracle it
enters as NULL
Oracle has the unique 'feature' that an empty string is NULL. This is
contrary to the SQL spec.
--
john r pierce 37N 122W
Matt,
* Matt Landry (lelnet.m...@gmail.com) wrote:
> postgres=# select datname, datallowconn from pg_database ;
> datname | datallowconn
> ---+--
> template1 | t
> template0 | t
> postgres | t
> reporting | t
> (4 rows)
Right, as I mentioned, template0 shouldn't have d
Mac 10.10.2 (Yosemite)
PostgreSQL 9.3
error message:
ERROR : SQL command failed: SQL: CREATE LANGUAGE plpythonu;
ERROR: could not access file "$libdir/plpython2": No such file or directory
Searched Web, nothing useful found...
Any advice will be greatly appreciated.
Diana
--
Sent via pgs
On 03/06/2015 02:43 PM, Stephen Frost wrote:
Right, as I mentioned, template0 shouldn't have datallowconn as 'true'.
That's why it's being included in the pg_dumpall.
On your test setup, run (as superuser):
update pg_database set datallowconn = false where datname = 'template0';
Then re-run th
Stephen Frost writes:
> * Matt Landry (lelnet.m...@gmail.com) wrote:
>> postgres=# select datname, datallowconn from pg_database ;
>> datname | datallowconn
>> ---+--
>> template1 | t
>> template0 | t
>> postgres | t
>> reporting | t
>> (4 rows)
> Right, as I mentioned, temp
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Matt Landry (lelnet.m...@gmail.com) wrote:
> >> postgres=# select datname, datallowconn from pg_database ;
> >> datname | datallowconn
> >> ---+--
> >> template1 | t
> >> template0 | t
> >> postgres | t
> >>
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Perhaps pg_upgrade should deliberately ignore template0 regardless of
>> datallowconn? And/or we should hard-wire that into pg_dumpall?
> My thinking would be that pg_dumpall should be hard-wired for template0
> (just like it is f
On 03/06/2015 12:44 PM, dpop...@uvic.ca wrote:
Mac 10.10.2 (Yosemite)
PostgreSQL 9.3
error message:
ERROR : SQL command failed: SQL: CREATE LANGUAGE plpythonu;
ERROR: could not access file "$libdir/plpython2": No such file or directory
Searched Web, nothing useful found...
Any advice will b
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Perhaps pg_upgrade should deliberately ignore template0 regardless of
> >> datallowconn? And/or we should hard-wire that into pg_dumpall?
>
> > My thinking would be that pg_dumpall shou
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>
>> Stephen Frost writes:
>> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> >> Perhaps pg_upgrade should deliberately ignore template0 regardless of
>> >> datallowconn? And/or we should hard-wire that into pg_dumpall?
>>
>> > My thin
On Thu, Mar 5, 2015 at 5:27 AM, Elena Fernandez Carmona
wrote:
> Hi,
>
> I have Postgres 9.2.4 installed on a RHEL 5.5
>
> I am going to migrate the operating system version to RHEL 6.4, and I would
> like to know if it is compatible with my postgres 9.2.4.
>
This is clearly *not* a bug so, i'm m
Postgres installed with Installer, from EnterpriseDB.
Error received while trying to register MADlib 1.7.0.
Looked at PostgresApp, but it is a package for PostgreSQL 9.4. Cannot have
this version of Postgres, because it is not supported by MADlib. Tried,
does not work. Had to uninstall, + manual d
On 03/06/2015 05:41 PM, dpop...@uvic.ca wrote:
Postgres installed with Installer, from EnterpriseDB.
Error received while trying to register MADlib 1.7.0.
I seem to remember the EDB builds against Python 3 not 2 now, which
would explain the error below if MADlib is looking for Python 2. I
can
Vick Khera wrote
> On Fri, Mar 6, 2015 at 5:59 AM, pinker <
> pinker@
> > wrote:
>
>> I have deleted a large number of records from my_table, which originally
>> had
>> 288 MB. Then I ran vacuum full to make the table size smaller. After this
>> operation size of the table remains the same, desp
David G Johnston writes:
> I have no experience here but given recent versions rewrite the table the
> vacuum verbose output shown seems unusual.
"vacuum verbose output shown?" There wasn't any.
[ digs about ... ]
Oh. The version of the message that nabble sent to the postgresql lists
was mis
Thank you, Adrian.
Maybe, you will be able to find something useful.
I spent more hours trying to
- install PostgreSQL 9.3 (successful, but with python3)
- install PostgresApp 9.3 (unsuccessful, could not start postgres, but no
matter - no python2 there anyway), then uninstall it.
- install Python
47 matches
Mail list logo
