[BUGS] could not truncate directory "pg_subtrans": apparent wraparound

2011-12-04 Thread MirrorX
hello to all, i found this error in the logs on the hot_standby server. this error appeared only once a few days back and hasn't come up again. the version i am using is 9.0.5 and the primary was loaded by restoring dump files (previous version was 8.4.4). i have never switched to this server and

[BUGS] BUG #6325: Useless Index updates

2011-12-04 Thread dmigowski
The following bug has been logged on the website: Bug reference: 6325 Logged by: Daniel Migowski Email address: dmigow...@ikoffice.de PostgreSQL version: 8.3.16 Operating system: Linux Description: It seems that an update to a row in a table always removes the element

Re: [BUGS] BUG #6325: Useless Index updates

2011-12-04 Thread Craig Ringer
On 12/04/2011 08:54 PM, dmigow...@ikoffice.de wrote: The following bug has been logged on the website: Bug reference: 6325 Logged by: Daniel Migowski Email address: dmigow...@ikoffice.de PostgreSQL version: 8.3.16 Operating system: Linux Description: It seems that an update

Re: [BUGS] BUG #6325: Useless Index updates

2011-12-04 Thread hubert depesz lubaczewski
On Sun, Dec 04, 2011 at 12:54:25PM +, dmigow...@ikoffice.de wrote: > It seems that an update to a row in a table always removes the element from > an index and adds it again. Wouldn't it be faster to check for equality of > the index parameters in the OLD and NEW record first? http://www.depe

Re: [BUGS] BUG #6325: Useless Index updates

2011-12-04 Thread Andreas Karlsson
On 2011-12-04 15:02, Craig Ringer wrote: - The index isn't always updated. Check out HOT (introduced in 8.4, the release after your current one) which reduces unnecessary index updates in cases where the old and new row can fit on the same heap page. Minor correction: HOT was introduced in 8.3.

Re: [BUGS] BUG #6325: Useless Index updates

2011-12-04 Thread Craig Ringer
On 12/05/2011 08:16 AM, Andreas Karlsson wrote: On 2011-12-04 15:02, Craig Ringer wrote: - The index isn't always updated. Check out HOT (introduced in 8.4, the release after your current one) which reduces unnecessary index updates in cases where the old and new row can fit on the same heap pag

[BUGS] BUG #6326: SELECT ARRAY(SELECT ...) syntax and array[] results doesn't work

2011-12-04 Thread maxim . boguk
The following bug has been logged on the website: Bug reference: 6326 Logged by: Maksym Boguk Email address: maxim.bo...@gmail.com PostgreSQL version: 9.1.1 Operating system: Linux Description: SELECT ARRAY(SELECT ...) doesn't work when subselect return any array. T

Re: [BUGS] BUG #6326: SELECT ARRAY(SELECT ...) syntax and array[] results doesn't work

2011-12-04 Thread Tom Lane
maxim.bo...@gmail.com writes: > SELECT ARRAY(SELECT ...) > doesn't work when subselect return any array. > Is that syntax supposed to work with anyarray types? No. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your

Re: [BUGS] BUG #6326: SELECT ARRAY(SELECT ...) syntax and array[] results doesn't work

2011-12-04 Thread Maxim Boguk
On Mon, Dec 5, 2011 at 2:05 PM, Tom Lane wrote: > maxim.bo...@gmail.com writes: > > SELECT ARRAY(SELECT ...) > > doesn't work when subselect return any array. > > Is that syntax supposed to work with anyarray types? > > No. > >regards, tom lane > Hi. Thank you very much

Re: [BUGS] BUG #6326: SELECT ARRAY(SELECT ...) syntax and array[] results doesn't work

2011-12-04 Thread Tom Lane
Maxim Boguk writes: > PS: I try create two-dimentional integer array from query results: Well, you could do that with a suitably defined aggregate having the signature "agg(anyarray) returns anyarray". But array_agg has the signature "array_agg(anyelement) returns anyarray" so you can't use it

Re: [BUGS] possible bug seen with -DCLOBBER_CACHE_ALWAYS and changing GUCs

2011-12-04 Thread Noah Misch
On Wed, Nov 30, 2011 at 08:10:22PM -0500, Tom Lane wrote: > Jeff Davis writes: > > SQL: > > set datestyle to postgres,us; > > prepare stmt as select '02-01-2011'::date::text; > > execute stmt; > > set datestyle to postgres,euro; > > execute stmt; > > deallocate stmt; > > > The results