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 4/27/15 8:45 AM, Marc-André Goderre wrote:
Can I change the segment size to allow more memory?
Is it a good idea?
The concerned function work only on the entire table then I can't process a
part of it.
Should I split the table in multiple table and merge them after the process?
Please don't
Chris Mair [mailto:ch...@1006.org]
Envoyé : 24 avril 2015 15:41
À : Marc-André Goderre; pgsql-general@postgresql.org
Objet : Re: [GENERAL] Invalid memory alloc
> I use Postgis and PGrouting extension.
> The error come when I use a pgrouting function pgr_createtopology()
It appears pgrouting
> I use Postgis and PGrouting extension.
> The error come when I use a pgrouting function pgr_createtopology()
It appears pgrouting violates the 1GB per chunk limit in the postgres backend
when processing large datasets:
https://github.com/pgRouting/pgrouting/issues/291
Bye,
Chris.
--
Sent
origine-
De : pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] De la part de Edson Richter
Envoyé : 23 avril 2015 16:16
À : pgsql-general@postgresql.org
Objet : Re: [GENERAL] Invalid memory alloc
On 23-04-2015 16:55, Marc-André Goderre wrote:
> Hello, I'm proce
De la part de Edson Richter
Envoyé : 23 avril 2015 16:16
À : pgsql-general@postgresql.org
Objet : Re: [GENERAL] Invalid memory alloc
On 23-04-2015 16:55, Marc-André Goderre wrote:
> Hello, I'm processing a 100Million row table.
> I get error message about memory and I'ld like t
Jim Nasby writes:
> We need more information from the OP about what they're doing.
Yeah. Those NOTICEs about "nnn edges processed" are not coming out of
anything in core Postgres; I'll bet whatever is producing those is at
fault (by trying to palloc indefinitely-large amounts of memory as a
sing
On 4/23/15 3:15 PM, Edson Richter wrote:
My question would sound stupid... you have 10Gb shared buffer, but how
much physical memory on this server?
How have you configured the kernel swappines, overcommit_memoryt,
overcommit_ratio?
Have you set anything different in shmmax or shmall?
I don't t
> Hello, I'm processing a 100Million row table.
> I get error message about memory and I'ld like to know what can cause this
> issue.
>
> ...
> psql:/home/ubuntu/create_topo.sql:12: NOTICE: 104855000 edges processed
> psql:/home/ubuntu/create_topo.sql:12: NOTICE: 104856000 edges processed
> ps
On 23-04-2015 16:55, Marc-André Goderre wrote:
Hello, I'm processing a 100Million row table.
I get error message about memory and I'ld like to know what can cause this
issue.
...
psql:/home/ubuntu/create_topo.sql:12: NOTICE: 104855000 edges processed
psql:/home/ubuntu/create_topo.sql:12: NOTI
Hello, I'm processing a 100Million row table.
I get error message about memory and I'ld like to know what can cause this
issue.
...
psql:/home/ubuntu/create_topo.sql:12: NOTICE: 104855000 edges processed
psql:/home/ubuntu/create_topo.sql:12: NOTICE: 104856000 edges processed
psql:/home/ubuntu/
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
---
Guy Helmer writes:
> On the system where I captured the backtrace, there are several
> 400MB-long entries in the textdata column. I inserted these entries by
> doing an "INSERT (..., textdata) VALUES (..., $1)", mmap'ed the data
> from a file into memory, and executed the command using PQexecP
Tom Lane wrote:
Guy Helmer writes:
Tom Lane wrote:
Normally I'd say "data corruption", but it is odd if you got the
identical message from two different machines. Can you reproduce
it with a debugger attached? If so, a backtrace from the call of
errfinish might be useful.
Guy Helmer writes:
> Tom Lane wrote:
>> Normally I'd say "data corruption", but it is odd if you got the
>> identical message from two different machines. Can you reproduce
>> it with a debugger attached? If so, a backtrace from the call of
>> errfinish might be useful.
> Yes, here is the backt
Tom Lane wrote:
Guy Helmer writes:
On systems running Postgresql 8.3.6, I have a nightly backup using
pg_dump that failed on two machines overnight with this error:
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: invalid memory alloc request size
137600642
Guy Helmer writes:
> On systems running Postgresql 8.3.6, I have a nightly backup using
> pg_dump that failed on two machines overnight with this error:
> pg_dump: SQL command failed
> pg_dump: Error message from server: ERROR: invalid memory alloc request size
> 1376006425
> pg_dump: The comm
On systems running Postgresql 8.3.6, I have a nightly backup using
pg_dump that failed on two machines overnight with this error:
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: invalid memory alloc request size
1376006425
pg_dump: The command was: COPY public.tablename
"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
Thank you and other helpfully peoples the interest about my first steps
in your world. I learned more than I hope.
This function work fine now.
Can you to offer me place where I find these information, because I read
the postgresql source code to find these macros.
Regards,
Josef
Dudás Józ
This is the debug of last varcharout routine:
Breakpoint 1, varcharout (fcinfo=0xbf8a1e7c) at varchar.c:441
441 VarChar*s = PG_GETARG_VARCHAR_P(0);
440 {
(gdb) print fcinfo
$25 = (FunctionCallInfo) 0xbf8a1e7c
441 VarChar*s = PG_GETARG_VARCHAR_P(0);
446
Dudás József <[EMAIL PROTECTED]> writes:
> Yes! You are right! Now must me find out how to convert char* to numeric datum
> and double to numeric datum and numeric datum to double :)
If you have a char* you can usually call a types input function which is
usally "type_in" or "typein" like:
Dir
Yes! You are right! Now must me find out how to convert char* to numeric
datum and double to numeric datum and numeric datum to double :)
=?ISO-8859-2?Q?Dud=E1s_J=F3zsef?= <[EMAIL PROTECTED]> writes:
Just have problem with this conversion from TEXT - double - Datum (
NUMERIC ) where in TEX
Thanks your replies, these much help me. I am beginer in postgresql c
function, sorry when I wrote stupid thinks too.
This function not call from sql just from c code. So as I understand not
need PG_FUNCTION_INFO_V1 macro. It is need in case I want to call routin
direct from sql or make database
Are you compiling with warnings? Because this should have blown up on
you:
On Fri, Jun 01, 2007 at 02:03:26PM +0200, Dudás József wrote:
> PG_FUNCTION_INFO_V1(_selectFunctionB);
> Datum
> _selectFunctionB( char *sql )
If you've declared your function V1 then it doesn't get passed
parameters like
=?ISO-8859-2?Q?Dud=E1s_J=F3zsef?= <[EMAIL PROTECTED]> writes:
> Just have problem with this conversion from TEXT - double - Datum (
> NUMERIC ) where in TEXT is a number value forexample now the value is 1.00
NUMERIC? You didn't say anything about NUMERIC before. The code you
posted thinks it i
Dudás József <[EMAIL PROTECTED]> writes:
> Sorry I do not understand. I did not convert float to varchar.
Well then there's some kind of miscommunication here. Your crash is happening
trying to read a varchar column later. Someone sometime is putting data into
that varchar column. I don't under
Sorry I do not understand. I did not convert float to varchar. The first
3 data are char* these conver to Datum:
attnum[0] = SPI_fnumber( tupdesc, "deviza_kod" );
datums[0] = DirectFunctionCall1(textin, CStringGetDatum(
_selectFunction( "SELECT ertek FROM foo WHERE parameter='currency'" ) ) );
This is the debug of last varcharout routine:
Breakpoint 1, varcharout (fcinfo=0xbf8a1e7c) at varchar.c:441
441 VarChar*s = PG_GETARG_VARCHAR_P(0);
440 {
(gdb) print fcinfo
$25 = (FunctionCallInfo) 0xbf8a1e7c
441 VarChar*s = PG_GETARG_VARCHAR_P(0);
446
Dudás József <[EMAIL PROTECTED]> writes:
> Here is the output from gdb:
>
> #0 errfinish (dummy=0) at elog.c:312
> #1 0x0827f378 in elog_finish (elevel=20,
>fmt=0x83586d8 "invalid memory alloc request size %lu") at elog.c:937
> #2 0x082983d7 in MemoryContextAlloc (context=0x843a1ac, size=4
Here is the output from gdb:
#0 errfinish (dummy=0) at elog.c:312
#1 0x0827f378 in elog_finish (elevel=20,
fmt=0x83586d8 "invalid memory alloc request size %lu") at elog.c:937
#2 0x082983d7 in MemoryContextAlloc (context=0x843a1ac, size=4294967293)
at mcxt.c:504
#3 0x0825751d in varchar
Thanks for your reply!
I was run gdb and errfinish but didn't get much help because I write to
list.
Yes the first datas ( datums[0-2] ) are char* / VARCHAR types and if I
call SPI_modifytuple( ( trigdata->tg_relation, tmptuple, 3, &attnum[0],
&datums[0], &isNull[0] ) than everything is OK.
Jus
=?ISO-8859-2?Q?Dud=E1s_J=F3zsef?= <[EMAIL PROTECTED]> writes:
> I know that something doing wrong, but I can't find out what is it.
Getting a stack trace from the point of the errfinish call would
probably help narrow it down. One thing that's not clear is whether
SPI_modifytuple itself is failin
Hello Everybody!
I know that something doing wrong, but I can't find out what is it. This
is a part from trigger function:
/
attnum[3] = SPI_fnumber( tupdesc, "arfolyam" );
datums[3] = _selectFunctionB( "SELECT ertek FROM foo WHERE
parameter='rate'" ); // this come back with Datum type from se
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
Greg Stark wrote:
> 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 h
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
I second Tom:
badblocks and memtest86 are what I use and works great on all kinds of
hardware. You don't even need a specific OS for memtest86 because you
can make a bootable floppy and test any old piece of hardware it recognizes.
Terry
--
Terry Fielder
[EMAIL PROTECTED]
Associate Directo
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
78 matches
Mail list logo
