Hello,
I created a new database by
create database icare;
then quit off psql and run:
pg_restore --clean --create --exit-on-error --dbname=icare
icare-test.tar
it complains:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_re
On 11/12/2015 06:53 PM, Alex Luya wrote:
When restoring a dump like this:
|pg_restore --clean --create --exit-on-error --dbname=test test.tar|
these error messages got printed out:
|pg_restore:[archiver (db)]Error whilePROCESSING TOC:pg_restore:[archiver
(db)]Error fromTOC entry 21;261580924SC
On Thu, Oct 8, 2015 at 12:49 PM, Thomas Munro wrote:
> On Thu, Oct 8, 2015 at 5:52 AM, Peter Geoghegan
> wrote:
> > On Wed, Oct 7, 2015 at 6:25 AM, Tom Lane wrote:
> >> The only real way out of such a situation is to REINDEX affected
> indexes.
> >> Refusing to start the server not only doesn't
Try this instead:
SELECT current_database();
SELECT nspname FROM pg_namespace ORDER BY 1;
Also, What is the exact command you are using with pg_restore?
On Thu, Nov 12, 2015 at 9:53 PM, Alex Luya wrote:
> When restoring a dump like this:
>
> pg_restore --clean --create --exit-on-error --dbname=
When restoring a dump like this:
pg_restore --clean --create --exit-on-error --dbname=test test.tar
these error messages got printed out:
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 21; 2615 80924 SCHEMA test test
pg_restore: [archiver
Thomas Kellerer writes:
> Doiron, Daniel schrieb am 12.11.2015 um 23:21:
>> Im troubleshooting a schema and found this:
>>
>> Indexes:
>> "pk_patient_diagnoses" PRIMARY KEY, btree (id)
>> "index_4341548" UNIQUE, btree (id)
>> "idx_patient_diagnoses_deleted" btree (deleted)
>> "idx_patient_diagno
Thomas Kellerer wrote:
> Doiron, Daniel schrieb am 12.11.2015 um 23:21:
> >I’m troubleshooting a schema and found this:
> >
> >Indexes:
> > "pk_patient_diagnoses" PRIMARY KEY, btree (id)
> The only index that Postgres "automatically" creates is the unique index
> supporting a primary key or a
Doiron, Daniel schrieb am 12.11.2015 um 23:21:
I’m troubleshooting a schema and found this:
Indexes:
"pk_patient_diagnoses" PRIMARY KEY, btree (id)
"index_4341548" UNIQUE, btree (id)
"idx_patient_diagnoses_deleted" btree (deleted)
"idx_patient_diagnoses_diagnosis_type_id" btr
2015-11-12 23:21 GMT+01:00 Doiron, Daniel :
> I’m troubleshooting a schema and found this:
>
> Indexes:
> "pk_patient_diagnoses" PRIMARY KEY, btree (id)
> "index_4341548" UNIQUE, btree (id)
> "idx_patient_diagnoses_deleted" btree (deleted)
> "idx_patient_diagnoses_diagnosis_type_id
On 11/12/2015 02:21 PM, Doiron, Daniel wrote:
I’m troubleshooting a schema and found this:
Indexes:
"pk_patient_diagnoses" PRIMARY KEY, btree (id)
"index_4341548" UNIQUE, btree (id)
"idx_patient_diagnoses_deleted" btree (deleted)
"idx_patient_diagnoses_diagnosis_type_id" btre
I’m troubleshooting a schema and found this:
Indexes:
"pk_patient_diagnoses" PRIMARY KEY, btree (id)
"index_4341548" UNIQUE, btree (id)
"idx_patient_diagnoses_deleted" btree (deleted)
"idx_patient_diagnoses_diagnosis_type_id" btree (diagnosis_type_id)
"idx_patient_diagnoses_icd
On 11/12/2015 11:49 AM, db042190 wrote:
I see "unexpected eof...could not receive data..target
machine actively refused it.".
That sounds like the same error message as discussed here:
http://www.postgresql.org/message-id/4d75289d.9020...@techbaza.pl
Could it be a problem of too many open con
On 11/12/2015 12:54 PM, db042190 wrote:
there is something i need to correct. Coming out of one of the 3 switches
are two branches that cause updates to the same "interaction log" table in
postgres. Not text files like the other 2 switches.
Could you show a sample of the actual log error mess
On 11/12/2015 12:07 PM, Venkata Balaji N wrote:
Around that time I just see a bunch of "checkpoints are occurring too
frequently...". About a minute later and coincidentally around the
time the
pentaho job ends, I see "unexpected eof...could not receive data..target
machine actively refused it
there is something i need to correct. Coming out of one of the 3 switches
are two branches that cause updates to the same "interaction log" table in
postgres. Not text files like the other 2 switches.
--
View this message in context:
http://postgresql.nabble.com/postgres-sometimes-returns-n
thx, the fact that the query runs under pentaho at least half of the time
(used to be most of the time) makes me think it will run on the db. I'll try
to get a handle on the cpu/handle info u requested.
--
View this message in context:
http://postgresql.nabble.com/postgres-sometimes-returns-no-
thx both for responding.
Because the checkpoint settings probably haven't changed in a long long time
and we see as many of those warnings on good nights as bad I'm going to make
those priority 2. Unless there is a cause and effect u can explain between
checkpointing and what we are experiencin
On Fri, Nov 13, 2015 at 6:49 AM, db042190
wrote:
> Hi. We have a postgres 9.1 query in a pentaho job (table input component
> contains the query and is followed by various switches) that runs nightly.
> More and more frequently (about half the time now), the query returns no
> data (or appears t
On 11/12/2015 11:49 AM, db042190 wrote:
Hi. We have a postgres 9.1 query in a pentaho job (table input component
contains the query and is followed by various switches) that runs nightly.
More and more frequently (about half the time now), the query returns no
data (or appears to return no data,
Hi. We have a postgres 9.1 query in a pentaho job (table input component
contains the query and is followed by various switches) that runs nightly.
More and more frequently (about half the time now), the query returns no
data (or appears to return no data, see last paragraph) when there is
clearl
On 11/12/2015 10:19 AM, anj patnaik wrote:
The Linux VM where postgres is running over NFS is in a different
location than where I am. Both the NFS mounted storage and VM are on
the same network connected via 1GB ethernet switch.
and earlier...
I do need reliability and high speed.
you wo
On Thu, Nov 12, 2015 at 12:49 PM, Scott Marlowe
wrote:
> On Thu, Nov 12, 2015 at 11:19 AM, anj patnaik wrote:
> > The Linux VM where postgres is running over NFS is in a different
> location
> > than where I am. Both the NFS mounted storage and VM are on the same
> network
> > connected via 1GB
2015-11-12 19:43 GMT+01:00 Adrian Klaver :
> On 11/12/2015 10:02 AM, anj patnaik wrote:
>
>> I get this warning when trying to fetch data for a postgres db. Does
>> this indicate a real issue? Thanks
>>
>
> Well it means the statistics for the table are out of touch with reality.
> The database wi
This is not necessarily a major issue. It is simply an advisory that a
significant number of rows in the table have been inserted, updated or
deleted and that in order to have reliable statistics, a vacuum analyze
should be done.
Depending on the number of rows in the table and the difference betw
On Thu, Nov 12, 2015 at 11:49 AM, Scott Marlowe wrote:
> On Thu, Nov 12, 2015 at 11:19 AM, anj patnaik wrote:
>> The Linux VM where postgres is running over NFS is in a different location
>> than where I am. Both the NFS mounted storage and VM are on the same network
>> connected via 1GB ethernet
On Thu, Nov 12, 2015 at 11:19 AM, anj patnaik wrote:
> The Linux VM where postgres is running over NFS is in a different location
> than where I am. Both the NFS mounted storage and VM are on the same network
> connected via 1GB ethernet switch.
>
> The physical server for the Linux VM has UPS.
>
On 11/12/2015 10:02 AM, anj patnaik wrote:
I get this warning when trying to fetch data for a postgres db. Does
this indicate a real issue? Thanks
Well it means the statistics for the table are out of touch with
reality. The database will not fall over, but your queries against the
table will
The Linux VM where postgres is running over NFS is in a different location
than where I am. Both the NFS mounted storage and VM are on the same
network connected via 1GB ethernet switch.
The physical server for the Linux VM has UPS.
Is there any specific test I can run to do power failure?
Can I
I get this warning when trying to fetch data for a postgres db. Does this
indicate a real issue? Thanks
Running VACUUM recommended
The estimated rowcount on the table "recorder" deviates significantly from
the actual rowcount. You should run VACUUM ANALYZE on this table.
Oops, I forgot to mention pg_initicluster, which is used to initiate the
various version/cluster combinations in Ubuntu.
It makes it easier to have several versions and clusters on the same
server, albeit that is not what most people/companies usually do.
eg: In Ubuntu, you could possibly have the
On 11/12/2015 08:37 AM, Melvin Davidson wrote:
To clarify.
To see the ACTUAL clusters installed, and the LIVE config directories,
you use
pg_lsclusters.
Actually:
aklaver@arkansas:~$ pg_lsclusters
Ver Cluster Port Status OwnerData directory Log file
9.3 main5432 down
To clarify.
To see the ACTUAL clusters installed, and the LIVE config directories, you
use
pg_lsclusters.
pg_ctlclusters then can control each individual cluster
So, for example, since apparently you have the 9.4 version of PostgreSQL,
pg_ctlcluster 9.4 main status
would probably show you that t
Adrian Klaver writes:
> On 11/12/2015 08:07 AM, Melvin Davidson wrote:
>> In Ubuntu 14.10, there are three variations of the postgresql.conf
>> configuration file, as follows:
>>
>> /var/lib/postgresql/9.4/main/postgresql.auto.conf
>> /usr/lib/tmpfiles.d/postgresql.conf
>> /etc/postgresql/9.4/mai
On 11/12/2015 08:07 AM, Melvin Davidson wrote:
Ubuntu does not use the standard pg_ctl for postgreSQL. Instead, it uses
pg_ctlcluster.
That in turn controls the different PostgreSQL clusters. When you do an
install of a new cluster, pg_ctlcluster is smart enough to put
postgresql.conf & pg_hba.co
Ubuntu does not use the standard pg_ctl for postgreSQL. Instead, it uses
pg_ctlcluster.
That in turn controls the different PostgreSQL clusters. When you do an
install of a new cluster, pg_ctlcluster is smart enough to put
postgresql.conf & pg_hba.conf into separate dirs.
So to be specific, /usr/li
On 11/12/2015 07:46 AM, Michael Convey wrote:
In Ubuntu 14.10, there are three variations of the postgresql.conf
configuration file, as follows:
/var/lib/postgresql/9.4/main/postgresql.auto.conf
The above is for when you do ALTER SYSTEM:
http://www.postgresql.org/docs/9.4/interactive/sql-alter
In Ubuntu 14.10, there are three variations of the postgresql.conf
configuration file, as follows:
/var/lib/postgresql/9.4/main/postgresql.auto.conf
/usr/lib/tmpfiles.d/postgresql.conf
/etc/postgresql/9.4/main/postgresql.conf
What is the difference between these files and which is the correct one
On Tue, Nov 10, 2015 at 12:26 PM, Adrian Klaver
wrote:
> On 11/10/2015 10:21 AM, Mammarelli, Joanne T wrote:
>>
>> Hi .. we’re on a hunt to locate either pgloader or the tds_fdw extension
>> to assist us with pulling data FROM a Microsoft sql server (we’re a
>> windows-based postgres installation)
On Wed, Nov 11, 2015 at 3:44 AM, Dusan wrote:
> Hi,
> I'm using table with parent_id to themselve and WITH RECURSIVE in SELECT on
> about 3thousands records.
> The "tree" of data is wide (each node has more children) but not deep
> (maximal depth of branch is 10 nodes).
>
> I'm planning to use sam
39 matches
Mail list logo
