After restarting the server in another window, I was surprised that my
command did not run in a transaction:
spc_test_scratch=# BEGIN; DROP VIEW IF EXISTS ptest_mip ; DROP VIEW
rent_info; \i create.view.rent_info.sql
FATAL: terminating connection due to administrator command
server closed the con
On 09/27/2013 10:57 PM, Adrian Klaver wrote:
Did you try the override method shown in this message?:
http://www.postgresql.org/message-id/ovpbg9.x5ovpbg9.pq9n.w333.g...@asuka.myrkraverk.com
I found it very comlicated and made things worst (I got ton of errors)!!!
BTW, I wonder why Postgresql
On 09/27/2013 10:42 PM, John R Pierce wrote:
static linking is heavily deprecated in most all environments.
I don't think this true because there are many commercial SDKs uses
static linking so the major issue here not deprecation so I strongly
believe it's license issue.
--
Best Regards,
Muh
On 09/28/2013 11:31 AM, Henrik wrote:
hello,
I am trying to recover data from postgesql 8.3 incomplete backup. I have
contents of data/base/ (fs snapshot), but there some tablespaces
(indexes, some tables) were in other locations.
On new server (clean install) I created database, replaced base
On 09/28/2013 11:31 AM, Henrik wrote:
hello,
I am trying to recover data from postgesql 8.3 incomplete backup. I have
contents of data/base/ (fs snapshot), but there some tablespaces
(indexes, some tables) were in other locations.
On new server (clean install) I created database, replaced base
Em 28/09/2013 18:23, Jeff Janes escreveu:
On Sat, Sep 28, 2013 at 1:54 PM, Edson Richter
mailto:edsonrich...@hotmail.com>> wrote:
Em 28/09/2013 15:54, Adrian Klaver escreveu:
Ok. Found the place.
So, there is nothing there. PG_DATA/base/pgsql_tmp is a empty
directory.
I've
Em 28/09/2013 18:12, Tomas Vondra escreveu:
On 28 Září 2013, 22:54, Edson Richter wrote:
Em 28/09/2013 15:54, Adrian Klaver escreveu:
On 09/28/2013 11:30 AM, Edson Richter wrote:
Em 28/09/2013 15:22, Adrian Klaver escreveu:
On 09/28/2013 11:16 AM, Edson Richter wrote:
I've a 12Gb database ru
On Sat, Sep 28, 2013 at 1:54 PM, Edson Richter wrote:
> Em 28/09/2013 15:54, Adrian Klaver escreveu:
>
> Ok. Found the place.
> So, there is nothing there. PG_DATA/base/pgsql_tmp is a empty directory.
> I've run the query over pg_stat_database view and there is nothing wrong
> with pgAdmin III - t
On 28 Září 2013, 22:54, Edson Richter wrote:
> Em 28/09/2013 15:54, Adrian Klaver escreveu:
>> On 09/28/2013 11:30 AM, Edson Richter wrote:
>>> Em 28/09/2013 15:22, Adrian Klaver escreveu:
On 09/28/2013 11:16 AM, Edson Richter wrote:
> I've a 12Gb database running without problems in Linux
Em 28/09/2013 15:54, Adrian Klaver escreveu:
On 09/28/2013 11:30 AM, Edson Richter wrote:
Em 28/09/2013 15:22, Adrian Klaver escreveu:
On 09/28/2013 11:16 AM, Edson Richter wrote:
I've a 12Gb database running without problems in Linux Centos 64bit
for
years now.
Looking database statistics (i
On 28 Září 2013, 21:30, Eugene Ostrovsky wrote:
> Thanks for the answer!
>
> About you questions:
> 1. Postgres 9.3
> 2. There are about 30-50 user connections. Actually Only 2 of databases
> are used intensively, others only in rare cases.
> 3. Hardware is AMD Phenom II X4 965, 8 Gb RAM, 2 SATA2
On 09/28/2013 11:30 AM, Edson Richter wrote:
Em 28/09/2013 15:22, Adrian Klaver escreveu:
On 09/28/2013 11:16 AM, Edson Richter wrote:
I've a 12Gb database running without problems in Linux Centos 64bit for
years now.
Looking database statistics (in pgAdmin III), I can see that there are
366 te
On 9/28/2013 11:29 AM, Tomas Vondra wrote:
There are probably some corner cases where this might improve the
performance, but in most cases it's going to be worse. Why are you
switching to multiple clusters?
For example consider that you'll probably have to use much smaller shared
buffers (which
hello,
I am trying to recover data from postgesql 8.3 incomplete backup. I have
contents of data/base/ (fs snapshot), but there some tablespaces
(indexes, some tables) were in other locations.
On new server (clean install) I created database, replaced base folder,
renamed database folder to match
Em 28/09/2013 15:22, Adrian Klaver escreveu:
On 09/28/2013 11:16 AM, Edson Richter wrote:
I've a 12Gb database running without problems in Linux Centos 64bit for
years now.
Looking database statistics (in pgAdmin III), I can see that there are
366 temporary files, and they sum up 11,863,839,867
On 28 Září 2013, 20:12, Eugene Ostrovsky wrote:
> Hello!
>
> I would like to find out what is the difference in hardware resources
> consuming between two solutions:
> 1. Several databases in the same postgresql cluster
> 2. Several clusters (one per each database) on the same host
>
> Currently I
Em 28/09/2013 15:16, Edson Richter escreveu:
I've a 12Gb database running without problems in Linux Centos 64bit
for years now.
Looking database statistics (in pgAdmin III), I can see that there are
366 temporary files, and they sum up 11,863,839,867 bytes in size.
Is that normal? When will th
On 09/28/2013 11:16 AM, Edson Richter wrote:
I've a 12Gb database running without problems in Linux Centos 64bit for
years now.
Looking database statistics (in pgAdmin III), I can see that there are
366 temporary files, and they sum up 11,863,839,867 bytes in size.
What are the temp files named
I installed pyodbc-3.0.7.win-amd64-py3.2.exe from
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyodbc then it work well
On Fri, Sep 27, 2013 at 10:00 AM, tuanhoanganh wrote:
> Hello all.
>
> I updated my laptop to windows 8.1, my PostgreSQL version is 9.2.3 64 bit.
> But my plpython function have
I've a 12Gb database running without problems in Linux Centos 64bit for
years now.
Looking database statistics (in pgAdmin III), I can see that there are
366 temporary files, and they sum up 11,863,839,867 bytes in size.
Is that normal? When will this space be released?
I've restarted the serv
20 matches
Mail list logo
