Re: [HACKERS] Unrecognized type error (postgres 9.1.4)
On Sat, Apr 6, 2013 at 12:23 AM, Amit Kapila amit.kap...@huawei.com wrote: On Saturday, April 06, 2013 3:57 AM Rodrigo Barboza wrote: Hello. I created a type my_uint that is a unsigned int 32. I am trying to update data of a table that contains a column of this type. Here is what happens: postgresql= explain analyze UPDATE attribute_type_conf SET rowform = rowform +1 where rowform = 18; ERROR: unsupported type: 132852 Can you post your complete test (like your type creation and its use for table and any initial data you loaded to it)? With Regards, Amit Kapila. Well, it's a lot of data. May I send it atached?
Re: [HACKERS] Enabling Checksums
On 05.04.2013 23:25, Kevin Grittner wrote: Jeff Davispg...@j-davis.com wrote: Also, the first version doesn't necessarily need to perform well; we can leave optimization as future work. +1, as long as we don't slow down instances not using the feature, and we don't paint ourselves into a corner. Speaking of which: I did some profiling yesterday of a test case that's heavy on WAL insertions, without checksums. I saw BufferGetLSNAtomic consuming 1.57% of the CPU time. That's not much, but it's clearly additional overhead caused by the checksums patch: Events: 6K cycles + 26,60% postmaster postgres [.] XLogInsert + 6,15% postmaster postgres [.] LWLockAcquire + 4,74% postmaster postgres [.] LWLockRelease + 2,47% postmaster postgres [.] PageAddItem + 2,19% postmaster postgres [.] ReadBuffer_common + 2,18% postmaster postgres [.] heap_fill_tuple + 1,95% postmaster postgres [.] ExecNestLoop + 1,89% postmaster postgres [.] ExecModifyTable + 1,85% postmaster postgres [.] heap_insert + 1,82% postmaster postgres [.] heap_prepare_insert + 1,79% postmaster postgres [.] heap_form_tuple + 1,76% postmaster postgres [.] RelationGetBufferForTuple + 1,75% postmaster libc-2.13.so [.] __memcpy_ssse3 + 1,73% postmaster postgres [.] PinBuffer + 1,67% postmaster postgres [.] hash_any + 1,64% postmaster postgres [.] ExecProcNode + 1,63% postmaster postgres [.] RelationPutHeapTuple + 1,57% postmaster postgres [.] BufferGetLSNAtomic + 1,51% postmaster postgres [.] ExecProject + 1,42% postmaster postgres [.] hash_search_with_hash_value + 1,34% postmaster postgres [.] AllocSetAlloc + 1,21% postmaster postgres [.] UnpinBuffer + 1,19% postmaster [kernel.kallsyms] [k] copy_user_generic_string + 1,13% postmaster postgres [.] MarkBufferDirty + 1,07% postmaster postgres [.] ExecScan + 1,00% postmaster postgres [.] ExecMaterializeSlot AFAICS that could be easily avoided by doing a simple PageGetLSN() like we used to, if checksums are not enabled. In XLogCheckBuffer: /* * XXX We assume page LSN is first data on *every* page that can be passed * to XLogInsert, whether it otherwise has the standard page layout or * not. We don't need the buffer header lock for PageGetLSN because we * have exclusive lock on the page and/or the relation. */ *lsn = BufferGetLSNAtomic(rdata-buffer); Also, the second sentence in the above comment is completely bogus now. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
On 6 April 2013 01:59, Kevin Grittner kgri...@ymail.com wrote: Brendan Jurd dire...@gmail.com wrote: The language specifically allows for zero elements, and does not contemplate multiple dimensions. I don't remember anything in the spec which would prohibit the data type of an array element from itself being an array, however. Indeed it does not prohibit nesting arrays inside other arrays, but the multidim arrays that Postgres allows you to create are not the same thing as nested arrays. I believe that a purely to-spec implementation would allow you to make an array-of-int-arrays, but since each element is its own separate collection there would be no requirement that they have the same cardinality as each other. For example, ARRAY[[1], [2,3], [4,5,6]] is a valid collection per the spec, but Postgres won't let you create this, because Postgres is trying to create a 2-D matrix of integers, rather than a collection of collections of integers. The inability to extend multidim arrays in Postgres is another manifestation of this matrix-oriented design. Extending nested collections is a no-brainer. Extending matrices while ensuring they remain perfectly regular ... not so much. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Fwd: Range types (DATERANGE, TSTZRANGE) in a foreign key with inclusion logic
Hello, this is a re-post from the SQL user list 2 month ago, because I assume only a developer can answer the questions below. Thanks, Matthias Nagel -- Weitergeleitete Nachricht -- Betreff: Range types (DATERANGE, TSTZRANGE) in a foreign key with inclusion logic Datum: Mittwoch 23 Januar 2013, 11:28:10 Von: Matthias Nagel matthias.h.na...@gmail.com An: pgsql-...@postgresql.org Hello everybody, first a big thank you to all that make the range types possible. They are great, especially if one runs a database to manage a student's university dormitory with a lot of temporal information like rental agreements, room allocations, etc. At the moment we are redesigning our database scheme for PosgreSQL 9.2, because the new range types and especially the EXCLUSION constraints allow to put a lot more (business) logic into the database scheme than before. But there is one feature missing (or I am too stupid to find it). Let's say we have some kind of container with a lifetime attribute, i.e. something like that CREATE TABLE container ( id SERIAL PRIMARY KEY, lifetime DATERANGE ); Further, there are items that must be part of the container and these items have a lifetime, too. CREATE TABLE item ( id SERIAL PRIMARY KEY, container_id INTEGER, lifetime DATERANGE, FOREIGN KEY (container_id) REFERENCES container ( id ), EXCLUDE USING gist ( container_id WITH =, lifetime WITH ) ); The foreign key ensures that items are only put into containers that really exist and the exclude constraint ensure that only one item is member of the same container at any point of time. But actually I need a little bit more logic. The additional contraint is that items must only be put into those containers whose lifetime covers the lifetime of the item. If an item has a lifetime that exceeds the lifetime of the container, the item cannot be put into that container. If an item is already in a container (with valid lifetimes) and later the container or the item is updated such that either lifetime is modified and the contraint is not fullfilled any more, this update must fail. I would like to do someting like: FOREIGN KEY ( container_id, lifetime ) REFERENCES other_table ( id, lifetime ) USING gist ( container_id WITH =, lifetime WITH @ ) (Of course, this is PosgreSQL-pseudo-code, but it hopefully make clear what I want.) So, now my questions: 1) Does this kind of feature already exist in 9.2? If yes, a link to the documentation would be helpful. 2) If this feature does not directly exist, has anybody a good idea how to mimic the intended behaviour? 3) If neither 1) or 2) applies, are there any plans to integrate such a feature? I found this discussion http://www.postgresql.org/message-id/4f8bb9b0.5090...@darrenduncan.net . Does anybody know about the progress? Having range types and exclusion contraints are nice, as I said in the introdruction. But if the reverse (foreign key with inclusion) would also work, the range type feature would really be amazing. Best regards, Matthias Nagel -- Matthias Nagel Willy-Andreas-Allee 1, Zimmer 506 76131 Karlsruhe Telefon: +49-721-8695-1506 Mobil: +49-151-15998774 e-Mail: matthias.h.na...@gmail.com ICQ: 499797758 Skype: nagmat84 - -- Matthias Nagel Willy-Andreas-Allee 1, Zimmer 506 76131 Karlsruhe Telefon: +49-721-8695-1506 Mobil: +49-151-15998774 e-Mail: matthias.h.na...@gmail.com ICQ: 499797758 Skype: nagmat84 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [PATCH] Exorcise zero-dimensional arrays (Was: Re: [HACKERS] Should array_length() Return NULL)
Brendan Jurd dire...@gmail.com wrote: On 6 April 2013 01:59, Kevin Grittner kgri...@ymail.com wrote: Brendan Jurd dire...@gmail.com wrote: The language specifically allows for zero elements, and does not contemplate multiple dimensions. I don't remember anything in the spec which would prohibit the data type of an array element from itself being an array, however. Indeed it does not prohibit nesting arrays inside other arrays, but the multidim arrays that Postgres allows you to create are not the same thing as nested arrays. I believe that a purely to-spec implementation would allow you to make an array-of-int-arrays, but since each element is its own separate collection there would be no requirement that they have the same cardinality as each other. For example, ARRAY[[1], [2,3], [4,5,6]] is a valid collection per the spec, but Postgres won't let you create this, because Postgres is trying to create a 2-D matrix of integers, rather than a collection of collections of integers. The inability to extend multidim arrays in Postgres is another manifestation of this matrix-oriented design. Extending nested collections is a no-brainer. Extending matrices while ensuring they remain perfectly regular ... not so much. Your interpretation matches mine all around. It is unfortunate that we have hijacked the standard's syntax for arrays to add a matrix feature. It seems to leave us without any way forward on these issues that I like very much. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] corrupt pages detected by enabling checksums
On 2013-04-05 16:29:47 -0700, Jeff Davis wrote: On Fri, 2013-04-05 at 15:09 +0200, Andres Freund wrote: How does the attached version look? I verified that it survives recovery, but not more. Comments: * Regarding full page writes, we can: - always write full pages (as in your current patch), regardless of the current settings - take WALInsertLock briefly to get the current settings from XLogCtl - always calculate the full page record, but in XLogInsert, if it happens to be a HINT record, and full page writes are not necessary, then discard it (right now I somewhat favor this option but I haven't looked at the details) I feel pretty strongly that we shouldn't add any such complications to XLogInsert() itself, its complicated enough already and it should be made simpler, not more complicated. I think we can just make up the rule that changing full page writes also requires SpinLockAcquire(xlogctl-info_lck);. Then its easy enough. And it can hardly be a performance bottleneck given how infrequently its modified. In retrospect I think making up the rule that full_page_writes changes imply a checkpoint would have made things easier performance and codewise. * typo in Backup blocks are not used in **xlog xlog** records Thats just me being funny after some long days ;). See its an 'xlog' 'xlog record'. * To get the appropriate setting for buffer_std, we should pass it down through MarkBufferDirty as an extra flag, I think. Or just declare as part of the api that only std buffers are allowed to be passed down. After a quick look it looks like all callers use enough of the standard page layout to make that viable. But that really was just a quick look. * I'm a bit worried that we'll need a cleanup lock when restoring an FSM page. What do you think? I don't yet see why, while recovery is ongoing there shouldn't be anyone doing anything concurrently to it but startup itself? * In xlog_redo, it seemed slightly awkward to call XLogRecGetData twice. Merely a matter of preference but I thought I would mention it. Youre absolutely right, memcpy should have gotten passed 'data', not XLogRecGetData(). Jeff, any chance you can run this for a round with your suite? Yes. I don't have a rigorous test suite, but I'll do some manual tests and walk through it with gdb. Heh, in this and only this I was talking to Jeff Janes. Strangely I never had noticed that you share the same name ;) Thanks! Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Back branches vs. gcc 4.8.0
Peter Eisentraut pete...@gmx.net writes: The reason that the whole code wasn't converted right away was (besides a lot of legwork with sizeof and offsetoff) that flexible array members aren't allowed in the middle of structs. Which eventually led to the mentioned commit 8137f2c32322c624e0431fac1621e8e9315202f9. If someone wants to go through and change the rest of the code to use FLEXIBLE_ARRAY_MEMBER, I won't mind. But I think it actually has nothing to do with the current bug or future-proofing anything. All compilers tolerate the current coding. The reason I'm thinking it's a good idea is that it would expose any remaining places where we have nominally var-length arrays embedded in larger structs. Now that I've seen the failures with gcc 4.8.0, I'm quite worried that there might be some more declarations like that which we've not identified yet, but that by chance aren't causing obvious failures today. (This is also why I'm not that excited about trying to fix things properly in the back branches compared to selecting -fno-aggressive-loop-optimizations: I'm afraid there might be more to it than just the one commit.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] corrupt pages detected by enabling checksums
On Fri, Apr 5, 2013 at 6:09 AM, Andres Freund and...@2ndquadrant.comwrote: How does the attached version look? I verified that it survives recovery, but not more. Jeff, any chance you can run this for a round with your suite? I've run it for a while now and have found no problems. Thanks, Jeff
[HACKERS] Re: [BUGS] BUG #8043: 9.2.4 doesn't open WAL files from archive, only looks in pg_xlog
On Sat, Apr 6, 2013 at 1:24 AM, Heikki Linnakangas hlinnakan...@vmware.comwrote: Incidentally, I bumped into another custom backup script just a few weeks back that also excluded backup_label. I don't know what the author was thinking when he wrote that, but it seems to be a surprisingly common mistake. Maybe it's the label in the filename that makes people think it's not important. I think part of it is the name label', and part of it is that this file is similar to and hence easily confused with the .history files, which (as far as I know) truly are there only for human information and not for system operation. Perhaps we should improve the documentation to make it more explicit that backup_label must be included in the backup. The docs already say that, though, so I suspect that people making this mistake have not read the docs very carefully anyway. I don't think the docs are very clear on that. They say This file will of course be archived as a part of your backup dump file, but will be does not imply must be. Elsewhere it emphasizes that the label you gave to pg_start_backup is written into the file, but doesn't really say what the file itself is there for. To me it seems to imply that the file is there for your convenience, to hold that label, and not as a critical part of the system. Patch attached, which I hope can be back-patched. I'll also add it to commitfest-Next. Cheers, Jeff backup_label_warning_v1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PROPOSAL: tracking aggregated numbers from pg_stat_database
Hi, I'm regularly using pg_stat_database view to analyze various aspects of behavior of the cluster. The #1 issue I'm constantly running into is that to get cluster-level view (across all the databases), the table needs to be aggregated like this: SELECT SUM(blks_hit) blks_hit, SUM(blks_read) blks_read FROM pg_stat_database This more or less works in stable environments, but once you start dropping databases (think of hosting with shared DB server) it gets unusable because after DROP DATABASE the database suddenly disappears from the sum. Therefore I do propose tracking the aggregated stats, similar to the pg_stat_bgwriter view. This does not require new messages (thanks to reuse of the existing messages), and I expect the overhead to be negligible (a few bytes of storage, minimal CPU). I think it does not make sense to merge this into pg_stat_bgwriter, creating a new view (can't think of a good name though), seems like a much better choice to me. And now a bit more detailed explanation of the issues ... Analysis is usually based on comparing two snapshots (say a few minutes apart), and this makes is rather much more difficult because the dropped databases suddenly disappear from the second snapshot. Say for example there are two databases, A and B, with stats snapshotted at T1 and T2. The database B is dropped sometimes between the snapshots. So the snaphots look like this: time | db | blks_read | bkls_hit --- T1 | A | 100 | 50 T1 | B | 100 | 50 T2 | A | 150 | 75 Now, the aggregated data look like this: time | blks_read | bkls_hit -- T1 | 200 | 100 T2 | 150 | 75 So the difference (T2-T1) is blks_read | bkls_hit -- -50 | -25 Yes, negative values do not make much sense. It's very difficult to detect such behavior and account for that. It might be possible to solve (some of) the issues with elaborate snapshotting system, but it's awkward / difficult to use. Adding a new system view works much nicer. regards Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Process title for autovac
I've often wanted to know what the autovacuum worker was doing. The process title seems like the best place to get this information, but the process title tells me what database it is in, but not what table it is working on. The attached patch demonstrates the concept of what I want. I put the code in table_recheck_autovac not because I think that is the best location, but just because it was the easiest point at which I knew how to get the table name easily before classTup gets destroyed. Example output: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 16392 jjanes20 0 229m 19m 6948 S 3.6 1.0 0:06.85 postgres: autovacuum worker process jjanes.public.pgbench_accounts I never reset the process title back to the initial state of just having a database name and no table. Which I can get away with temporarily because the autovac worker never dilly-dallies between tables, it either goes to the next one, or exits. A real implementation would probably want to reset it anyway, though. Is this functionality something we want? If so should it include explicit vacuum as well as autovac? Any opinion about where in the code base it properly belongs (which obviously depends on whether it should cover manual vacuum as well)? And does the string need to distinguish between an autovac and an autoanalyze? Cheers, Jeff autovac_set_ps_display_v1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_dump with postgis extension dumps rules separately
If I create a database and install postgis as an extension, and then run pg_dump I get this: [...] CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public; [...] CREATE RULE geometry_columns_delete AS ON DELETE TO geometry_columns DO INSTEAD NOTHING; [...] Shouldn't that CREATE RULE be implicitly part of the CREATE EXTENSION? If so, is this a pg_dump bug, PostGIS bug, or pilot error? FWIW I see CREATE OR REPLACE RULE statements in the PostGIS extension SQL script. Thanks, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, 24x7 Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump selectively ignores extension configuration tables
On 04/04/2013 01:03 PM, Vibhor Kumar wrote: I did some testing on this patch with 9.1 and 9.2 source code. Testing included following: 1. Configured PostGIS with 9.1 and 9.2 2. verified all switches of pg_dump with regression db. 3. Checked other extensions, to verify if this impacting those. Everything is working as expected and I haven't found any issue during my test with this patch. Thanks Vibhor. Any other comments or concerns before I commit this? While testing this patch, some thoughts came in my mind and thought to share on this thread. Is it possible, if we can have two switches for extension in pg_dump: 1. extension dump with user data in extension tables. 2. User data-only dump from extensions. This might be worth considering for 9.4 Thanks, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, 24x7 Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Process title for autovac
On 07/04/13 08:20, Jeff Janes wrote: I've often wanted to know what the autovacuum worker was doing. The process title seems like the best place to get this information, but the process title tells me what database it is in, but not what table it is working on. The attached patch demonstrates the concept of what I want. I put the code in table_recheck_autovac not because I think that is the best location, but just because it was the easiest point at which I knew how to get the table name easily before classTup gets destroyed. Example output: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 16392 jjanes20 0 229m 19m 6948 S 3.6 1.0 0:06.85 postgres: autovacuum worker process jjanes.public.pgbench_accounts I never reset the process title back to the initial state of just having a database name and no table. Which I can get away with temporarily because the autovac worker never dilly-dallies between tables, it either goes to the next one, or exits. A real implementation would probably want to reset it anyway, though. Is this functionality something we want? If so should it include explicit vacuum as well as autovac? Any opinion about where in the code base it properly belongs (which obviously depends on whether it should cover manual vacuum as well)? And does the string need to distinguish between an autovac and an autoanalyze? Cheers, Jeff Knowing whether it is vacuuming or analyzing seems like a nice idea +1 Cheers Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unrecognized type error (postgres 9.1.4)
On Saturday, April 06, 2013 12:18 PM Rodrigo Barboza wrote: On Sat, Apr 6, 2013 at 12:23 AM, Amit Kapila amit.kap...@huawei.com wrote: On Saturday, April 06, 2013 3:57 AM Rodrigo Barboza wrote: Hello. I created a type my_uint that is a unsigned int 32. I am trying to update data of a table that contains a column of this type. Here is what happens: postgresql= explain analyze UPDATE attribute_type_conf SET rowform = rowform +1 where rowform = 18; ERROR: unsupported type: 132852 Can you post your complete test (like your type creation and its use for table and any initial data you loaded to it)? Well, it's a lot of data. May I send it atached? If you can't make it to small reproducible test, then you can send. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Back branches vs. gcc 4.8.0
On Fri, Apr 5, 2013 at 9:45 PM, Peter Eisentraut pete...@gmx.net wrote: So I think this is not a compiler bug or an arms race. We just need to fix the code. So I'm in favor of backporting. I can certainly see this argument. I understand Tom's point about an arms race, but back-porting this doesn't feel terribly risky to me. The thing is, if the arms race is escalating faster than we're comfortable with, we can always opt opt at a later time; it's not as if back-porting this fix now commits us irrevocably. Then, too, I tend to think this is more our fault than gcc's - for a change. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unrecognized type error (postgres 9.1.4)
Ok! I will try to reproduce in a smaller scenario. On Sat, Apr 6, 2013 at 9:53 PM, Amit Kapila amit.kap...@huawei.com wrote: On Saturday, April 06, 2013 12:18 PM Rodrigo Barboza wrote: On Sat, Apr 6, 2013 at 12:23 AM, Amit Kapila amit.kap...@huawei.com wrote: On Saturday, April 06, 2013 3:57 AM Rodrigo Barboza wrote: Hello. I created a type my_uint that is a unsigned int 32. I am trying to update data of a table that contains a column of this type. Here is what happens: postgresql= explain analyze UPDATE attribute_type_conf SET rowform = rowform +1 where rowform = 18; ERROR: unsupported type: 132852 Can you post your complete test (like your type creation and its use for table and any initial data you loaded to it)? Well, it's a lot of data. May I send it atached? If you can't make it to small reproducible test, then you can send. With Regards, Amit Kapila.
Re: [HACKERS] isolation test fails on installcheck
Jaime Casanova ja...@2ndquadrant.com writes: I was running some tests, and noted $SUBJECT. It fails consistently on current HEAD (without any patch). ... Attached regressions.diff, basically the fails give an error of select failed: Interrupted system call Hm, looks to me like the select() error path at isolationtester.c:717 ought to consider EINTR as a retryable case. Curious though that we have not seen this in the buildfarm ... unless maybe this explains the failures-with-no-output that have been seen on some of the Windows critters? But you'd think we'd see the select failed: message if so. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unused code in float8_to_char , formatting.c ?
On Thu, Apr 4, 2013 at 6:47 PM, Greg Jaskiewicz gryz...@me.com wrote: Looking around the code Today, one of my helpful tools detected this dead code. As far as I can see, it is actually unused call to strlen() in formatting.c, float8_to_char(). I poked at this a little and suggest the following somewhat more extensive cleanup. It seems to me that there are a bunch of these functions where len is unconditionally initialized in NUM_TOCHAR_prepare and then used there. Similarly in NUM_TOCHAR_cleanup. And then there's a chunk of each individual function that does it a third time. Rather than use the same variable in all three places, I've moved the variable declarations to the innermost possible scope. Doing that revealed a bunch of other, similar places where we can get rid of strlen() calls. Does this version seem like a good idea? ...Robert formatting_dead_code_v2.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Process title for autovac
On Sat, Apr 6, 2013 at 4:20 PM, Jeff Janes jeff.ja...@gmail.com wrote: I've often wanted to know what the autovacuum worker was doing. The process title seems like the best place to get this information, but the process title tells me what database it is in, but not what table it is working on. The attached patch demonstrates the concept of what I want. I put the code in table_recheck_autovac not because I think that is the best location, but just because it was the easiest point at which I knew how to get the table name easily before classTup gets destroyed. Example output: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 16392 jjanes20 0 229m 19m 6948 S 3.6 1.0 0:06.85 postgres: autovacuum worker process jjanes.public.pgbench_accounts I never reset the process title back to the initial state of just having a database name and no table. Which I can get away with temporarily because the autovac worker never dilly-dallies between tables, it either goes to the next one, or exits. A real implementation would probably want to reset it anyway, though. Is this functionality something we want? If so should it include explicit vacuum as well as autovac? Any opinion about where in the code base it properly belongs (which obviously depends on whether it should cover manual vacuum as well)? And does the string need to distinguish between an autovac and an autoanalyze? I'm not sure whether it's a good idea to do this for manual vacuum (the answer may depend on what the code ends up looking like), but it seems good to do it at least for autovac. I don't think it's absolutely necessary to distinguish between autovac and autoanalyze, but I think it would be nice. Generally, +1 for doing something along these lines. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] isolation test fails on installcheck
On Sat, Apr 6, 2013 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Curious though that we have not seen this in the buildfarm ... anyway, your commit fix the problem. thanks -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] isolation test fails on installcheck
Jaime Casanova ja...@2ndquadrant.com writes: On Sat, Apr 6, 2013 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Curious though that we have not seen this in the buildfarm ... anyway, your commit fix the problem. thanks Thanks for confirming. What platform are you testing on, anyway? I'm still wondering why you saw it when the buildfarm did not. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] isolation test fails on installcheck
On Sat, Apr 6, 2013 at 11:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jaime Casanova ja...@2ndquadrant.com writes: On Sat, Apr 6, 2013 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Curious though that we have not seen this in the buildfarm ... anyway, your commit fix the problem. thanks Thanks for confirming. What platform are you testing on, anyway? I'm still wondering why you saw it when the buildfarm did not. Debian 7 (64 bits) Kernel: 3.2.41-2 Processor: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz gcc 4.7.2 don't know what else you could need, please let me know if you want any other info -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] isolation test fails on installcheck
On Sun, Apr 7, 2013 at 12:54 AM, Jaime Casanova ja...@2ndquadrant.com wrote: On Sat, Apr 6, 2013 at 11:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jaime Casanova ja...@2ndquadrant.com writes: On Sat, Apr 6, 2013 at 9:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Curious though that we have not seen this in the buildfarm ... anyway, your commit fix the problem. thanks Thanks for confirming. What platform are you testing on, anyway? I'm still wondering why you saw it when the buildfarm did not. Debian 7 (64 bits) Kernel: 3.2.41-2 Processor: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz gcc 4.7.2 don't know what else you could need, please let me know if you want any other info argh! sorry, i forgot that the tests were run in a test machine so the real information is: Debian 6 Kernel: 2.6.32-5-amd64 Processor: AMD Turion(tm) 64 X2 TL-60 gcc 4.4.5 -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
