Re: [BUGS] Minor inheritance/check bug: Inconsistent behavior
From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Tuesday, August 28, 2012 2:04 AM Robert Haas writes: >> Maybe, but in that case shouldn't referencing a system column chuck an error? > Yeah, possibly. I think none of them are populated with anything useful > during INSERT checks (though OID might be an exception?). Less sure > about the state during UPDATE checks, though. AFAICT during Update also, it doesn't contain useful. The only chance it would have contain something useful is when it goes for EvalPlanQual and then again comes to check for constraints. However these attributes get filled in heap_update much later. So now should the fix be that it returns an error for system column reference except for OID case? With Regards, Amit Kapila. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [PATCH] Prevent hanging on unreachable hosts on startup
On Mon, Aug 27, 2012 at 09:34:48PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Tom, can you comment on this patch because you commented on the previous > > version? Thanks. > > Doesn't that provoke a pile of compiler warnings about local variables > potentially being altered during longjmp? It sure looks pretty unsafe > from here. It also fails to print any error message if a connection > attempt is canceled. > > A bigger-picture question is just how safe it is to longjmp out of libpq > partway through a connection attempt. At the very least, that's likely > to leak an open socket and some memory. Maybe that doesn't matter too > much for psql, but I'm not convinced. It seems fairly likely that > internal state for libc (malloc), openssl, etc, could be left in a > corrupt state if the interrupt happens at just the wrong time. (This > didn't matter so much for the original proposal, where we'd just have > been exiting psql anyway on failure. But if it's in \c then we want > psql to still be operational after a failure.) > > We could perhaps dodge the longjmp safety question by using a > PQconnectStartParams/PQconnectPoll loop. I'm not sure that provides > 100% the same functionality --- in particular, I think it wouldn't allow > interrupting out of a DNS name resolution delay. But it'd be less > likely to result in strange crashes. > > regards, tom lane The latest on this patch can be found here: http://archives.postgresql.org/message-id/500151c4.5010...@enterprisedb.com -Ryan Kelly -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6489: Alter table with composite type/table
On Mon, Aug 27, 2012 at 9:40 PM, Bruce Momjian wrote: > On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote: >> On 13.3.2012. 20:49, Merlin Moncure wrote: >> > I personally think it's an oversight. This was just discussed a >> > couple of days ago here: >> > http://postgresql.1045698.n5.nabble.com/Altering-a-table-with-a-rowtype-column-td5544844.html >> > >> > The server is blocking the alter-not-null-with-default because it's >> > assuming that the default should be applied to dependent (foreign) >> > tables implementing the type as a field. I think this assumption is >> > totally bogus because composite types defaults get applied to the >> > type, not to member fields and therefore a default has no meaning in >> > that context. I think the TODO should read to relax the check >> > essentially. >> > >> > merlin >> > >> >> I agree. >> TODO: alter table-type columns according to attribute type rules. >> Enforce only TYPE features and ignore TABLE features when altering composite >> table-types. >> >> While I'm making up TODO's, my favorite one: support recursive types. > > Should we add this TODO? I am confused by the text above though. I think so, but you should read the referenced thread for some background -- especially Tom's comments. What's missing is a consensus on how defaults and tables-as-rowtypes interact; and before working on a TODO that should be established. merlin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6489: Alter table with composite type/table
Bruce Momjian writes: > On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote: >> On 13.3.2012. 20:49, Merlin Moncure wrote: >>> I personally think it's an oversight. This was just discussed a >>> couple of days ago here: >>> http://postgresql.1045698.n5.nabble.com/Altering-a-table-with-a-rowtype-column-td5544844.html >> TODO: alter table-type columns according to attribute type rules. >> Enforce only TYPE features and ignore TABLE features when altering composite >> table-types. > Should we add this TODO? I am confused by the text above though. I think this is making an assumption that we have consensus on what are "type" properties and what are only "table" properties; that is, is it a feature or a bug that column defaults don't work for instances of composite types? The ALTER code is rejecting the case on the assumption that we think this is a bug that should get fixed eventually. I'd only want to relax the check if we have consensus that that will never happen. The thread linked to via nabble above covers a lot of the background and issues here. It didn't seem to me that there was clear consensus. In any case, if we do do this, ISTM the TODO is much less about removing one test in ALTER TABLE and much more about documenting the chosen behavior. I think the reason you're confused by the proposed TODO wording is exactly that it uses the phrases "TYPE features" and "TABLE features" as if those concepts were defined or documented anywhere. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] BUG #6572: The example of SPI_execute is bogus
On Sun, Apr 15, 2012 at 12:29:39PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada wrote: > >> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane wrote: > >>> Given the lack of complaints since 9.0, maybe we should not fix this > >>> but just redefine the new behavior as being correct? But it seems > >>> mighty inconsistent that the tuple limit would apply if you have > >>> RETURNING but not when you don't. In any case, the ramifications > >>> are wider than one example in the SPI docs. > > >> To be honest, I was surprised when I found tcount parameter is said to > >> be applied to even INSERT. I believe people think that parameter is > >> to limit memory consumption when returning tuples thus it'd be applied > >> for only SELECT or DML with RETURNING. So I'm +1 for non-fix but > >> redefine the behavior. Who wants to limit the number of rows > >> processed inside the backend, from SPI? > > > Yeah. > > Okay, apparently nobody cares about RETURNING behaving differently from > non-RETURNING, so the consensus is to redefine the current behavior as > correct. That means what we need is to go through the docs and see what > places need to be updated (and, I guess, back-patch the changes to 9.0). > I will get to this if nobody else does, but not right away. Would someone make the doc change outlined above? Thanks. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6489: Alter table with composite type/table
here's my sense from what I've done in this area so far. On Tue, Aug 28, 2012 at 9:54 AM, Tom Lane wrote: > Bruce Momjian writes: > > On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote: > >> On 13.3.2012. 20:49, Merlin Moncure wrote: > >>> I personally think it's an oversight. This was just discussed a > >>> couple of days ago here: > >>> > http://postgresql.1045698.n5.nabble.com/Altering-a-table-with-a-rowtype-column-td5544844.html > > >> TODO: alter table-type columns according to attribute type rules. > >> Enforce only TYPE features and ignore TABLE features when altering > composite table-types. > > > Should we add this TODO? I am confused by the text above though. > > I think this is making an assumption that we have consensus on what > are "type" properties and what are only "table" properties; that is, > is it a feature or a bug that column defaults don't work for instances > of composite types? > I think right now the fact is that multiple inheritance is usually a cleaner way to incorporate multiple table types in a single table. There are some giant gotchas here of course, but nothing like the area of using composite types in columns. This is an area where we may do well to work towards consensus. Right now tables and composite types work almost the same but there are so many odd cases where they don't that it is somewhat disorienting. > > The ALTER code is rejecting the case on the assumption that we think > this is a bug that should get fixed eventually. I'd only want to relax > the check if we have consensus that that will never happen. > But at the same time, you can create the table with a not null constraint and then insert nulls, so I am not sure what the difference is. Again this is a case where different assumptions are followed partway through and consequently you run into very unexpected sharp corners. > > The thread linked to via nabble above covers a lot of the background and > issues here. It didn't seem to me that there was clear consensus. > I have some blog posts written (to be published next week) on the sharp corners of these sorts of things and how to avoid them. My overall recommendation actually is to use table inheritance as an alternative if you can (prefixing column names to avoid collisions) but reserve these mostly for views. Maybe it would be a good idea to re-hash this on -general at that point. > > In any case, if we do do this, ISTM the TODO is much less about removing > one test in ALTER TABLE and much more about documenting the chosen > behavior. I think the reason you're confused by the proposed TODO > wording is exactly that it uses the phrases "TYPE features" and "TABLE > features" as if those concepts were defined or documented anywhere. > To be honest, having worked with these a bit, I think we need to choose the behavior before we can document or even implement it. Best Wishes, Chris Travers
