Re: [HACKERS] [PATCH] Regression tests in windows ignore white space
On Mon, Dec 30, 2013 at 6:02 PM, Amit Kapila wrote: > On Sun, Dec 29, 2013 at 2:06 AM, David Rowley > wrote: > > On Sun, Dec 29, 2013 at 2:29 AM, Amit Kapila > > wrote: > >> > >> When I tried with your patch on windows, it results into following: > >> > >> == running regression test queries== > >> test tablespace ... diff: unrecognized option > >> `--strip-trailing-cr > >> ' > >> Which version of diff you are using? > >> > >> Version of diff on my m/c is: > >> diff - GNU diffutils version 2.7 > >> > > > > I had a bit of a look around on the git repository for diffutils and I've > > found at least part of the commit which introduced --strip-trailing-cr > > > > > http://git.savannah.gnu.org/cgit/diffutils.git/commit/?id=eefb9adae1642dcb0e2ac523c79998f466e94e77 > > > > Although here I can only see that they've added the command line args and > > not the actual code which implements stripping the carriage returns. > Going > > by that it seems that was added back in 2001, but the version you're > using > > is a bit older than than, it seems 2.7 is 19 years old! > > For Windows build, I am using whatever latest Git provides rather than > downloading > individual components which might not be good, but I find it > convenient. The latest > Git (1.8.4) download on windows still provides 2.7, which is the > reason I am on older > version. However I agree that it is better to use latest version. > It looks like the diff version I'm using is from msys and msys is what is in my search path rather than the git\bin path. To be honest I didn't realise that git for windows came with bison and flex, (at least I see bison.exe and flex.exe in the git\bin path.. I don't remember me putting them there) I don't seem to even have git\bin in my %path% environment variable at all, so all those tools are being picked up from the msys path. I'd need to remind myself about the msys install process, but since we're already saying in the docs that msys should be installed, then would the fix for this not just be as simple as my patch plus a note in the docs to say to ensure msys\bin occurs before git\bin in the %path% environment var, minimum supported diff version is 2.8. Did you install msys? if so does it have a later version of diff? Regards David Rowley > > > http://git.savannah.gnu.org/cgit/diffutils.git/refs/tags > > > > I'm on 2.8.7 which is only 4 years old. > > > > I know we don't normally go with bleeding edge, but I wondering if we > could > > make the minimum supported diff version at least 2.8 (at least for > windows) > > which was released in 2002. > > I have checked that for some of the other components like bison, flex, > ActiveState TCL we specify minimum version required, but not for diff. > http://www.postgresql.org/docs/devel/static/install-windows-full.html > > +1, for minimum diff version as 2.8. > > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com >
Re: [HACKERS] [PATCH] Regression tests in windows ignore white space
On Sun, Dec 29, 2013 at 2:06 AM, David Rowley wrote: > On Sun, Dec 29, 2013 at 2:29 AM, Amit Kapila > wrote: >> >> When I tried with your patch on windows, it results into following: >> >> == running regression test queries== >> test tablespace ... diff: unrecognized option >> `--strip-trailing-cr >> ' >> Which version of diff you are using? >> >> Version of diff on my m/c is: >> diff - GNU diffutils version 2.7 >> > > I had a bit of a look around on the git repository for diffutils and I've > found at least part of the commit which introduced --strip-trailing-cr > > http://git.savannah.gnu.org/cgit/diffutils.git/commit/?id=eefb9adae1642dcb0e2ac523c79998f466e94e77 > > Although here I can only see that they've added the command line args and > not the actual code which implements stripping the carriage returns. Going > by that it seems that was added back in 2001, but the version you're using > is a bit older than than, it seems 2.7 is 19 years old! For Windows build, I am using whatever latest Git provides rather than downloading individual components which might not be good, but I find it convenient. The latest Git (1.8.4) download on windows still provides 2.7, which is the reason I am on older version. However I agree that it is better to use latest version. > http://git.savannah.gnu.org/cgit/diffutils.git/refs/tags > > I'm on 2.8.7 which is only 4 years old. > > I know we don't normally go with bleeding edge, but I wondering if we could > make the minimum supported diff version at least 2.8 (at least for windows) > which was released in 2002. I have checked that for some of the other components like bison, flex, ActiveState TCL we specify minimum version required, but not for diff. http://www.postgresql.org/docs/devel/static/install-windows-full.html +1, for minimum diff version as 2.8. With Regards, Amit Kapila. 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] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
On Sun, Dec 29, 2013 at 8:18 AM, Heikki Linnakangas wrote: >> My position is not based on a gut feeling. It is based on carefully >> considering the interactions of the constituent parts, plus the >> experience of actually building a working prototype. > > > I also carefully considered all that stuff, and reached a different > conclusion. Plus I also actually built a working prototype (for some > approximation of "working" - it's still a prototype). Well, clearly you're in agreement with me about unprincipled deadlocking. That's what I was referring to here. > Frankly I'm pissed off that you dismissed from the start the approach that > seems much better to me. I gave you a couple of pointers very early on: look > at the way we do exclusion constraints, and try to do something like promise > tuples or killing an already-inserted tuple. You dismissed that, so I had to > write that prototype myself. Sorry, but that isn't consistent with my recollection at all. The first e-mail you sent to any of the threads on this was on 2013-11-18. Your first cut at a prototype was on 2013-11-19, the very next day. If you think that I ought to have been able to know what you had in mind based on conversations at pgConf.EU, you're giving me way too much credit. The only thing vaguely along those lines that I recall you mentioning to me in Dublin was that you thought I should make this work with exclusion constraints - I was mostly explaining what I'd done, and why. I was pleased that you listened courteously, but I didn't have a clue what you had in mind, not least because to the best of my recollection you didn't say anything about killing tuples. I'm not going to swear that you didn't say something like that, since a lot of things were said in a relatively short period, but it's certainly true that I was quite curious about how you might go about incorporating exclusion constraints into this for a while before you began visibly participating on list. Now, when you actually posted the prototype, I realized that it was the same basic design that I'd cited in my very first e-mail on the IGNORE patch (the one that didn't have row locking at all) - nobody else wanted to do heap insertion first for promise tuples. I read that 2007 thread [1] a long time ago, but that recognition only came when you posted your first prototype, or perhaps shortly before when you started participating on list. I am unconvinced that making this work for exclusion constraints is compelling, except for IGNORE, which is sensible but something I would not weigh heavily at all. In any case, since your implementation currently doesn't lock more than one row per tuple proposed for insertion (even though exclusion constraints could have a huge number of rows to lock when you propose to insert a row with a range covering a decade, and many rows need to be locked, where with unique indexes you only ever lock either 0 or 1 rows per slot). I could fairly easily extend my patch to have it work for exclusion constraints with IGNORE only. You didn't try and convince me that what you have proposed is better than what I have. You immediately described your approach. You did say some things about buffer locking, but you didn't differentiate between what was essential to my design, and what was incidental, merely calling it scary (i.e. you did something similar to what you're accusing me of here - you didn't dismiss it, but you didn't address it either). If you look back at the discussion throughout late November and much of December, it is true that I am consistently critical, but that was clearly a useful exercise, because now we know there is a problem to fix. Why is your approach better? You never actually said. In short, I think that my approach may be better because it doesn't conflate row locking with value locking (therefore making it easier to reason about, maintaining modularity), and that it never bloats, and that releasing locks is clearly cheap which may matter a lot sometimes. I don't think the "intent exclusive" locking of my most recent revision is problematic for performance - as the L&Y paper says, exclusive locking leaf pages only is not that problematic. Extending that in a way that still allows reads, only for an instant isn't going to be too problematic. I'm not sure that this is essential to your design, and I'm not sure what your thoughts are on this, but Andres has defended the idea of promise tuples that lock old values indefinitely pending the outcome of another xact where we'll probably want to update, and I think this is a bad idea. Andres recently seemed less convinced of this than in the past [2], but I'd like to hear your thoughts. It's very pertinent, because I think releasing locks needs to be cheap, and rendering old promise tuples invisible is not cheap. I'm not trying to piss anyone off here - I need all the help I can get. These are important questions, and I'm not posing them to you to be contrary. > Even after that, y
[HACKERS] Re: [bug fix] multibyte messages are displayed incorrectly on the client
On Sun, Dec 22, 2013 at 07:51:55PM +0900, MauMau wrote: > From: "Noah Misch" > >Better to attack that directly. Arrange to apply any > >client_encoding named in > >the startup packet earlier, before authentication. This relates > >to the TODO > >item "Let the client indicate character encoding of database names, user > >names, and passwords". (I expect such an endeavor to be tricky.) > > Unfortunately, character set conversion is not possible until the > database session is established, since it requires system catalog > access. Please the comment in src/backend/utils/mb/mbutils.c: > > * During backend startup we can't set client encoding because we (a) > * can't look up the conversion functions, and (b) may not know the database > * encoding yet either. So SetClientEncoding() just accepts anything and > * remembers it for InitializeClientEncoding() to apply later. Yes, changing that is the tricky part. > I guess that's why Tom-san suggested the same solution as my patch > (as a compromise) in the below thread, which is also a TODO item: > > Re: encoding of PostgreSQL messages > http://www.postgresql.org/message-id/19896.1234107...@sss.pgh.pa.us That's fair for the necessarily-earliest messages, like 'invalid value for parameter "client_encoding"' and messages pertaining to the physical structure of the startup packet. The client's encoding expectation is unknowable. An error that mentions "client_encoding" will hopefully put users on the right track regardless of how we translate and encode the surrounding words. The other affected messages are quite technical, making a casual user unlikely to fix or even see them. Not so for authentication messages, so I'm wary of forcing use of ASCII that late in the handshake. Note that choosing to use ASCII need not imply wholly declining to translate. If the build uses GNU libiconv, gettext can emit ASCII approximations for translations that conform to a Latin-derived alphabet, falling back to no translation where the alphabet differs too much. pg_perm_setlocale(LC_CTYPE, "C") requests such behavior. (The inferior iconv //TRANSLIT implementation of GNU libc will convert non-ASCII characters to question marks, though.) > From: "Alvaro Herrera" > >The problem is that if there's an encoding mismatch, the message might > >be impossible to figure out. If the message is in english, at least it > >can be searched for in the web, or something -- the user might even find > >a page in which the english error string appears, with a native language > >explanation. > > I feel like this, too. Being readable in English is better than > being unrecognizable. I agree that English consistently beats mojibake. I question whether that makes up for the loss of translation when encodings do happen to match, particularly for non-technical errors like a mistyped password. The everything-UTF8 scenario appears often, perhaps explaining infrequent complaints about the status quo. If 90% of translated message users have client_encoding != server_encoding, then +1 for your patch's strategy. If the figure is only 60%, I'd vote for holding out for a more-extensive fix that allows us to encoding-convert localized authentication failure messages. -- Noah Misch 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] control to don't toast one new type
On 12/28/2013 06:28 PM, Mohsen SM wrote: > I create type based on varlena. > I want control it that don't toast. In general it's probably going to be better to just specify the storage option on a column by column basis: ALTER TABLE ... ALTER COLUMN ... SET STORAGE PLAIN; A quick look at the sources suggests that as far as Pg is concerned, if it's varlena it's potentially TOASTable. Take a look at needs_toast_table - you'l see there that for each table attribute, it treats the attribute as toastable if it's (a) not fixed length and (b) not 'p' (PLAIN) storage. So, while I'm far from an expert, my impression is that you'd need to force 'attstorage' to 'p' wherever your type appears. You do that with pg_type.typstorage . See http://www.postgresql.org/docs/9.3/static/catalog-pg-type.html, 'typstorage'. Your question's pretty unclear, so I'm not really sure you just want to prevent TOASTing, or why you want to. If this isn't really what you wanted to do, please explain the *why* behind your question. Why do you want to do this? What problem are you trying to solve? What do you think it will achieve? -- Craig Ringer 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] Custom collations, collation modifiers (eg case-insensitive)
On 12/30/2013 08:49 AM, Craig Ringer wrote: > One of the big appeals of the new COLLATE feature was, to me, the > possibility that we'd be able to support custom collations including > case-insensitive collations in future. > > It's something I'd like to tackle one day, and in the mean time want to > pop on the TODO so it's not lost and forgotten. Everyone OK with that? > > > [TODO] User-defined collations or collation modifiers/filters > > [TODO] Provide a built-in case-insensitive collation modifier, i.e. > COLLATE ... CASE INSENSITIVE, or current-collation case insensitive as > COLLATE CASE INSENSITIVE. The SQL 20xx draft I'm working from does not appear to specify subclauses to COLLATE, and vendors that use COLLATE for case insensitive comparisions appear to do so with extended collation names. So any kind of "CASE INSENSITIVE" modifier would be an extension. It has CREATE CHARACTER SET (11.41) and CREATE COLLATION (11.43). CREATE COLLATION offers control over space padding, but not case. It might be better to just offer variants of all supported collations that ignore (a) case, (b) case and accents, or (c) just accents. The only problem with that is that you can't say "give me the case insensitive variant of whatever the current locale's default collation is", you have to specify the collation. (I intensely dislike the idea of ignoring accents, but it's something some people appear to need/want, and is supported by other vendors). Anyway, I just wanted to raise this as a future TODO. Back to trying to work out issues in updatable s.b. views. -- Craig Ringer 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
[HACKERS] Custom collations, collation modifiers (eg case-insensitive)
One of the big appeals of the new COLLATE feature was, to me, the possibility that we'd be able to support custom collations including case-insensitive collations in future. It's something I'd like to tackle one day, and in the mean time want to pop on the TODO so it's not lost and forgotten. Everyone OK with that? [TODO] User-defined collations or collation modifiers/filters [TODO] Provide a built-in case-insensitive collation modifier, i.e. COLLATE ... CASE INSENSITIVE, or current-collation case insensitive as COLLATE CASE INSENSITIVE. Case insensitive collation could be implemented as a collation filter, where both inputs are transformed using the supplied function before being passed to the system collation support. The most obvious being "lower() both inputs". -- Craig Ringer 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] XML Issue with DTDs
On Dec26, 2013, at 21:30 , Florian Pflug wrote: > On Dec23, 2013, at 18:39 , Peter Eisentraut wrote: >> On 12/19/13, 6:40 PM, Florian Pflug wrote: >>> The following example fails for XMLOPTION set to DOCUMENT as well as for >>> XMLOPTION set to CONTENT. >>> >>> select xmlconcat( >>> xmlparse(document ']>'), >>> xmlparse(content '') >>> )::text::xml; >> >> The SQL standard specifies that DTDs are dropped by xmlconcat. It's >> just not implemented. > > OK, cool, I'll try to figure out how to do that with libxml Hm, I've read through the (draft) SQL/XML 2003 standard, and it seems that it mandates more processing of DTDs than we currently do. In particular, it says that attribute default values and custom entities are to be expanded by xmlparse(). Without doing that, stripping the DTD can change the meaning of an XML document, or make it not well-formed (in the case of custom entity definitions). So I think that we unless we implement that, I we have to raise an error, not silently strip the DTD. best regards, Florian Pflug -- 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 FIX] Version number expressed in octal form by mistake
Tom Lane wrote: > Kevin Grittner writes: >> Tom Lane wrote: >>> So I'm inclined to propose that we set min/max to 0 and 99 >>> here. >> >> Something like the attached back-patched to 8.4? > > Works for me. Done. Thanks for the report, Joel! -- Kevin Grittner EDB: 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] Polymorphic function calls
On Sun, Dec 29, 2013 at 8:44 AM, knizhnik wrote: > create function volume(r base_table) returns integer as $$ begin return > r.x*r.y; end; $$ language plpgsql strict stable; > create function volume(r derived_table) returns integer as $$ begin return > r.x*r.y*r.z; end; $$ language plpgsql strict stable; [...] > Execution plans of first and second queries are very similar. > The difference is that type of r_1 in first query is "base_table". > It is obvious that query should return fixed set of columns, so > > select * from base_table; > > can not return "z" column. > But passing direved_table type instead of base_table type to volume() > function for record belonging to derived_table seems to be possible and not > contradicting something, isn't it? Correct. Postgres chooses a function based on the passed signature. When you specify base_table it will choose volume(base_table) and for base_table it will be volume(derived_table) as well. FYI, there is a common practice to follow the DRY principle with inheritance and polymorphic functions in Postgres. On your example it might be shown like this: create function volume(r base_table) returns integer as $$ begin return r.x*r.y; end; $$ language plpgsql strict stable; create function volume(r derived_table) returns integer as $$ begin return volume(r::base_table) *r.z; end; $$ language plpgsql strict stable; -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray...@gmail.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] [COMMITTERS] pgsql: Upgrade to Autoconf 2.69
I wrote: > Perhaps though we should override Autoconf's setting of > _DARWIN_USE_64_BIT_INODE, if we can do that easily? It's clearly > not nearly as problem-free on 10.5 as the Autoconf boys believe, > and it's already enabled by default on the release series where it > does work. I looked into this and found that _DARWIN_USE_64_BIT_INODE is being turned on by AC_SYS_LARGEFILE. Quite aside from the wisdom of doing this at all, it's got nothing to do with the advertised purpose of that macro: the width of inode_t would affect how many files you can put on one filesystem, not how large the individual files are. I don't think that is something that we need to concern ourselves with enabling when it's not the platform default. And just to add insult to injury, the implementation technique is such that the #define gets put into pg_config.h unconditionally, even if AC_SYS_LARGEFILE isn't executed by the configure script! So IMO this is brain-dead in at least three different ways, and I've pushed a patch to revert it. We still need to address the other issues enumerated in my previous message, but this should be enough to get buildfarm member locust happy again. 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] [BUG FIX] Version number expressed in octal form by mistake
Kevin Grittner writes: > Tom Lane wrote: >> So I'm inclined to propose that we set min/max to 0 and 99 here. > Something like the attached back-patched to 8.4? Works for me. 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] [BUG FIX] Version number expressed in octal form by mistake
Tom Lane wrote: > On reflection, I'm not sure that pg_restore as such should be applying any > server version check at all. pg_restore itself has precious little to do > with whether there will be a compatibility problem; that's mostly down to > the DDL that pg_dump put into the archive file. And we don't have enough > information to be very sure about whether it will work, short of actually > trying it. So why should the code arbitrarily refuse to try? > > So I'm inclined to propose that we set min/max to 0 and 99 here. Something like the attached back-patched to 8.4? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company*** a/src/bin/pg_dump/pg_backup_archiver.c --- b/src/bin/pg_dump/pg_backup_archiver.c *** *** 297,304 RestoreArchive(Archive *AHX) if (AH->version < K_VERS_1_3) exit_horribly(modulename, "direct database connections are not supported in pre-1.3 archives\n"); ! /* XXX Should get this from the archive */ ! AHX->minRemoteVersion = 070100; AHX->maxRemoteVersion = 99; ConnectDatabase(AHX, ropt->dbname, --- 297,308 if (AH->version < K_VERS_1_3) exit_horribly(modulename, "direct database connections are not supported in pre-1.3 archives\n"); ! /* ! * We don't want to guess at whether the dump will successfully ! * restore; allow the attempt regardless of the version of the restore ! * target. ! */ ! AHX->minRemoteVersion = 0; AHX->maxRemoteVersion = 99; ConnectDatabase(AHX, ropt->dbname, -- 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] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
On 12/27/2013 07:11 AM, Peter Geoghegan wrote: On Thu, Dec 26, 2013 at 5:58 PM, Robert Haas wrote: While mulling this over further, I had an idea about this: suppose we marked the tuple in some fashion that indicates that it's a promise tuple. I imagine an infomask bit, although the concept makes me wince a bit since we don't exactly have bit space coming out of our ears there. Leaving that aside for the moment, whenever somebody looks at the tuple with a mind to calling XactLockTableWait(), they can see that it's a promise tuple and decide to wait on some other heavyweight lock instead. The simplest thing might be for us to acquire a heavyweight lock on the promise tuple before making index entries for it, and then have callers wait on that instead always instead of transitioning from the tuple lock to the xact lock. Yeah, that seems like it should work. You might not even need an infomask bit for that; just take the "other heavyweight lock" always before calling XactLockTableWait(), whether it's a promise tuple or not. If it's not, acquiring the extra lock is a waste of time but if you're going to sleep anyway, the overhead of one extra lock acquisition hardly matters. I think the interlocking with buffer locks and heavyweight locks to make that work could be complex. Hmm. Can you elaborate? The inserter has to acquire the heavyweight lock before releasing the buffer lock, because otherwise another inserter (or deleter or updater) might see the tuple, acquire the heavyweight lock, and fall to sleep on XactLockTableWait(), before the inserter has grabbed the heavyweight lock. If that race condition happens, you have the original problem again, ie. the updater unnecessarily waits for the inserting transaction to finish, even though it already killed the tuple it inserted. That seems easy to avoid. If the heavyweight lock uses the transaction id as the key, just like XactLockTableInsert/XactLockTableWait, you can acquire it before doing the insertion. Peter, can you give that a try, please? - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Polymorphic function calls
Is there any chance to implement polymorphic calls in PostgreSQL? Consider the following definitions: create table base_table (x integer, y integer); create table derived_table (z integer) inherits (base_table); create function volume(r base_table) returns integer as $$ begin return r.x*r.y; end; $$ language plpgsql strict stable; create function volume(r derived_table) returns integer as $$ begin return r.x*r.y*r.z; end; $$ language plpgsql strict stable; insert into base_table values (1,2); insert into derived_table values (3,4,5); postgres=# select * from base_table; x | y ---+--- 1 | 2 3 | 4 (2 rows) postgres=# select volume(r) from base_table r; volume 2 12 (2 rows) postgres=# select volume(r) from only base_table r union all select volume(r_1) from only derived_table r_1; volume 2 60 (2 rows) Execution plans of first and second queries are very similar. The difference is that type of r_1 in first query is "base_table". It is obvious that query should return fixed set of columns, so select * from base_table; can not return "z" column. But passing direved_table type instead of base_table type to volume() function for record belonging to derived_table seems to be possible and not contradicting something, isn't 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] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
On 12/26/2013 01:27 AM, Peter Geoghegan wrote: On Wed, Dec 25, 2013 at 6:25 AM, Andres Freund wrote: And yes, I still think that promise tuples might be a better solution regardless of the issues you mentioned, but you know what? That doesn't matter. Me thinking it's the better approach is primarily based on gut feeling, and I clearly haven't voiced clear enough reasons to convince you. So you going with your own, possibly more substantiated, gut feeling is perfectly alright. Unless I go ahead and write a POC of my own at least ;) My position is not based on a gut feeling. It is based on carefully considering the interactions of the constituent parts, plus the experience of actually building a working prototype. I also carefully considered all that stuff, and reached a different conclusion. Plus I also actually built a working prototype (for some approximation of "working" - it's still a prototype). Whoa? What? Not convincing everyone is far from it being a useless discussion. Such an attitude sure is not the way to go to elicit more feedback. And it clearly gave you the feedback that most people regard holding buffer locks across other nontrivial operations, in a potentially unbounded number, as a fundamental problem. Uh, I knew that it was a problem all along. While I explored ways of ameliorating the problem, I specifically stated that we should discuss the subsystems interactions/design, which you were far too quick to dismiss. The overall design is far more pertinent than one specific mechanism. While I certainly welcome your participation, if you want to be an effective reviewer I suggest examining your own attitude. Everyone wants this feature. Frankly I'm pissed off that you dismissed from the start the approach that seems much better to me. I gave you a couple of pointers very early on: look at the way we do exclusion constraints, and try to do something like promise tuples or killing an already-inserted tuple. You dismissed that, so I had to write that prototype myself. Even after that, you have spent zero effort to resolve the remaining issues with that approach, proclaiming that it's somehow fundamentally flawed and that locking index pages is obviously better. It's not. Sure, it still needs work, but the remaining issue isn't that difficult to resolve. Surely not any more complicated than what you did with heavy-weight locks on b-tree pages in your latest patch. Now, enough with the venting. Back to drawing board, to figure out how best to fix the deadlock issue with the insert_on_dup-kill-on-conflict-2.patch. Please help me with that. PS. In btreelock_insert_on_dup_v5.2013_12_28.patch, the language used in the additional text in README is quite difficult to read. Too many difficult sentences and constructs for a non-native English speaker like me. I had to look up "concomitantly" in a dictionary and I'm still not sure I understand that sentence :-). - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
