Over the weekend, Amazon did some maintenance that resulted in one of our
instances being restarted. Apparently this left the database in a bad
state. This particular instance functions as a slony replication target and
when I went to start up slony, I get the following error message. Here's
some r
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 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 Mar
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 Martínez wrote:
On 12/10/2014 11:49 AM, Adrian K
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 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 "x_2013" failed:
> PQgetResult
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 Mar
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 Martínez wrote:
On 12/10/2014 11:16 AM, Adrian K
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 Mar
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 Martínez wrote:
Hi all,
I am running PostgreSQL
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. W
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. When running pg_dump on a specific table, I get
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 ta
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 table "x_2013" failed:
PQgetResult() failed.
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
scheu_postgresql wrote:
> In my Postgresql 8.4.0 server, since this morning some tables are
unavailable, see example below :
>
> --> pg_dump MY_DB > bkp_MY_DB.dmp
> pg_dump: SQL command failed
> pg_dump: Error message from server: ERROR: invalid memory alloc
request size 18446744073709551613
> pg
Hi
In my Postgresql 8.4.0 server, since this morning some tables are
unavailable, see example below :
--> pg_dump MY_DB > bkp_MY_DB.dmp
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: invalid memory alloc request
size 18446744073709551613
pg_dump: The command was: COPY . (
Tom, Scott,
Thank you very much for your advice and right questions that lead to me the
solution - In summary, I was able to identify and delete all corrupted data
with no data loss. Everything add up once I disabled index per Tom's advice.
Here is the detail report:
Review the data again in order
On Fri, Feb 24, 2012 at 4:01 AM, Naoko Reeves wrote:
> -- I have narrowed down the row
> SELECT * FROM table ORDER BY table_id OFFSET 526199 LIMIT 1 -- ERROR:
> invalid memory alloc request size 1765277700
Are you certain that offset 526199 is using both the same query plan
and doesn't produce t
Scott Marlowe writes:
> On Fri, Feb 24, 2012 at 10:09 AM, Tom Lane wrote:
>> Naoko Reeves writes:
>>> [ inconsistent behavior with a corrupted table ]
>> I think most likely some of these queries are using a corrupted index
>> and some are not --- have you looked at the EXPLAIN for each one?
>>
On Fri, Feb 24, 2012 at 10:09 AM, Tom Lane wrote:
> Naoko Reeves writes:
>> [ inconsistent behavior with a corrupted table ]
>
> I think most likely some of these queries are using a corrupted index
> and some are not --- have you looked at the EXPLAIN for each one?
> It might be a good idea to t
Naoko Reeves writes:
> [ inconsistent behavior with a corrupted table ]
I think most likely some of these queries are using a corrupted index
and some are not --- have you looked at the EXPLAIN for each one?
It might be a good idea to turn off enable_indexscan and
enable_bitmapscan while poking a
Curious: was there some sort of hardware issue or anything like that preceding
this issue?
Version: "PostgreSQL 8.4.6 on i386-apple-darwin, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370),
32-bit"
There was an hardware crash.
after that pg_dump fail
Version: "PostgreSQL 8.4.6 on i386-apple-darwin, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370),
32-bit"
There was an hardware crash.
after that pg_dump failed with an error:
ERROR: invalid memory alloc request size 1765277700
I searched archive and it i
On 27.12.2011 23:23, Merlin Moncure wrote:
> On Tue, Dec 27, 2011 at 4:07 PM, Tomas Vondra wrote:
>> That's not likely. The corruption is usually the cause, when it hits
>> varlena header - that's where the length info is stored. In that case
>> PostgreSQL suddenly thinks the varlena field has a n
On Tue, Dec 27, 2011 at 4:07 PM, Tomas Vondra wrote:
>>> Googling around, it sounds like this is often due to table corruption,
>>> which would be unfortunate, but usually seems to be repeatable. I can
>>> re-run that query without issue, and in fact can select * from the entire
>>> table witho
On 27.12.2011 18:34, Ben Chobot wrote:
> On Dec 26, 2011, at 8:08 AM, Ben Chobot wrote:
>
>> Yesterday I had a problem on a 64-bit 9.1.1 install:
>>
>> # select version();
>>version
>>
>>
On Dec 26, 2011, at 8:08 AM, Ben Chobot wrote:
> Yesterday I had a problem on a 64-bit 9.1.1 install:
>
> # select version();
>version
>
>
Yesterday I had a problem on a 64-bit 9.1.1 install:
# select version();
version
---
"Andrus" <[EMAIL PROTECTED]> writes:
> SELECT * FROM firma1.toode WHERE toode LIKE 'ä%'
> causes error:
> ERROR: invalid memory alloc request size 2147483648
> SQL state: XX000
This looks like a problem already reported, and patched here:
http://archives.postgresql.org/pgsql-committers/2007-05/ms
SELECT * FROM firma1.toode WHERE toode LIKE 'ä%'
causes error:
ERROR: invalid memory alloc request size 2147483648
SQL state: XX000
How to fix ?
Andrus.
toode column type is char(20) and it is primary key.
toode table has index:
CREATE UNIQUE INDEX toode_toode_unique_pattern_idx
ON firma1
Brendan Duddridge <[EMAIL PROTECTED]> writes:
> Next exception:SQL State:XX000 -- error code: 0 -- msg: ERROR:
> invalid memory alloc request size 1684370054
> I'm not sure which memory setting I need to change to correct this.
This looks more like a "corrupt data" problem than an "insufficient
Hello,Today in our logs we received the following exception:Exception Message: EvaluateExpression failed: update category_product set product_is_active = p.is_active, product_status_code = p.status_code from product p where category_product.product_id = p.product_id and category_id = 1001415;Next
Tom Lane <[EMAIL PROTECTED]> writes:
> Janning Vygen <[EMAIL PROTECTED]> writes:
> > one more question: You mentioned standard disk and memory checks. Can you
> > point to some link where i can find more about it or which software do you
> > mean? I guess i have to start looking at it.
>
> The
Janning Vygen <[EMAIL PROTECTED]> writes:
> one more question: You mentioned standard disk and memory checks. Can you
> point to some link where i can find more about it or which software do you
> mean? I guess i have to start looking at it.
The stuff I've heard recommended is memtest86 for memo
Am Montag, 23. Januar 2006 21:57 schrieb Tom Lane:
> Janning Vygen <[EMAIL PROTECTED]> writes:
> > ok, shouldn't i upgrade to 8.1 instead of 8.0.6 if i can?
>
> Up to you --- you have more risk of compatibility issues if you do that,
> whereas within-branch updates are supposed to be painless. Dep
Janning Vygen <[EMAIL PROTECTED]> writes:
>> Hmm ... the one part of that that jumps out at me is plperl. We already
>> know that plperl can screw up the locale settings; I wonder whether
>> there are other bugs. Anyway, if you are using plperl I *strongly*
>> recommend updating to the latest PG
TOM! Ich will ein Kind von Dir!!
(it means 'something like': thank you so much. you just saved my life!)
Am Montag, 23. Januar 2006 21:16 schrieb Tom Lane:
> Janning Vygen <[EMAIL PROTECTED]> writes:
> >> OK, what's the schema of this table exactly?
> >
> > ...
> > Regeln:
> > cache_stip_delet
Janning Vygen <[EMAIL PROTECTED]> writes:
>> OK, what's the schema of this table exactly?
> ...
> Regeln:
> cache_stip_delete AS
> ON DELETE TO spieletipps DO UPDATE tsptcache SET tc_cache = -2
>FROM tippspieltage2spiele tspt2sp, spiele sp
> WHERE tsptcache.tr_kurzname = old.tr_kurz
Am Montag, 23. Januar 2006 20:30 schrieb Tom Lane:
> Janning Vygen <[EMAIL PROTECTED]> writes:
> > Ok, i got the reffilnode from pg_class and compiled pg_filedump. result
> > of ./pg_filedump -i -f -R 3397
> > /home/postgres8/data/base/12934120/12934361 > filedump.txt is attached
>
> OK, what's the
Janning Vygen <[EMAIL PROTECTED]> writes:
> Ok, i got the reffilnode from pg_class and compiled pg_filedump. result of
> ./pg_filedump -i -f -R 3397 /home/postgres8/data/base/12934120/12934361 >
> filedump.txt is attached
OK, what's the schema of this table exactly? It looks like there are
a co
Janning Vygen <[EMAIL PROTECTED]> writes:
> I shouldn't call gdb while my database is up and running, don't i?
Sure you can. Especially against a core dump --- that mode doesn't have
anything to do with the running processes.
> $ delete from spieletipps where ctid = '(3397,49)';
> Server beendet
Am Montag, 23. Januar 2006 17:05 schrieb Tom Lane:
> Janning Vygen <[EMAIL PROTECTED]> writes:
> > pg_dump: ERROR: invalid memory alloc request size 18446744073709551614
> > pg_dump: SQL command to dump the contents of table "spieletipps" failed:
> > PQendcopy() failed.
>
> This looks more like a
Janning Vygen <[EMAIL PROTECTED]> writes:
> pg_dump: ERROR: invalid memory alloc request size 18446744073709551614
> pg_dump: SQL command to dump the contents of table "spieletipps" failed:
> PQendcopy() failed.
This looks more like a corrupt-data problem than anything else. Have
you tried the
Hi,
my cron job which is dumping the databse fails this night. I got:
pg_dump: ERROR: invalid memory alloc request size 18446744073709551614
pg_dump: SQL command to dump the contents of table "spieletipps" failed:
PQendcopy() failed.
pg_dump: Error message from server: ERROR: invalid memory al
45 matches
Mail list logo
