Chander Ganesan writes:
> With PostGIS 2.0 if I load/install postgis using the command:
> create extension postgis schema postgis;
> And then use the command:
> pg_dump -t postgis.spatial_ref_sys dbname > spatial_ref_sys.sql
> I get an output that contains a few "set" statements, but no table
With PostGIS 2.0 if I load/install postgis using the command:
create extension postgis schema postgis;
And then use the command:
pg_dump -t postgis.spatial_ref_sys dbname > spatial_ref_sys.sql
I get an output that contains a few "set" statements, but no table
definition or data from the table
Elizandro Gallegos wrote:
> Please can I be removed from the mailing list
The answer was in the email to which you responded. Did you have
trouble using the referenced page?
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-admin
-Kevin
--
Sent via pg
"Gnanakumar" wrote:
>> We get very good performance dealing with thousands of concurrent
>> users with a pool of 35 connections to the database.
>>
>> If you want to handle more users than you can currently support,
>> you probably need to use fewer database connections.
>
> First, please excuse
Hello
Please can I be removed from the mailing list, and I receive many emails like
this
thanks
ЄLIZANDЯO GALLEGOS V.
> Date: Wed, 9 May 2012 09:58:45 -0400
> From: chander.gane...@gmail.com
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] pg_dump: schema with OID 22
Chander Ganesan writes:
> I'm running into a weird issue with PostgreSQL 9.1.3 and PostGIS 2.0
> when trying to dump a table - no matter what table I try to dump in this
> database, I find that I get the same error, as evidenced below (scroll
> down for relevant data/error output.)
2200 would
Hi All,
I'm running into a weird issue with PostgreSQL 9.1.3 and PostGIS 2.0
when trying to dump a table - no matter what table I try to dump in this
database, I find that I get the same error, as evidenced below (scroll
down for relevant data/error output.)
Any ideas as to what might be the
> We get very good performance dealing with
> thousands of concurrent users with a pool of 35 connections to the
> database.
>
> If you want to handle more users than you can currently support, you
> probably need to use fewer database connections.
First, please excuse me that I'm not able to und