On 12/10/2014 02:34 PM, Adrian Klaver wrote:
On 12/10/2014 10:08 AM, Gabriel Sánchez Martínez wrote:
On 12/10/2014 01:00 PM, Adrian Klaver wrote:
On 12/10/2014 09:54 AM, Gabriel Sánchez Martínez wrote:
On 12/10/2014 12:47 PM, Adrian Klaver wrote:
On 12/10/2014 09:25 AM, Gabriel Sánchez
On 12/10/2014 01:48 PM, Tomas Vondra wrote:
On 10.12.2014 17:07, Gabriel Sánchez Martínez wrote:
Hi all,
I am running PostgreSQL 9.3.5 on Ubuntu Server 14.04 64 bit with 64 GB
of RAM. When running pg_dump on a specific table, I get the following
error:
pg_dump: Dumping the contents of table
On 12/10/2014 01:00 PM, Adrian Klaver wrote:
On 12/10/2014 09:54 AM, Gabriel Sánchez Martínez wrote:
On 12/10/2014 12:47 PM, Adrian Klaver wrote:
On 12/10/2014 09:25 AM, Gabriel Sánchez Martínez wrote:
On 12/10/2014 11:49 AM, Adrian Klaver wrote:
On 12/10/2014 08:31 AM, Gabriel Sánchez
On 12/10/2014 12:47 PM, Adrian Klaver wrote:
On 12/10/2014 09:25 AM, Gabriel Sánchez Martínez wrote:
On 12/10/2014 11:49 AM, Adrian Klaver wrote:
On 12/10/2014 08:31 AM, Gabriel Sánchez Martínez wrote:
On 12/10/2014 11:16 AM, Adrian Klaver wrote:
On 12/10/2014 08:07 AM, Gabriel Sánchez
On 12/10/2014 11:49 AM, Adrian Klaver wrote:
On 12/10/2014 08:31 AM, Gabriel Sánchez Martínez wrote:
On 12/10/2014 11:16 AM, Adrian Klaver wrote:
On 12/10/2014 08:07 AM, Gabriel Sánchez Martínez wrote:
Hi all,
I am running PostgreSQL 9.3.5 on Ubuntu Server 14.04 64 bit with 64 GB
of RAM
On 12/10/2014 11:16 AM, Adrian Klaver wrote:
On 12/10/2014 08:07 AM, Gabriel Sánchez Martínez wrote:
Hi all,
I am running PostgreSQL 9.3.5 on Ubuntu Server 14.04 64 bit with 64 GB
of RAM. When running pg_dump on a specific table, I get the following
error:
pg_dump: Dumping the contents of
Hi all,
I am running PostgreSQL 9.3.5 on Ubuntu Server 14.04 64 bit with 64 GB
of RAM. When running pg_dump on a specific table, I get the following
error:
pg_dump: Dumping the contents of table "x_2013" failed:
PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid m
> On Nov 17, 2014, at 8:10, Gabriel Sánchez Martínez
> wrote:
>
>
>
>> On Nov 17, 2014, at 3:28, Raghu Ram wrote:
>>
>>> On Mon, Nov 17, 2014 at 10:20 AM, Gabriel Sánchez Martínez
>>> wrote:
>>>
>>> The situation appears to
> On Nov 17, 2014, at 3:28, Raghu Ram wrote:
>
>> On Mon, Nov 17, 2014 at 10:20 AM, Gabriel Sánchez Martínez
>> wrote:
>>
>> The situation appears to be stable now, but upon running REINDEX and VACUUM
>> on one of the databases, I get the following:
&
I'm running PostgreSQL 9.3.5 on Ubuntu 14.04 on x86_64. The database
directory is on linux mdadm RAID10, using 4 4TB disks and a far=2
layout. While the RAID tolerates 1 drive failure nicely, I had the
misfortune of 2 drives failing consecutively, one of which had many
sectors reallocated and
On 02/17/2014 08:45 PM, Jeff Janes wrote:
On Mon, Feb 17, 2014 at 5:09 PM, "Gabriel E. Sánchez Martínez"
mailto:gabrielesanc...@gmail.com>> wrote:
On 02/16/2014 10:33 PM, Gabriel Sánchez Martínez wrote:
Is there a way of asking PostgreSQL to read the files of
Is there a way of asking PostgreSQL to read the files of a table
directly off the disk, asking the OS not to use the file cache? I am
running PostgreSQL 9.1 on Ubuntu Server 64-bit. The server in question
has the maximum amount of RAM it supports, but the database has grown
much larger. Most
On 11/13/2013 06:22 AM, Torsten Förtsch wrote:
Hi,
we have a table partitioned by time. Each month goes into a separate
child table. Primary key in each table is (underlying, ts). The
resulting index is perfect for ordering like in the query below. Each
child table has a constraint like:
CH
On 11/13/2013 08:26 AM, Torsten Förtsch wrote:
On 13/11/13 13:49, Gabriel Sánchez Martínez wrote:
My question is, why does it then try to fetch one row from every other
index? Can that be avoided without a lower bound on ts?
If you don't set a lower bound, since every other table has
On 11/13/2013 06:22 AM, Torsten Förtsch wrote:
Hi,
we have a table partitioned by time. Each month goes into a separate
child table. Primary key in each table is (underlying, ts). The
resulting index is perfect for ordering like in the query below. Each
child table has a constraint like:
CH
15 matches
Mail list logo
