Re: [BUGS] BUG #3811: Getting multiple values from a sequence generator
On Fri, 2007-12-14 at 10:47 +0100, Adriaan van Os wrote: > Simon Riggs wrote: > > On Mon, 2007-12-10 at 12:31 +0100, hubert depesz lubaczewski wrote: > >> On Sun, Dec 09, 2007 at 03:32:17PM +, Simon Riggs wrote: > >>> ALTER SEQUENCE blah INCREMENT BY val; > >> this has the sideeffect that all concurrent nextvals() will also > >> increment by val, which is not always acceptable. > > > > So this is a feature proposal, not a bug? > > > > Sounds interesting but needs to be on pgsql-hackers, please. > > I posted a message to pgsql-hackers three times but it gets stalled (and the > owner of the list > doesn't reply). Somebody will need to join pgsql-hackers. Other mail will be reflected because of spam. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3811: Getting multiple values from a sequence generator
Simon Riggs wrote: > On Fri, 2007-12-14 at 10:47 +0100, Adriaan van Os wrote: > > Simon Riggs wrote: > > > Sounds interesting but needs to be on pgsql-hackers, please. > > > > I posted a message to pgsql-hackers three times but it gets stalled (and > > the owner of the list > > doesn't reply). > > Somebody will need to join pgsql-hackers. Other mail will be reflected > because of spam. Even when it gets stalled, moderators (of which I am one) approve the message if it's not spam. I haven't received anything from Adrian as far as I can remember, leading to the idea that his mail is being lost for other reasons (because it's considered spam by some filter perhaps?). -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "Las cosas son buenas o malas segun las hace nuestra opinión" (Lisias) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Bug (#3484) - Invalid page header again
Hi folks, we had reported about various database problems some weeks ago. Since then we have updated the database to release 8.2.4 und the linux kernel to 2.6.22.6-smp. Now we got an error again: IN SHORT: - data is inserted - the same data is read and exported successfully - after a nightly vacuum analyze the data is corrupted and cannot be read any more. Error message(s): see below CONCLUSION Apparently the data is corrupted by "vacuum analyze". IN DETAIL: We got an error during the nightly dump again: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: invalid memory alloc request size 18446744073709551610 Some records in table "transaktion" (which contains about 45 million records) are corrupted. But the data has not been corrupted after insertion, it must have been corrupted later. Let us explain the track of the error: 1. 2007/12/07 ~3:30h: The (now corrupted) data was inserted successfully 2. 2007/12/07 7h : The (now corrupted) data was read and exported successfully! ( We run an export of the data every morning at 7h, which exports the data we retrieved/inserted during the last 24 hours ) 3. 2007/12/07 22h: Database was dumped successfully 4. 2007/12/07 23:15h: Database "vacuum analyze" was run successfully 5. 2007/12/08 22h: The database dump got the error described above: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: invalid memory alloc request size 18446744073709551610 6. 2007/12/08 23h: "vacuum analyze" threw an error: INFO: vacuuming "public.transaktion" WARNING: relation "transaktion" TID 1240631/12: OID is invalid ERROR: invalid page header in block 1240632 of relation "transaktion" 7. 2007/12/10 : We started the export of the data ( which runs every morning ) for the last days again. These exports use the same SQL-Commands as the automatical run. But now, we got an error when exporting the data for 2007/12/07. ERROR: invalid memory alloc request size 18446744073709551610 The process exporting the same set of data ran successfully in the morning of the 2007/12/07: We are very sure, that the data has not been manipulated since the time of insertion, because the error occurs on the testing system and at the moment no tests except from inserting and exporting the data are done. 8. 2007/12/14 When we now start a select over the corrupted data, we get the error message: ERROR: could not access status of transaction 313765632 DETAIL: Could not open file "pg_clog/012B": Datei oder Verzeichnis nicht gefunden. We are using Linux version: 2.6.22.6-smp. Hardware system: 2 dual core processor ( Intel(R) Xeon(TM) CPU 2.80GHz ) postgres-Version: 8.2.4 Original-Nachricht Betreff: Missing pg_clog file / corrupt index / invalid page header Datum: Wed, 05 Sep 2007 08:18:31 +0200 Von: alex <[EMAIL PROTECTED]> Organisation: click:ware GmbH An: pgsql-bugs@postgresql.org My colleague Marc Schablewski reported this Bug (#3484) the first time at the end of July. The described problem occured twice at our database and now it happened again. Summary == Various errors like: "invalid page header in block 8658 of relation", "could not open segment 2 of relation 1663/77142409/266753945 (target block 809775152)", "ERROR: could not access status of transaction 2134240 DETAIL: could not open file "pg_clog/0002": File not found", "CEST PANIC: right sibling's left-link doesn't match" on the following system: Postgres 8.1.8 SUsE Linux Kernel 2.6.13-15.8-smp 2 Intel XEON Processors with 2 cores each ECC-Ram Hardware Raid (mirror set) Detailed description === The message was thrown by the nightly pg_dump: pg_dump: ERROR: invalid page header in block 8658 of relation "import_data_zeilen" pg_dump: SQL command to dump the contents of table "import_data_zeilen" failed: PQendcopy() failed. pg_dump: Error message from server: ERROR: invalid page header in block 8658 of relation "import_data_zeilen" pg_dump: The command was: COPY public.import_data_zeilen (id, eda_id, zeile, man_id, sta_id) TO stdout; A manually executed dedicated dump on the concerned table was processed successfully ( at daytime! ) We were really suprised! Also, select-queries (using indexes) on the table succeeded. (in the past when the error occured, select-queries failed). So, no repair seemed to be needed for the table. The following night, the pg_dump succeeded, but the "vacuum analyze" (executed after the pg_dump) threw the same error: INFO: vacuuming "public.import_data_zeilen" ERROR: invalid page header in block 8658 of relation "import_data_zeilen" Any select on this table using indexes now failed! ( if the resultset contained the corrupted data ) This behaviour is very confusing. Re-creating the table solved the problem. However, the damaged rows were lost. We have two systems, one active, one for tests. They are nearly identical, having similar hardare, using the same software and they are running under the same l
[BUGS] BUG #3816: Timezone bug
The following bug has been logged online: Bug reference: 3816 Logged by: Geert Bijloos Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 and 8.2.4 Operating system: Linux Description:Timezone bug Details: Try this SET TIMEZONE TO 'CET'; SELECT (timestamp with time zone '2000-01-01 UT' + interval '86 days 0 hours 5 min 0 sec') at time zone 'UT'; "2000-03-26 23:05:00" -> WRONG SET TIMEZONE TO 'UTC'; SELECT (timestamp with time zone '2000-01-01 UT' + interval '86 days 0 hours 5 min 0 sec') at time zone 'UT'; "2000-03-27 00:05:00" -> RIGHT It can be reproduced for several timezones. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3816: Timezone bug
"Geert Bijloos" <[EMAIL PROTECTED]> writes: > Try this > SET TIMEZONE TO 'CET'; > SELECT (timestamp with time zone '2000-01-01 UT' + interval '86 days 0 hours > 5 min 0 sec') at time zone 'UT'; > "2000-03-26 23:05:00" -> WRONG On what grounds do you claim that that's wrong? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug (#3484) - Invalid page header again
alex <[EMAIL PROTECTED]> writes: > Given that the problem occurred on two different machines we are very > sure that it is *not* a hardware problem. I wouldn't be so sure, especially not when the behavior looks like a hardware problem in every other respect. You've heard of common-mode failures, no? Do both machines have RAM chips from the same batch, for instance? regards, tom lane ---(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 (#3484) - Invalid page header again
alex wrote: WARNING: relation "transaktion" TID 1240631/12: OID is invalid ERROR: invalid page header in block 1240632 of relation "transaktion" 7. 2007/12/10 : We started the export of the data ( which runs every morning ) for the last days again. These exports use the same SQL-Commands as the automatical run. Alex, please can you provide binary dump of these two pages or if there are sensitive data try to use pg_filedump to get only page and tuple headers? Zdenek ---(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 #3816: Timezone bug
"Geert Bijloos" <[EMAIL PROTECTED]> writes: > The following bug has been logged online: > PostgreSQL version: 8.1.3 and 8.2.4 > Description:Timezone bug Without actually checking whether the results are wrong I'll note that several of the changes in the bug-fix releases post 8.1.3 and 8.2.4 are timezone updates. (And since 8.1.3 there were several crashing and data eating bugs fixed in those bug-fix releases) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #3817: about service
The following bug has been logged online: Bug reference: 3817 Logged by: Avanttec Medical System Email address: [EMAIL PROTECTED] PostgreSQL version: 8 Operating system: windows xp Description:about service Details: i am using number of database on the postgresql ,on the time running the database.In the backend number of service are runnning on task manager . please liste those service which run on the postgresql.Other wise please tell me how to avoid the service which runs on the taskmanager.reply me soon ---(end of broadcast)--- TIP 6: explain analyze is your friend
