Re: [HACKERS] POSIX shared memory redux
A.M. age...@themactionfaction.com writes: On Apr 11, 2011, at 7:13 PM, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: I mean I'm not convinced that fcntl() locking will be as reliable. I'm not either. Particularly not on NFS. Is there an example of a recent system where fcntl is broken (ignoring NFS)? Well, the fundamental point is that ignoring NFS is not the real world. We can't tell people not to put data directories on NFS, and even if we did tell them not to, they'd still do it. And NFS locking is not trustworthy, because the remote lock daemon can crash and restart (forgetting everything it ever knew) while your own machine and the postmaster remain blissfully awake. None of this is to say that an fcntl lock might not be a useful addition to what we do already. It is to say that fcntl can't just replace what we do already, because there are real-world failure cases that the current solution handles and fcntl alone wouldn't. 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] Postgre inner work question
On Tuesday 12 April 2011 01.02:35 Lucas Cotta wrote: Does postgre execute the queries following a execution plan tree, where the leafs are table scans, and the nodes are joins? yes, see the EXPLAIN SQL command (EXPLAIN SELECT * FROM ), it will shwo this tree. http://www.postgresql.org/docs/9.0/static/sql-explain.html cheers -- vbi -- The woman you buy -- and she is the least expensive -- takes a great deal of money. The woman who gives herself takes all your time. -- Balzac signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] Windows build issues
On Tue, Apr 12, 2011 at 22:36, Brar Piening b...@gmx.de wrote: On Tue, 12 Apr 2011 08:51:57 -0400, Andrew Dunstan and...@dunslane.net wrote: that's in the SDK? If not, I still think that should be our primary option - I certainly don't see how it's obsolete. (and you can, afaics, still get the platform sdk with the correct version of the compiler (non-vs2010), but I haven't tested it) Or did I miss something in this thread? Have we shown for sure that you can't build it with the compiler I haven't actually tried using the SDK alone. I'll try testing that on a cloud appliance when I get a chance, as I'm out of Windows boxes I can reasonable perturb. I do know you *need* the SDK for 64 bit builds with VSE 2008, as it doesn't include a 64 bit compiler. I've just built current git HEAD on a clean Windows XP virtual machine with only Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP 1 (the latest pre VS 2010 SDK) on it. It builds without problems (a few warnings) and passes vcregress check. VS or VS EXPRESS is probably not needed to build Postgres with any recent Windows SDK that includes compilers (= 6.0). So per your experience, all we really need to do is to define what the *max* level of the Windows SDK we can use is, to make sure people don't get the VS2010 compiler instead? (And adding the note that VS2010 isn't supported with or without the platform sdk) This Wikipedia article might shed some more light on the MS SDK chaos: http://en.wikipedia.org/wiki/Microsoft_Windows_SDK Yeah, unfortunately it doesn't list which version of the compilers are included... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Itanium HP-UX build failure, register stack
The code we added recently to the stack-depth check to also check the register stack on ia64 doesn't compile on HP-UX B.11.31, using the HP aCC compiler: cc -Ae +O2 -g -I../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o postgres.o postgres.c postgres.c, line 3002: warning #2837-D: omission of explicit type is nonstandard (int assumed) static __inline__ char * ^ postgres.c, line 3002: error #2065: expected a ; static __inline__ char * ^ I committed a fix for that using the HP-UX specific _Asm_mov_from_ar macro, similar to how we use _Asm_xchg for TAS(). With this, 8.4 compiles on HP-UX again, yeaee! 9.0 still has this issue: http://archives.postgresql.org/pgsql-hackers/2010-11/msg01971.php. I'll take a look at that.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] Itanium HP-UX build failure, register stack
On 04/13/2011 05:12 AM, Heikki Linnakangas wrote: The code we added recently to the stack-depth check to also check the register stack on ia64 doesn't compile on HP-UX B.11.31, using the HP aCC compiler: cc -Ae +O2 -g -I../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o postgres.o postgres.c postgres.c, line 3002: warning #2837-D: omission of explicit type is nonstandard (int assumed) static __inline__ char * ^ postgres.c, line 3002: error #2065: expected a ; static __inline__ char * ^ I committed a fix for that using the HP-UX specific _Asm_mov_from_ar macro, similar to how we use _Asm_xchg for TAS(). With this, 8.4 compiles on HP-UX again, yeaee! 9.0 still has this issue: http://archives.postgresql.org/pgsql-hackers/2010-11/msg01971.php. I'll take a look at that.. I wish we could get some buildfarm coverage for HPUX. I've whined about this in the past, but nobody's ever made an offer to provide suitable platform(s) that I know of. cheers andrew -- 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] Itanium HP-UX build failure, register stack
On 13.04.2011 14:22, Andrew Dunstan wrote: I wish we could get some buildfarm coverage for HPUX. I've whined about this in the past, but nobody's ever made an offer to provide suitable platform(s) that I know of. I only have temporary access to this HPUX box, but I'm trying to arrange that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] POSIX shared memory redux
On Apr 13, 2011, at 2:06 AM, Tom Lane wrote: A.M. age...@themactionfaction.com writes: On Apr 11, 2011, at 7:13 PM, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: I mean I'm not convinced that fcntl() locking will be as reliable. I'm not either. Particularly not on NFS. Is there an example of a recent system where fcntl is broken (ignoring NFS)? Well, the fundamental point is that ignoring NFS is not the real world. We can't tell people not to put data directories on NFS, and even if we did tell them not to, they'd still do it. And NFS locking is not trustworthy, because the remote lock daemon can crash and restart (forgetting everything it ever knew) while your own machine and the postmaster remain blissfully awake. None of this is to say that an fcntl lock might not be a useful addition to what we do already. It is to say that fcntl can't just replace what we do already, because there are real-world failure cases that the current solution handles and fcntl alone wouldn't. The goal of this patch is to eliminate SysV shared memory, not to implement NFS-capable locking which, as you point out, is virtually impossible. As far as I can tell, in the worst case, my patch does not change how postgresql handles the NFS case. SysV shared memory won't work across NFS, so that interlock won't catch, so postgresql is left with looking at a lock file with PID of process on another machine, so that won't catch either. This patch does not alter the lock file semantics, but merely augments the file with file locking. At least with this patch, there is a chance the lock might work across NFS. In the best case, it can allow for shared-storage postgresql failover, which is a new feature. Furthermore, there is an improvement in shared memory handling in that it is unlinked immediately after creation, so only the postmaster and its children have access to it (through file descriptor inheritance). This means shared memory cannot be stomped on by any other process. Considering that possibly working NFS locking is a side-effect of this patch and not its goal and, in the worst possible scenario, it doesn't change current behavior, I don't see how this can be a ding against this patch. Cheers, M -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Fix for pg_upgrade
The attached patches fixes a pg_upgrade crash in 9.0 caused by a new cluster database that doesn't exist in the old cluster; instead throw an error. This was reported to me by EnterpriseDB testing staff. This bug does not exist in git head. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/contrib/pg_upgrade/relfilenode.c b/contrib/pg_upgrade/relfilenode.c new file mode 100644 index b20ca20..fc36968 *** a/contrib/pg_upgrade/relfilenode.c --- b/contrib/pg_upgrade/relfilenode.c *** transfer_all_new_dbs(migratorContext *ct *** 46,51 --- 46,55 int n_maps; pageCnvCtx *pageConverter = NULL; + if (!old_db) + pg_log(ctx, PG_FATAL, + the new cluster database %s was not found in the old cluster\n, new_db-db_name); + n_maps = 0; mappings = gen_db_file_maps(ctx, old_db, new_db, n_maps, old_pgdata, new_pgdata); -- 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_regress multibyte - encoding?
pg_regress supports a --multibyte option, which can also be invoked using the MULTIBYTE make variable when you run make check. I think this is fairly unknown, but we are now documenting it as part of how to run the collation regression tests. I think it would also be useful in the PL/Python regression tests for some of the unicode test variants. So before this spreads too widely, should we rename it to --encoding and ENCODING to be consistent with the naming everywhere else? Does anyone use the old interface? Do we need to keep it? -- 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] [PATCH] Fix that NOSUPERUSER implies REPLICATION unless specified contrarily
On Tue, Apr 12, 2011 at 4:14 PM, Andres Freund and...@anarazel.de wrote: Also add some regression tests for that behaviour. Found after seing a report about it in IRC by Daniel Grace. This patch didn't apply cleanly for me, but I committed the basic fix. -- 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
[HACKERS] GEQO-induced crash with provably dummy relations
An off-list discussion with Leo Carson of SDSC led to the following test case, which reproducibly crashes 8.4: -- do this in the regression database, or use some other base table create or replace view vv as select a.unique1, b.unique2, c.tenthous, 'label'::text as lab from tenk1 a left join tenk1 b on a.unique1 = b.unique2 left join tenk1 c on a.unique1 = c.tenthous; explain select * from vv where lab = 'fool'; set geqo_threshold = 2; explain select * from vv where lab = 'fool'; The reason is that joinrels.c determines that the topmost outer join must yield an empty result (because the constant-false condition resulting from lab = 'fool' is attached to that join) and it then decides that the join's RHS doesn't need to be evaluated either. So it applies mark_dummy_rel() to that base rel. In a GEQO environment that leads to dangling pointers, because the dummy path added to the base rel gets recycled at the end of geqo_eval(), but the base RelOptInfo is still alive and will be examined again later. 9.0 and HEAD don't crash on this particular test case, but they're still putting short-lived path pointers into longer-lived data structures, so I'm convinced that they need the fix too. This is not that hard to fix, but it reminds me that GEQO is just really hard to test decently. It doesn't help that the standard regression tests fail to exercise it at all. (You can try running the regression tests with geqo_threshold=2, but you'll get some possibly-platform-dependent failures due to row ordering differences from different plans getting chosen. This makes it hard to mechanize testing.) I wonder if anyone's got any good ideas about that? 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] pg_regress multibyte - encoding?
Peter Eisentraut pete...@gmx.net writes: pg_regress supports a --multibyte option, which can also be invoked using the MULTIBYTE make variable when you run make check. I think this is fairly unknown, but we are now documenting it as part of how to run the collation regression tests. I think it would also be useful in the PL/Python regression tests for some of the unicode test variants. So before this spreads too widely, should we rename it to --encoding and ENCODING to be consistent with the naming everywhere else? +1 Does anyone use the old interface? Do we need to keep it? As long as this is only in HEAD and not back-patched, I don't see a need for that. 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] Windows build issues
On Wed, 13 Apr 2011 10:45:25 +0200, Magnus Hagander mag...@hagander.net wrote: So per your experience, all we really need to do is to define what the *max* level of the Windows SDK we can use is, to make sure people don't get the VS2010 compiler instead? (And adding the note that VS2010 isn't supported with or without the platform sdk) Yes, v6.0-v7.0 will work, v7.0a(=VS 2010) and v7.1 will not work. Yeah, unfortunately it doesn't list which version of the compilers are included... Actually the VS 2010 compilers (and those of the associated Windows SDK's) work fine for building postgres. They produce quite a few additional warnings that I already mentioned (http://archives.postgresql.org/pgsql-hackers/2011-01/msg00118.php) but the product seems to work fine. The problem with VS 2010 (and the associated Windows SDK's) is the fact that MS dropped VCBuild.exe and now uses MSBuild.exe to build Visual C++ Projects so the generated build files don't work any longer. (see http://msdn.microsoft.com/en-us/library/bb531344.aspx) For the records (CSV): Version,Windows SDK Version Number,Build Number,Release Date,Building PostgreSQL Windows Vista Update .NET 3.0 SDK,v6.0,6.1.6000.16384.10,2007-03-22,will work (tested*) Included in Visual Studio 2008,v6.0a,??,2007-11-19,will work (untested) Windows Server 2008 .NET 3.5 SDK,v6.1,6.0.6001.18000.367,2008-02-05,will work (untested) Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP 1,v7.0,6.1.7600.16385,2009-07-24,will work (tested*) Included in Visual Studio 2010,v7.0a,6.1.7600.16385,2010-04-12,will not work yet (tested**) Microsoft Windows SDK for Windows 7 and .NET Framework 4,v7.1,7.1.7600.0.30514,2010-05-21,will not work yet (tested**) * builds and passes vcregress check with current git HEAD ** fails while trying to detect vcbuild version Regards, Brar -- 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] POSIX shared memory redux
On Wed, Apr 13, 2011 at 7:20 AM, A.M. age...@themactionfaction.com wrote: The goal of this patch is to eliminate SysV shared memory, not to implement NFS-capable locking which, as you point out, is virtually impossible. As far as I can tell, in the worst case, my patch does not change how postgresql handles the NFS case. SysV shared memory won't work across NFS, so that interlock won't catch, so postgresql is left with looking at a lock file with PID of process on another machine, so that won't catch either. This patch does not alter the lock file semantics, but merely augments the file with file locking. At least with this patch, there is a chance the lock might work across NFS. In the best case, it can allow for shared-storage postgresql failover, which is a new feature. Furthermore, there is an improvement in shared memory handling in that it is unlinked immediately after creation, so only the postmaster and its children have access to it (through file descriptor inheritance). This means shared memory cannot be stomped on by any other process. Considering that possibly working NFS locking is a side-effect of this patch and not its goal and, in the worst possible scenario, it doesn't change current behavior, I don't see how this can be a ding against this patch. I don't see why we need to get rid of SysV shared memory; needing less of it seems just as good. In answer to your off-list question, one of the principle ways I've seen fcntl() locking fall over and die is when someone removes the lock file. You might think that this could be avoided by picking something important like pg_control as the log file, but it turns out that doesn't really work: http://0pointer.de/blog/projects/locking.html Tom's point is valid too. Many storage appliances present themselves as an NFS server, so it's very plausible for the data directory to be on an NFS server, and there's no guarantee that flock() won't be broken there. If our current interlock were known to be unreliable also maybe we wouldn't care very much, but AFAICT it's been extremely robust. -- 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] POSIX shared memory redux
Robert Haas robertmh...@gmail.com writes: In answer to your off-list question, one of the principle ways I've seen fcntl() locking fall over and die is when someone removes the lock file. You might think that this could be avoided by picking something important like pg_control as the log file, but it turns out that doesn't really work: http://0pointer.de/blog/projects/locking.html Hm, I wasn't aware of the fact that you lose an fcntl() lock if you close a *different* file descriptor for the same file. My goodness, that's horrid :-(. It basically means that any third-party code running in a backend could accidentally defeat the locking, and most of the time you'd never even know it had happened ... as opposed to what would happen if you detached from shmem for instance. You could run with such code for years, and probably never know why sometimes the interlock failed to work when you needed it to. 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] POSIX shared memory redux
On Apr 13, 2011, at 8:36 PM, Robert Haas wrote: I don't see why we need to get rid of SysV shared memory; needing less of it seems just as good. 1. As long one keeps SysV shared memory around, the postgresql project has to maintain the annoying platform-specific document on how to configure the poorly named kernel parameters. If the SysV region is very small, that means I can run more postgresql instances within the same kernel limits, but one can still hit the limits. My patch allows the postgresql project to delete that page and the hassles with it. 2. My patch proves that SysV is wholly unnecessary. Are you attached to it? (Pun intended.) In answer to your off-list question, one of the principle ways I've seen fcntl() locking fall over and die is when someone removes the lock file. You might think that this could be avoided by picking something important like pg_control as the log file, but it turns out that doesn't really work: http://0pointer.de/blog/projects/locking.html Tom's point is valid too. Many storage appliances present themselves as an NFS server, so it's very plausible for the data directory to be on an NFS server, and there's no guarantee that flock() won't be broken there. If our current interlock were known to be unreliable also maybe we wouldn't care very much, but AFAICT it's been extremely robust. Both you and Tom have somehow assumed that the patch alters current postgresql behavior. In fact, the opposite is true. I haven't changed any of the existing behavior. The robust behavior remains. I merely added fcntl interlocking on top of the lock file to replace the SysV shmem check. If someone deletes the postgresql lock file over NFS, the data directory is equally screwed, but with my patch there is chance that two machines sharing a properly-configured NFS mount can properly interlock- postgresql cannot offer that today, so this is a feature upgrade with no loss. The worst case scenario is today's behavior. My original goal remains to implement POSIX shared memory, but Tom Lane was right to point out that the current interlocking check relies on SysV, so, even though the startup locking is really orthogonal to shared memory, I implemented what could be considered a separate patch for that and rolled it into one. I would encourage you to take a look at the patch. Cheers, M -- 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] BUG #5856: pg_attribute.attinhcount is not correct.
On Sun, Apr 10, 2011 at 5:23 AM, Noah Misch n...@leadboat.com wrote: On Sun, Apr 10, 2011 at 07:35:53AM -0400, Robert Haas wrote: On Sun, Apr 10, 2011 at 6:36 AM, Noah Misch n...@leadboat.com wrote: 3. Make AlterTableCreateToastTable acquire only ShareUpdateExclusiveLock and remove the pass-usage heuristic from ATRewriteCatalogs. For this to be valid, toast_insert_or_update() must behave reasonably in the face of a relation concurrently acquiring a TOAST table. Since it takes reltoastrelid from the relcache, toast_insert_or_update() will not act on the change in the middle of a single call. Even if it did, I don't see any risks. I'd lean toward #3 if someone else is also confident in its correctness. Otherwise, #1 seems like the way to go. Preferences? Other ideas? I haven't scrutinized the code but I would prefer #3 if it's viable without too much of a code footprint. It's certainly compact; patch attached. Thanks. Committed. It occurred to me to worry that it would be quite unsafe if a TOAST table got *removed* while holding less than AccessExclusiveLock, but it appears we're safe enough from that; I believe it can only happen on a table rewrite, and there's not much chance of that ever requiring a lesser lock strength. -- 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] POSIX shared memory redux
On Wed, Apr 13, 2011 at 6:11 PM, A.M. age...@themactionfaction.com wrote: I don't see why we need to get rid of SysV shared memory; needing less of it seems just as good. 1. As long one keeps SysV shared memory around, the postgresql project has to maintain the annoying platform-specific document on how to configure the poorly named kernel parameters. If the SysV region is very small, that means I can run more postgresql instances within the same kernel limits, but one can still hit the limits. My patch allows the postgresql project to delete that page and the hassles with it. 2. My patch proves that SysV is wholly unnecessary. Are you attached to it? (Pun intended.) With all due respect, I think this is an unproductive conversation. Your patch proves that SysV is wholly unnecessary only if we also agree that fcntl() locking is just as reliable as the nattch interlock, and Tom and I are trying to explain why we don't believe that's the case. Saying that we're just wrong without responding to our points substantively doesn't move the conversation forward. In case it's not clear, here again is what we're concerned about: A System V shm *cannot* be removed until nobody is attached to it. A lock file can be removed, or the lock can be accidentally released by the apparently innocuous operation of closing a file descriptor. Both you and Tom have somehow assumed that the patch alters current postgresql behavior. In fact, the opposite is true. I haven't changed any of the existing behavior. The robust behavior remains. I merely added fcntl interlocking on top of the lock file to replace the SysV shmem check. This seems contradictory. If you replaced the SysV shmem check, then it's not there, which means you altered the behavior. -- 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] Prefered Types
On Mon, Apr 11, 2011 at 1:39 PM, Зотов Роман zo...@oe-it.ru wrote: 11.04.2011 5:19, Robert Haas пишет: You only sent this to me, I think; I assume you meant to copy the list. ...Robert On Mar 16, 2011, at 12:46 AM, Zotovzo...@oe-it.ru wrote: I send full patch, prev patch could be not so full, because i didn`t knew how does it build. (too many generated files) now i think it work. now it doesn`t change defaults and not change syntax to use prefered. I just change it by update pg_type ... this feature can be modified now. And i saw two new ways to select functions 1. If function only, one we can choose it without current hard way 2. If we can`t choose function we can think, what more likely that function, what have first match operand Thank you, if you get this patch (with some changes) into your product. You should probably add this patch here: https://commitfest.postgresql.org/action/commitfest_view/open -- 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] Typed table DDL loose ends
On Sat, Apr 9, 2011 at 6:57 PM, Noah Misch n...@leadboat.com wrote: While looking at the typed table/pg_upgrade problem, I ran into a few smaller problems in the area. I'm not envisioning a need for much code shift to fix them, but there are a few points of policy. * Table row types used in typed tables vs. ALTER TABLE As previously noted: CREATE TABLE t (); CREATE TABLE is_a OF t; ALTER TABLE t ADD c int; \d is_a -- No columns At first I thought we should just forbid the use of table row types in CREATE TABLE OF. However, we've been quite systematic about not distinguishing between table row types and CREATE TYPE AS types; I've only found a distinction in ALTER TABLE/ALTER TYPE, where we direct you to the other command. It would be nice to preserve this heritage. That doesn't look particularly difficult; it may actually yield a net code reduction. I guess my gut feeling is that it would make more sense to forbid it outright for 9.1, and we can look at relaxing that restriction later if we're so inclined. Much as with the problem Tom fixed in commit eb51af71f241e8cb199790dee9ad246bb36b3287, I'm concerned that there may be other cases that we're not thinking of right now, and while we could find them all and fix them, the amount of functionality gained is fairly marginal, and I don't really want to hold up the release while we bug-swat. -- 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] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE
On Fri, Apr 8, 2011 at 5:12 PM, Noah Misch n...@leadboat.com wrote: Implemented as attached. The first patch just adds the ALTER TABLE subcommands to attach and detach a table from a composite type. A few open questions concerning typed tables will probably yield minor changes to these subcommands. I implemented them to be agnostic toward the outcome of those decisions. I suppose one issue is whether anyone would care to bikeshed on the proposed syntax. Any takers? I think you only need an AccessShareLock on InheritsRelationId, since you are only selecting from it. If we adopt the elsewhere-proposed approach of forbidding the use of rowtypes to create typed tables, the circularity-checking logic here can become simpler. I think it's not actually water-tight right now: rhaas=# create table a (x int); CREATE TABLE rhaas=# create table b of a; CREATE TABLE rhaas=# create table c () inherits (b); CREATE TABLE rhaas=# create table d of c; CREATE TABLE rhaas=# alter table a of d; ALTER TABLE pg_dump is not happy with this situation. -- 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] POSIX shared memory redux
A.M. age...@themactionfaction.com writes: 1. As long one keeps SysV shared memory around, the postgresql project has to maintain the annoying platform-specific document on how to configure the poorly named kernel parameters. No, if it's just a small area, I don't see that that's an issue. You're going to max out on other things (like I/O bandwidth) long before you run into the limit on how many postmasters you can have from this. The reason that those parameters are problematic now is that people tend to want *large* shmem segments and the typical defaults aren't friendly to that. 2. My patch proves that SysV is wholly unnecessary. Are you attached to it? (Pun intended.) You were losing this argument already, but ad hominem attacks are pretty much guaranteed to get people to tune you out. There are real, substantive, unfixable reasons to not trust fcntl locking completely. I would encourage you to take a look at the patch. Just to be perfectly clear: I have not read your patch, and am not likely to before the next commitfest starts, because I have approximately forty times too many things to do already. I'm just going off your own abbreviated description of the patch. But from what I know about fcntl locking, it's not a sufficient substitute for the SysV shmem interlock, because it has failure modes that the SysV interlock doesn't, and those failure modes occur in real-world cases. Yeah, it'd be nice to also be able to lock against other postmasters on other NFS clients, but we hardly ever hear of somebody getting burnt by the lack of that (and fcntl wouldn't be a bulletproof defense anyway). On the other hand, accidentally trying to start a duplicate postmaster on the same machine is an everyday occurrence. 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] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE
Robert Haas robertmh...@gmail.com writes: If we adopt the elsewhere-proposed approach of forbidding the use of rowtypes to create typed tables, the circularity-checking logic here can become simpler. I think it's not actually water-tight right now: rhaas=# create table a (x int); CREATE TABLE rhaas=# create table b of a; CREATE TABLE rhaas=# create table c () inherits (b); CREATE TABLE rhaas=# create table d of c; CREATE TABLE rhaas=# alter table a of d; ALTER TABLE alter table a of d? What the heck does that mean, and why would it be a good idea? 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] Itanium HP-UX build failure, register stack
I wish we could get some buildfarm coverage for HPUX. I've whined about this in the past, but nobody's ever made an offer to provide suitable platform(s) that I know of. cheers I've got two HP-UX 11 boxes, PA-RISC and IA64. From uname: HP-UX B.11.23 U 9000/785 HP-UX B.11.23 U ia64 They are build farm boxes (which already build postgres) so my guess is they wouldn't require much fiddling. I don't time to help with this, but am more than willing to give you all the access you need to get it going. I also have HP-UX 10.20 on a PA-RISC for the courageous. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
