Re: [BUGS] BUG #2694: Memory allocation error when selecting array
Tom Lane wrote:
"Vitali Stupin" <[EMAIL PROTECTED]> writes:
The error "invalid memory alloc request size 4294967293" apears when
selecting array of empty arrays:
select ARRAY['{}'::text[],'{}'::text[]];
I can get a core dump off it too, sometimes. The problem is in
ExecEvalArray, which computes the dimension of the result as [1:2]
even though there are no elements to put in it.
Joe, what do you think about this? Offhand I think that the only
workable definition is that this case yields another zero-dimensional
array, but maybe there is another choice?
Sorry for the slow response -- I'm at the airport just heading home from
a marathon 30 day business trip.
I think producing another zero-dimensional result is the only way that
makes sense unless/until we change multidimensional arrays to really be
arrays of array-datatype elements. Right now they're two different things.
We should probably check all the other array operations to see if they
have comparable problems.
Yes -- I'll see if I can find the time over the next couple weeks while
home.
Joe
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] corruption since 7.4.13 update ?
Just for your information. Our problem was caused by a bad firmware of one of the harddisk in the mirror. "An HP ProLiant server configured with any of the Ultra320 hard drives listed in Table 1 may experience an unsuccessful write operation when transferring data to the hard drive during periods of extreme disk intensive I/O operations. This event occurs only under rare conditions and ALL of the following criteria must be met in order for this event to occur: Disk intensive I/O operations are occurring that generate a queue of 112 commands on the affected disk drive. The 113th command queued on the drive is a write command that requires 256 blocks (or more) of data to be written to the drive. Note: While the depth of the command queue and the number of commands in the queue are critera for the occurrence of this event, obtaining this information is not necessary in order to determine affected hard drives. Affected hard drives are listed in Table 1 below and are identified when the HDDETECT Utility is run." http://h2.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&; taskId=110&prodSeriesId=397634&prodTypeId=15351&prodSeriesId=397634&objectID =PSD_EX050119_CW01 regards, -Franz -Ursprüngliche Nachricht- Von: Rasper, Franz Gesendet: Mittwoch, 9. August 2006 10:10 An: pgsql-bugs@postgresql.org Betreff: corruption since 7.4.13 update ? Hello, i have a "new" machine with following problem: postgres-7.4.13[7874]: [457-1] ERROR: could not open segment 1 of relation "data_server_id_idx" (target block 791807): No such file or directory I my point of view it seems the same error as: http://archives.postgresql.org/pgsql-admin/2006-07/msg00028.php http://archives.postgresql.org/pgsql-admin/2006-07/msg00103.php The server is an HP DL 380 G4 with Battery Backup write cache. I am doing a lot of inserts. (Linux + Postgresql 7.4.13) I works correctly on an other server (Linux + Postgresl 7.4.10 , HP DL 380 G3 without Battery Backup Write Cache). Linux + Postgresql 7.4.10 + HP DL 380 G3 without Battery Backup Write Cache it takes about 4 hours Linux + Postgresql 7.4.13 + HP DL 380 G4 with Battery Backup Write Cache it takes about 15 minutes Amount of RAM is the same (4 GB ) both have ext3 Filesystems What could be the reason ? Postgresql 7.4.13 ? Configuration ? Linux Kernel (2.4.28 vs. 2.4.32) ? Backup Write Cache ? Hardware ? The first time it works correctly. Next day ist doesnt work. Any help is appreciated. regrads, -Franz ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] 8.2beta1 (w32): server process crash (tsvector)
[offline ATM, can't look at the main issue, just wanted to get a comment in about fopen(). Unless beaten to it, I'll try to look at the other part later.] > on a sidenote: are those fopen() errors debug-code-leftovers > or something one should worry about? i can't find those files > on the file system. No. It's debugging output for a problem we had earlier, and will be removed before release. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2694: Memory allocation error when selecting array
Joe Conway <[EMAIL PROTECTED]> writes:
> Sorry for the slow response -- I'm at the airport just heading home from
> a marathon 30 day business trip.
Yow. Hope you get some time off...
> Tom Lane wrote:
>> "Vitali Stupin" <[EMAIL PROTECTED]> writes:
>>> The error "invalid memory alloc request size 4294967293" apears when
>>> selecting array of empty arrays:
>>> select ARRAY['{}'::text[],'{}'::text[]];
>>
>> Joe, what do you think about this? Offhand I think that the only
>> workable definition is that this case yields another zero-dimensional
>> array, but maybe there is another choice?
> I think producing another zero-dimensional result is the only way that
> makes sense unless/until we change multidimensional arrays to really be
> arrays of array-datatype elements. Right now they're two different things.
On looking at the code, I notice that this somewhat-related case works:
regression=# select array[null::text[], null::text[]];
array
---
{}
(1 row)
The reason is that null inputs are just ignored in ExecEvalArray. So
one pretty simple patch would be to ignore zero-dimensional inputs too.
This would have implications for mixed inputs though: instead of
regression=# select array['{}'::text[], '{a,b,c}'::text[]];
ERROR: multidimensional arrays must have array expressions with matching
dimensions
you'd get behavior like
regression=# select array[null::text[], '{a,b,c}'::text[]];
array
---
{{a,b,c}}
(1 row)
Which of these seems more sane?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] 8.2beta1 (w32): server process crash (tsvector)
No. It's debugging output for a problem we had earlier, and will be removed before release. thanks for clarifying. wasn't sure whether the comment in the release notes really was applying to these "file not found" error messages. Unless beaten to it, I'll try to look at the other part later in case more information / data is needed please let me know. if helpfull (i.e. bug not reproducable with my test data in the previous mail), full pgsql access could be set up as well. thanks in advance, thomas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
