Re: [HACKERS] arrays as pl/perl input arguments [PATCH]
On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin wrote: > So, here is the v8. Instead of rewriting the encode_array_literal I've added > another function, encode_type_literal (could use a better name). > ... > I can easily convert the encode_array_literal to just call this function, but > not encode_array_constructor, > but I actually wonder what do we need the > encode_array_constructor (and encode_array_literal) functions for ? I > guess they were useful to pass array references to SPI, I dunno, Ill have to go dig through the archives. > but per my > understanding it's possible to use perl array references in SPI functions > directly now, so are there any other use cases for these functions, which > justify the time to spend on updating them to support arrays of composites Probably not, but I dunno if we can just drop them out from people using them... > (and shouldn't we also provide encode_composite_literal and > encode_composite_constructor as well) ? Well we should not need encode_composite_literal, encode_type_literal() should work for that. I don't see a reason for the _constructor variant so id vote against it unless there is a use case. Anyway in playing with this patch a bit more I found another bug return [[]]; would segfault. So find attached a v9 that: - fixes above segfault - made plperl_sv_to_literal vastly simpler (no longer uses SPI and calls regtypin directly) - removed extraneous added in v8 in plperl.sgml (my docbook stuff is broken, so I can't build them, hopefully there are no other problems) - we now on the fly (when its requested) make the backwards compatible string for arrays (it was a few lines now that we have plperl_sv_to_literal) - make plperl.o depend on plperl_helpers.h (should have been done in the utf8 patch) Anyway barring any more bugs, I think this patch is ready. pg_to_perl_arrays_v9.patch.gz Description: GNU Zip compressed 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] Debian readline/libedit breakage
charles.mcdev...@emc.com wrote: The GNU people will never be 100% satisfied by anything you do to psql, other than making it GPL. Readline is specifically licensed in a way to try to force this (but many disagree with their ability to force this). The "GNU people" are perfectly content with the license of PostgreSQL. They are unhappy with the license terms of OpenSSL, which is fair because they are ridiculous. Eric Young and the rest of the contributors produced a useful piece of software, and made it considerly less valuable to the world due to the ego trip terms: http://www.openssl.org/source/license.html -- the worst specific problem is the requirement to acknowledge OpenSSL use in advertising of projects that use it. The PostgreSQL community has had similar issues with popular software commonly used on top of PostgreSQL, that happened to use a non-standard license with unique terms. It would be both hypocritical and incorrect to now blame the GNU projects for taking a similar stand on this one. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- 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] Replication server timeout patch
On Feb 11, 2011 8:20 PM, "Robert Haas" wrote: > > On Fri, Feb 11, 2011 at 4:38 PM, Robert Haas wrote: > > On Fri, Feb 11, 2011 at 4:30 PM, Heikki Linnakangas > > wrote: > >> On 11.02.2011 22:11, Robert Haas wrote: > >>> > >>> On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote: > > I split this out of the synchronous replication patch for independent > review. I'm dashing out the door, so I haven't put it on the CF yet or > anything, but I just wanted to get it out there...I'll be around in > Not Too Long to finish any other details. > >>> > >>> This looks like a useful and separately committable change. > >> > >> Hmm, so this patch implements a watchdog, where the master disconnects the > >> standby if the heartbeat from the standby stops for more than > >> 'replication_[server]_timeout' seconds. The standby sends the heartbeat > >> every wal_receiver_status_interval seconds. > >> > >> It would be nice if the master and standby could negotiate those settings. > >> As the patch stands, it's easy to have a pathological configuration where > >> replication_server_timeout < wal_receiver_status_interval, so that the > >> master repeatedly disconnects the standby because it doesn't reply in time. > >> Maybe the standby should report how often it's going to send a heartbeat, > >> and master should wait for that long + some safety margin. Or maybe the > >> master should tell the standby how often it should send the heartbeat? > > > > I guess the biggest use case for that behavior would be in a case > > where you have two standbys, one of which doesn't send a heartbeat and > > the other of which does. Then you really can't rely on a single > > timeout. > > > > Maybe we could change the server parameter to indicate what multiple > > of wal_receiver_status_interval causes a hangup, and then change the > > client to notify the server what value it's using. But that gets > > complicated, because the value could be changed while the standby is > > running. > > On reflection I'm deeply uncertain this is a good idea. It's pretty > hopeless to suppose that we can keep the user from choosing parameter > settings which will cause them problems, and there are certainly far > stupider things they could do then set replication_timeout < > wal_receiver_status_interval. They could, for example, set fsync=off > or work_mem=4GB or checkpoint_segments=3 (never mind that we ship that > last one out of the box). Any of those settings have the potential to > thoroughly destroy their system in one way or another, and there's not > a darn thing we can do about it. Setting up some kind of handshake > system based on a multiple of the wal_receiver_status_interval is > going to be complex, and it's not necessarily going to deliver the > behavior someone wants anyway. If someone has > wal_receiver_status_interval=10 on one system and =30 on another > system, does it therefore follow that the timeouts should also be > different by 3X? Perhaps, but it's non-obvious. > > There are two things that I think are pretty clear. If the receiver > has wal_receiver_status_interval=0, then we should ignore > replication_timeout for that connection. And also we need to make > sure that the replication_timeout can't kill off a connection that is > in the middle of streaming a large base backup. Maybe we should try > to get those two cases right and not worry about the rest. Dan, can > you check whether the base backup thing is a problem with this as > implemented? Yes, I will have something to say come Saturday. -- fdr
Re: [HACKERS] Replication server timeout patch
On Fri, Feb 11, 2011 at 4:38 PM, Robert Haas wrote: > On Fri, Feb 11, 2011 at 4:30 PM, Heikki Linnakangas > wrote: >> On 11.02.2011 22:11, Robert Haas wrote: >>> >>> On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote: I split this out of the synchronous replication patch for independent review. I'm dashing out the door, so I haven't put it on the CF yet or anything, but I just wanted to get it out there...I'll be around in Not Too Long to finish any other details. >>> >>> This looks like a useful and separately committable change. >> >> Hmm, so this patch implements a watchdog, where the master disconnects the >> standby if the heartbeat from the standby stops for more than >> 'replication_[server]_timeout' seconds. The standby sends the heartbeat >> every wal_receiver_status_interval seconds. >> >> It would be nice if the master and standby could negotiate those settings. >> As the patch stands, it's easy to have a pathological configuration where >> replication_server_timeout < wal_receiver_status_interval, so that the >> master repeatedly disconnects the standby because it doesn't reply in time. >> Maybe the standby should report how often it's going to send a heartbeat, >> and master should wait for that long + some safety margin. Or maybe the >> master should tell the standby how often it should send the heartbeat? > > I guess the biggest use case for that behavior would be in a case > where you have two standbys, one of which doesn't send a heartbeat and > the other of which does. Then you really can't rely on a single > timeout. > > Maybe we could change the server parameter to indicate what multiple > of wal_receiver_status_interval causes a hangup, and then change the > client to notify the server what value it's using. But that gets > complicated, because the value could be changed while the standby is > running. On reflection I'm deeply uncertain this is a good idea. It's pretty hopeless to suppose that we can keep the user from choosing parameter settings which will cause them problems, and there are certainly far stupider things they could do then set replication_timeout < wal_receiver_status_interval. They could, for example, set fsync=off or work_mem=4GB or checkpoint_segments=3 (never mind that we ship that last one out of the box). Any of those settings have the potential to thoroughly destroy their system in one way or another, and there's not a darn thing we can do about it. Setting up some kind of handshake system based on a multiple of the wal_receiver_status_interval is going to be complex, and it's not necessarily going to deliver the behavior someone wants anyway. If someone has wal_receiver_status_interval=10 on one system and =30 on another system, does it therefore follow that the timeouts should also be different by 3X? Perhaps, but it's non-obvious. There are two things that I think are pretty clear. If the receiver has wal_receiver_status_interval=0, then we should ignore replication_timeout for that connection. And also we need to make sure that the replication_timeout can't kill off a connection that is in the middle of streaming a large base backup. Maybe we should try to get those two cases right and not worry about the rest. Dan, can you check whether the base backup thing is a problem with this as implemented? -- 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] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Fri, Feb 11, 2011 at 6:40 PM, Nick Rudnick wrote: > I remember well PostgreSQL has an own garbage collection (palloc() etc.;I > only know it is in utils of the backend, at mmgr), but I didn't find it on > the TODO list; so > > o would you say "hands off the garbage collection" or could you imagine > extensions? > > o would you consider the PostgreSQL garbage collection to be rather > specific (e.g., DBMS specific optimizations) or heavily interwoven into the > code -- or could it be conceivable that behaviour requirements from > PostgreSQL could be specified so far that alternative garbage collections > can be developed and inserted? Despite occasional posturing, I think that our community tends to take a pretty pragmatic view of the world. If a patch can be shown to have more upside than downside, we tend to accept it. If it has more downside than upside, we reject it. Now, I think all of us have lists of things that we're most interested in working on, based on the problems that we encounter in real life. I worked on join removal because it solved particular problems that I ran into when building web applications. Greg Smith works on checkpointing and other issues related to disk I/O because he helps people build big honking servers that use PostgreSQL, and that's where he runs into problems. Kevin Grittner implemented SSI for true serializability because it solves a problem he has. If you're fired up about improving memory management, by all means have a crack at it. As an armchair quarterback, I'm a bit doubtful that there is a significant amount of efficiency or maintainability that can be squeezed out of that subsystem, but I'd be happy to be proven wrong. There are certainly workloads where palloc overhead is significant, and if someone can find a way to make a meaningful improvement there, we're not going to reject it because we didn't think of it ourselves. > Time for a 'coming out': In the last years, I have mostly worked with pure > typed declarative languages (Haskell, Mercury), so I personally have a type > system like Hindley-Milner in mind, which by concept does not have infinite > pointer chains and also in other regards seems to be in much closer > relationship with relational database systems (an interesting, though early > state effort: http://groups.inf.ed.ac.uk/links/). I've been interested in this in the past, but the implementation challenges are daunting. -- 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] ALTER EXTENSION UPGRADE, v3
marcin mank writes: > On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane wrote: >> Hmm. Â That seems like it would require a rather pathological collection >> of upgrade scripts. Â In particular why would you have a one-step upgrade >> from 1.1 to 2.0 but no short path from 1.2? > Say we have 20 versions, with up- and downgrade scripts between > consecutive versions, and a fast path from 5 to 20. > if we are at version 6, it would go 6->5->20. if 6->5 drops a table, > we`re in trouble. So basically, to get into trouble you need all three of these elements: 1. A downgrade script; 2. A fast-path upgrade script that reverses the effect of the downgrade and skips at least two versions further than that; 3. An irreversible action in the downgrade script. That seems sufficiently far-fetched to me that documenting the hazard ought to be enough (and I've done so). If we could identify downgrade scripts, it would be easy enough to modify the shortest-path algorithm to not use them unless necessary (by assigning them a very large weight instead of weight 1). However, I'm still not excited about defining a version comparison rule just for that. One possibility is to invent a file naming rule that marks downgrade scripts, for example an extra dash: extension-oldversion-newversion-.sql I'm really not convinced it's worth the trouble, though. 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] pl/python tracebacks
On Wed, Feb 9, 2011 at 02:10, Jan Urbański wrote: > On 06/02/11 20:12, Jan Urbański wrote: >> On 27/01/11 22:58, Jan Urbański wrote: >>> On 23/12/10 14:56, Jan Urbański wrote: Here's a patch implementing traceback support for PL/Python mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the plpython-refactor patch sent eariler. >>> >>> Updated to master. >> >> Updated to master again. > > Once more. In PLy_traceback fname and prname look like they will leak (well as much as a palloc() in an error path can leak I suppose). Other than that everything looks good. I tested plpython2 and plpython3 and skimmed the docs to see if there was anything obvious that needed updating. I also obviously looked at the added regression tests and made sure they worked. Marking as Ready. -- 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] multiset patch review
On Sat, Feb 12, 2011 at 05:01, Stephen Frost wrote:
> Input arrays are always flattened into one-dimensional arrays.
> That just strikes me as completely broken when it comes to PG Arrays.
Contains operators (<@, &&, @>) ignore multi-dimensions.
Array slice operator ([lo:hi]) always reset the index offsets.
> What does the spec say about this, if anything? Is that required by
> spec, or is the spec not relevant to this because MULTISETs are only one
> dimensional..?
Yes. The SQL standard has only one-dimensional ARRAYs and MULTISETs ,
though it supports "collections of collections", that we don't have.
> I would think that we would have a way to define what dimension or piece
> of the array that would be sorted or returned as a set, etc.
It would be consistent if we return (ARRAY[][])[] => ARRAY[],
but we throw errors actually.
> In my view, we should be throwing an error if we get called on a
> multi-dim array and we can't perform the operation on that in an
> obviously correct way, not forcing the input to match something we can
> make work.
Agreed, I'll do so. We could also keep lower-bounds of arrays,
at least on sort.
> I'm not thrilled with called ArrayGetNItems array_cardinality(). Why
> not just provide a function with a name like "array_getnitems()"
> instead?
We must use the name, because it is in the SQL standard.
FUNCTION cardinality(collection) => number
We would have overloaded two versions for ARRAYs andMULTISETs.
> trim_array() suffers from two problems: lack of comments, and no spell
> checking done on those that are there.
What comments do you want?
> Should get_type_cache() really live in array_userfuncs.c ?
Do you find codes using the same operation in other files?
> There's more, primairly lack of comments and what I consider poor
> function naming ("sort_or_unique()" ? really?),
Could you suggest better names?
--
Itagaki Takahiro
--
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] Careful PL/Perl Release Not Required
On Feb 11, 2011, at 3:58 PM, Alex Hunsaker wrote: > You mean... we have been talking past each other this whole time? Well, since my second post, I think. I was wrong in the first one. > Olegs case _was_ a utf8 database. > From his original bug: > >>> Hi there, below is the problem, which I don't have when running in shell. >>> The database is in UTF-8 encoding. Ah. Stupid of me not to have seen that part. > Thats why I have been fighting the notion that he can finally get rid > of the utf8::decode(). The utf8::decode() _before_ uri_unescape() was > wrong, it "fixed" his problem but that was really a bug. The > utf8::decode() after uri_unescape() is the right answer. And he will > still need that pre and post patch. Right. >> * And your PL/Perl functions expect arguments that are byte soup >> * Once you upgrade to 9.1 they won't be >> * So you'll need to encode them. > > Yeah, I think we all agree it should be mentioned in the incompatible > section of the release notes. :-) Right, loud and clear. And the same for values returned from PL/Perl functions, right? They will no longer be returned as binary soup if you return a decoded value. I bet that's not at all common, though. Best, David -- 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] ALTER EXTENSION UPGRADE, v3
On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane wrote: > =?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= writes: >> This has the side effect that you can also have downgrade scripts. I >> don't know if this is designed or just coincidental, so thought it >> would be worth mentioning. >> The worst case is that if you are upgrading from 1.2 to 2.0 the path >> is 1.2 -> 1.1 -> 2.0, even if there exists a path 1.2 -> 1.8 -> 1.9 -> >> 2.0. This could potentially result in data loss, if the downgrade >> drops some columns or something like that. > > Hmm. That seems like it would require a rather pathological collection > of upgrade scripts. In particular why would you have a one-step upgrade > from 1.1 to 2.0 but no short path from 1.2? > Say we have 20 versions, with up- and downgrade scripts between consecutive versions, and a fast path from 5 to 20. if we are at version 6, it would go 6->5->20. if 6->5 drops a table, we`re in trouble. Greetings Marcin Mańk -- 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] Debian readline/libedit breakage
On Sat, Feb 12, 2011 at 12:15 AM, wrote: >> > Ok, but be aware that readline is GPL v3, not GPL v2, and has those >> > additional >> requirements. >> >> No > > What? From the GNU Readline home page: "Readline is free software, > distributed under the terms of the GNU General Public License, version 3." > > I know it used to be GPLv2, but that isn't true these days. There's nothing in the GPLv3 which changes things in this case. -- greg -- 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] ALTER EXTENSION UPGRADE, v3
"David E. Wheeler" writes: > On Feb 11, 2011, at 10:30 AM, Tom Lane wrote: >> It can be specified by a "directory" parameter in the control file, >> and defaults to the same place the control file is. Right now, that's >> $PREFIX/share/contrib/. > Frankly, given the likely proliferation of upgrade scripts, I think it ought > to be $PREFIX/share/contrib/$extension/ I think it should be up to the extension author to decide to do that, just as it is now. However I do see a bug in the current PGXS coding: if MODULEDIR is set, that should affect DATA and DOCS files but *not* the primary extension control file, because the place where that must be is hard-wired into extension.c. MODULEDIR should just affect the files whose location will be determined by the directory parameter in the control file. Then, if an extension author wants to put his stuff in his own subdirectory, he sets something like MODULEDIR = extension/hstore in the makefile and directory = hstore in the control file. >> One other thing that ought to be discussed is >> whether to stick with that choice or change it. Given that some people >> have great antipathy to the word "contrib", I suspect there will be >> argument to change it --- but to do so, I think we'd have to change the >> default MODULEDIR in PGXS, and I'm not sure that's a good idea. > Add EXTENSIONDIR and make it "extensions". Well, it's not exactly that easy, because we don't want to break the file layout that an old-style module is expecting PGXS to produce. But I guess what we could do is make the default definition of MODULEDIR depend on whether or not EXTENSION has been defined: "extension" if so, and backwards-compatible "contrib" if not. BTW, I'm inclined to make it $PREFIX/share/extension not extensions, but I have to admit I'm hard-pressed to explain exactly why that feels better. Anybody else care about that detail? 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] Debian readline/libedit breakage
* charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote: > > * charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote: > > > GnuTLS doesn't qualify. > > > > That should be "doesn't currently".. > > > > Doesn't currently? Does that mean you know of a project to get FIPS > certification for it? I don't. "doesn't qualify" would imply that it's incapable of attaining FIPS certification. I didn't make that claim, you did. Is there some reason that GnuTLS is incapable of attaining FIPS certification that you know of? Also, this is a very Debian-specific thread and quite a few other Debian packages use GnuTLS instead of OpenSSL. I do not expect PostgreSQL to drop support for OpenSSL, ever. > The current OpenSSL has a version that is (the only source-code-level > FIPS-140 certification ever). Yes, I'm aware, I didn't dispute that. > And yes, it is API compatible with the non-FIPS one. It just doesn't support > some of the algorithms that the other does. When I looked into addressing this for our C&A'd systems it wasn't at all clear that it was trivial to move from non-FIPS OpenSSL to FIPS-compliant OpenSSL. Perhaps that's changed but, sadly, there's a heck of a lot more encryption out there than just what OpenSSL will give you (the Linux kernel being a primary example, but also the MIT Kerberos libraries). Yes, it means you have to address that FISMA control, but that's not an insurmountable problem and is, really, a reality for anyone running a serious Linux-based environment, in my experience. What I don't think people appreciate or realize is that there's a lot of other encryption happening in their systems beyond what OpenSSL does. > The GNU people will never be 100% satisfied by anything you do to psql, other > than making it GPL. > Readline is specifically licensed in a way to try to force this (but many > disagree with their ability to force this). This doesn't deserve a response. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Debian readline/libedit breakage
> -Original Message- > From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg Stark > Sent: Friday, February 11, 2011 4:14 PM > To: McDevitt, Charles > Cc: sfr...@snowman.net; alvhe...@commandprompt.com; > g...@2ndquadrant.com; mba...@debian.org; t...@sss.pgh.pa.us; > and...@dunslane.net; j...@commandprompt.com; pgsql- > hack...@postgresql.org > Subject: Re: Debian readline/libedit breakage > > On Sat, Feb 12, 2011 at 12:07 AM, wrote: > >> This is just libelous FUD. There's absolutely no reason postgres would > >> have to be GPL'd to satisfy any library license. > > > > Ok, but be aware that readline is GPL v3, not GPL v2, and has those > > additional > requirements. > > No What? From the GNU Readline home page: "Readline is free software, distributed under the terms of the GNU General Public License, version 3." I know it used to be GPLv2, but that isn't true these days. -- 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] arrays as pl/perl input arguments [PATCH]
On Feb 10, 2011, at 11:26 PM, Alexey Klyukin wrote:
> On Feb 10, 2011, at 9:44 PM, Andrew Dunstan wrote:
>
>> On 02/10/2011 08:15 AM, Alexey Klyukin wrote:
>>>
>>> Let me try implementing that as an XS interface to plperl_array_to_datum.
>>
>>
>> Are you intending this as a completion of the current patch or as 9.2 work?
>> If the former you need to send it in real fast.
>
> I'd like to extend the current patch, going to post the update by tomorrow.
So, here is the v8. Instead of rewriting the encode_array_literal I've added
another function, encode_type_literal (could use a better name). basically a
user-level interface to plperl_sv_to_datum, which accepts the perl variable
and the type name as a text string and returns the string representation of
the input variable according to the output function of the argument type, e..g:
do $$ elog(NOTICE, encode_type_literal([[1],[2],[3]], 'int[]'));$$ language
plperl;
NOTICE: {{1},{2},{3}}
I can easily convert the encode_array_literal to just call this function, but
not encode_array_constructor, since the latter needs to produce its own string
representation, different from the result of the type output function. One
option would be traversing through the SV *, duplicating the efforts of
plperl_sv_to_datum, but I actually wonder what do we need the
encode_array_constructor (and encode_array_literal) functions for ? I
guess they were useful to pass array references to SPI, but per my
understanding it's possible to use perl array references in SPI functions
directly now, so are there any other use cases for these functions, which
justify the time to spend on updating them to support arrays of composites
(and shouldn't we also provide encode_composite_literal and
encode_composite_constructor as well) ?
/A
--
Alexey Klyukin
The PostgreSQL Company - Command Prompt, Inc.
pg_to_perl_arrays_v8.patch.gz
Description: GNU Zip compressed 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] Debian readline/libedit breakage
On Sat, Feb 12, 2011 at 12:07 AM, wrote: >> This is just libelous FUD. There's absolutely no reason postgres would >> have to be GPL'd to satisfy any library license. > > Ok, but be aware that readline is GPL v3, not GPL v2, and has those > additional requirements. No -- greg -- 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] Debian readline/libedit breakage
-Original Message- > From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg Stark > Sent: Friday, February 11, 2011 4:03 PM > On Fri, Feb 11, 2011 at 11:06 PM, wrote: > > The GNU people will never be 100% satisfied by anything you do to psql, > > other > than making it GPL. > > Readline is specifically licensed in a way to try to force this (but many > > disagree > with their ability to force this). > > This is just libelous FUD. There's absolutely no reason postgres would > have to be GPL'd to satisfy any library license. Ok, but be aware that readline is GPL v3, not GPL v2, and has those additional requirements. -- 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] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 11:06 PM, wrote: > The GNU people will never be 100% satisfied by anything you do to psql, other > than making it GPL. > Readline is specifically licensed in a way to try to force this (but many > disagree with their ability to force this). This is just libelous FUD. There's absolutely no reason postgres would have to be GPL'd to satisfy any library license. In fact doing so would make the problem worse, not better since then the license on Postgres itself would (allegedly) conflict with the OpenSSL license. There's no question that the resulting binary when linked with readline is covered by the GPL including shipping source code etc. This is non-controversial and the original intent of licensing readline under the GPL. This isn't the same question as GIMP plugins or code using GMP which are themselves functionally dependent on the GPL'd code and some claim are therefore derivative works. I don't think anyone would claim that Postges is a derivative work of readline. The only question here is whether the OpenSSL license imposes requirements which cannot be met at the same time as the GPL requirements. The rest of Postgres itself doesn't conflict but if you're distributing a binary then you're covered by all the licenses of the code you include and depend on (the last part is somewhat controversial but irrelevant to this topic since OpenSSL headers are already included). So if the OpenSSL license imposes restrictions that the GPL bars then the resulting binary is not distributable. I suspect RedHat may have determined that the OpenSSL license requirements are not in fact mutually exclusive with the GPL either because they're not enforceable at all in the US anyways or because the way they read them they can be satisfied without violating the GPL. It's also possible they just decided it's unlikely the OpenSSL people would ever sue or the damages would be negligable. Of course this is all speculation. -- greg -- 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] Replication server timeout patch
On Fri, Feb 11, 2011 at 12:11 PM, Robert Haas wrote: > On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote: >> I split this out of the synchronous replication patch for independent >> review. I'm dashing out the door, so I haven't put it on the CF yet or >> anything, but I just wanted to get it out there...I'll be around in >> Not Too Long to finish any other details. > > This looks like a useful and separately committable change. > > However, it looks to me like this renders wal_sender_delay aka > WalSndDelay completely unused. If we don't need that GUC any more, we > should rip it out completely. Indeed; I have cleaned this up. > The comment in WalSndHandshake should have a tab at the beginning of > every line. Right now the first line has a tab and the rest have > spaces. > Also correct. Done. > The first hunk in WalSndLoop is a meaningless whitespace change. I was trying to get it under 80 columns wide, but yes, it is unnecessary. I think this closes out the small fry. I have rebased my splitorific branch to reflect these changes: https://github.com/fdr/postgres/commits/splitorific Context diff equivalent attached. -- fdr 0001-Split-and-rename-out-server-timeout-of-clients-2.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
Re: [HACKERS] Careful PL/Perl Release Not Required
On Fri, Feb 11, 2011 at 16:42, David E. Wheeler wrote: > On Feb 11, 2011, at 12:57 PM, Alex Hunsaker wrote: > >> Yay! 1 > > Yes, this is all good. But it still seems to me that: > > * If your database is neither utf-8 no sql_ascii You mean... we have been talking past each other this whole time? Olegs case _was_ a utf8 database. >From his original bug: >> Hi there, below is the problem, which I don't have when running in shell. >> The database is in UTF-8 encoding. Thats why I have been fighting the notion that he can finally get rid of the utf8::decode(). The utf8::decode() _before_ uri_unescape() was wrong, it "fixed" his problem but that was really a bug. The utf8::decode() after uri_unescape() is the right answer. And he will still need that pre and post patch. > * And your PL/Perl functions expect arguments that are byte soup > * Once you upgrade to 9.1 they won't be > * So you'll need to encode them. Yeah, I think we all agree it should be mentioned in the incompatible section of the release notes. :-) -- 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] Careful PL/Perl Release Not Required
On Feb 11, 2011, at 12:57 PM, Alex Hunsaker wrote: > Yay! 1 Yes, this is all good. But it still seems to me that: * If your database is neither utf-8 no sql_ascii * And your PL/Perl functions expect arguments that are byte soup * Once you upgrade to 9.1 they won't be * So you'll need to encode them. Unless I've completely misunderstood the change in how arguments are passed. Best, David -- 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] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Hi Josh, at first, thanks for all the interesting info given Correct, AFAIK. o extensions of PostgreSQL to support such a kind of usage have to be expected to be expected to be rejected from integration to the code base core -- i.e., if they are done, students have to be told «you can't expect this to become a part of PostgreSQL» Not necessarily. We "rule out" *very* few things from PostgreSQL; I think the TODO list only has 3 ideas which are contraindicated. After reading these points, I would say it really is a very liberal policy... and I can't resist the temptation to ask about garbage collection: I remember well PostgreSQL has an own garbage collection (palloc() etc.;I only know it is in utils of the backend, at mmgr), but I didn't find it on the TODO list; so o would you say "hands off the garbage collection" or could you imagine extensions? o would you consider the PostgreSQL garbage collection to be rather specific (e.g., DBMS specific optimizations) or heavily interwoven into the code -- or could it be conceivable that behaviour requirements from PostgreSQL could be specified so far that alternative garbage collections can be developed and inserted? However, the warning is that this particular *set* of ideas has some very high hurdles to jump before it could be considered seriously for core, and that none of the existing committers seem interested in helping with it. So the level of difficulty for the implementer would be considerably greater than for many other patches of less invasiveness and clearer apparent utility. Among the hurdles are: a. performance: you'd have to work out how to make nested object resolution not take forever and burn up the CPUs Time for a 'coming out': In the last years, I have mostly worked with pure typed declarative languages (Haskell, Mercury), so I personally have a type system like Hindley-Milner in mind, which by concept does not have infinite pointer chains and also in other regards seems to be in much closer relationship with relational database systems (an interesting, though early state effort: http://groups.inf.ed.ac.uk/links/). As (partially due to emerging multicore technology) the trend seems to go into this direction (Scala for Java, inclusion of FP functionality in C++), and such type system may be regarded as competitive with OO, I personally don't see much motivation for a such forced marriage like ISO/IEC 9075-10 (SQL/OLB). The difficulty in regard of pure typed declarative languages rather seems to be garbage collection (therefore the question above), as it in these language environments uses to be a very sophisticated piece of programming, subject of intensive research efforts, so it would be a problem if the PostgreSQL garbage collection would be equally complex. b. resolution: you'd need to come up with an object naming practice which compliments, intead of conflicts with, the SQL-standard syntax of course... c. utility: you'd have to demonstrate why all this was actually useful. in short gross words: a typed rulebase extension. ai. joint-venturing with leading teams in this area. Is this understood correctly, especially the last point, or did Robert/Tom just specifically address syntactical conflicts (between schema and object semantics) with the point notation? Syntactic conflicts are also significant, as anyone who's used EDB's "packages" mod can tell you. So these would need to be worked out as well, and NOT in a way which breaks backwards compatibility. completely d'accord... Otherwise, the striking lack of academical initiatives in the area of OO and rule inference on top of PostgreSQL appears to me as a demand to Hmmm. I don't know about that; I've never seen that academics *cared* whether or not their code god into -core. Unfortunately this is well said... Thanks for your infos, Nick -- 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] Add support for logging the current role
I wrote:
> Patch attached.
This time with src/backend/utils/misc/postgresql.conf.sample fixed.
-Kevin
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 5188,5202 dynamic_library_path =
'C:\tools\postgresql;H:\my_project\lib;$libdir'
!
! max_predicate_locks_per_transaction
(integer)
!max_predicate_locks_per_transaction configuration
parameter
The shared predicate lock table tracks locks on
! max_predicate_locks_per_transaction * ( + ) objects (e.g., tables);
hence, no more than this many distinct objects can be locked at
--- 5188,5202
!
! max_pred_locks_per_transaction
(integer)
!max_pred_locks_per_transaction configuration
parameter
The shared predicate lock table tracks locks on
! max_pred_locks_per_transaction * ( + ) objects (e.g., tables);
hence, no more than this many distinct objects can be locked at
*** a/src/backend/storage/lmgr/predicate.c
--- b/src/backend/storage/lmgr/predicate.c
***
*** 1874,1880 DeleteChildTargetLocks(const PREDICATELOCKTARGETTAG
*newtargettag)
* thresholds are, either making it proportional to the number of
* tuples in a page & pages in a relation, or at least making it a
* GUC. Currently the threshold is 3 for a page lock, and
! * max_predicate_locks_per_transaction/2 for a relation lock, chosen
* entirely arbitrarily (and without benchmarking).
*/
static int
--- 1874,1880
* thresholds are, either making it proportional to the number of
* tuples in a page & pages in a relation, or at least making it a
* GUC. Currently the threshold is 3 for a page lock, and
! * max_pred_locks_per_transaction/2 for a relation lock, chosen
* entirely arbitrarily (and without benchmarking).
*/
static int
***
*** 2063,2069 CreatePredicateLock(const PREDICATELOCKTARGETTAG *targettag,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_predicate_locks_per_transaction.")));
if (!found)
{
SHMQueueInit(&(target->predicateLocks));
--- 2063,2069
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_pred_locks_per_transaction.")));
if (!found)
{
SHMQueueInit(&(target->predicateLocks));
***
*** 2082,2088 CreatePredicateLock(const PREDICATELOCKTARGETTAG *targettag,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_predicate_locks_per_transaction.")));
if (!found)
{
--- 2082,2088
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_pred_locks_per_transaction.")));
if (!found)
{
***
*** 2341,2347 PredicateLockTupleRowVersionLink(const Relation relation,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_predicate_locks_per_transaction.")));
if (!found)
{
SHMQueueInit(&(newtarget->predicateLocks));
--- 2341,2347
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_pred_locks_per_transaction.")));
if (!found)
{
SHMQueueInit(&(newtarget->predicateLocks));
***
*** 3337,3343 ReleaseOneSerializableXact(SERIALIZABLEXACT *sxact, bool
partial,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to
increase max_predicate_locks_per_transaction.")));
if (found)
{
if
Re: [HACKERS] Debian readline/libedit breakage
> * charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote: > > Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 > compliance is essential to many Federal users. > > Essential? That's a bit much. Yes, it shows up on a FISMA review as an > open action item, but it's a risk that can both be accepted and > mitigated. I also thought FIPS-140 version required API changes.. > > > GnuTLS doesn't qualify. > > That should be "doesn't currently".. > Doesn't currently? Does that mean you know of a project to get FIPS certification for it? I don't. The current OpenSSL has a version that is (the only source-code-level FIPS-140 certification ever). And yes, it is API compatible with the non-FIPS one. It just doesn't support some of the algorithms that the other does. The GNU people will never be 100% satisfied by anything you do to psql, other than making it GPL. Readline is specifically licensed in a way to try to force this (but many disagree with their ability to force this). -- 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] Add support for logging the current role
Stephen Frost wrote:
> Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'd be happy with "max_pred_locks_per_transaction" which gets the
>> worst case down without being too obviously at variance with
>> "max_locks_per_transaction".
>
> Sounds good to me. The header length for show all would drop to
> only 206 characters (or so) with that change.
Patch attached.
-Kevin
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 5188,5202 dynamic_library_path =
'C:\tools\postgresql;H:\my_project\lib;$libdir'
!
! max_predicate_locks_per_transaction
(integer)
!max_predicate_locks_per_transaction configuration
parameter
The shared predicate lock table tracks locks on
! max_predicate_locks_per_transaction * ( + ) objects (e.g., tables);
hence, no more than this many distinct objects can be locked at
--- 5188,5202
!
! max_pred_locks_per_transaction
(integer)
!max_pred_locks_per_transaction configuration
parameter
The shared predicate lock table tracks locks on
! max_pred_locks_per_transaction * ( + ) objects (e.g., tables);
hence, no more than this many distinct objects can be locked at
*** a/src/backend/storage/lmgr/predicate.c
--- b/src/backend/storage/lmgr/predicate.c
***
*** 1874,1880 DeleteChildTargetLocks(const PREDICATELOCKTARGETTAG
*newtargettag)
* thresholds are, either making it proportional to the number of
* tuples in a page & pages in a relation, or at least making it a
* GUC. Currently the threshold is 3 for a page lock, and
! * max_predicate_locks_per_transaction/2 for a relation lock, chosen
* entirely arbitrarily (and without benchmarking).
*/
static int
--- 1874,1880
* thresholds are, either making it proportional to the number of
* tuples in a page & pages in a relation, or at least making it a
* GUC. Currently the threshold is 3 for a page lock, and
! * max_pred_locks_per_transaction/2 for a relation lock, chosen
* entirely arbitrarily (and without benchmarking).
*/
static int
***
*** 2063,2069 CreatePredicateLock(const PREDICATELOCKTARGETTAG *targettag,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_predicate_locks_per_transaction.")));
if (!found)
{
SHMQueueInit(&(target->predicateLocks));
--- 2063,2069
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_pred_locks_per_transaction.")));
if (!found)
{
SHMQueueInit(&(target->predicateLocks));
***
*** 2082,2088 CreatePredicateLock(const PREDICATELOCKTARGETTAG *targettag,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_predicate_locks_per_transaction.")));
if (!found)
{
--- 2082,2088
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_pred_locks_per_transaction.")));
if (!found)
{
***
*** 2341,2347 PredicateLockTupleRowVersionLink(const Relation relation,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_predicate_locks_per_transaction.")));
if (!found)
{
SHMQueueInit(&(newtarget->predicateLocks));
--- 2341,2347
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of shared memory"),
!errhint("You might need to increase
max_pred_locks_per_transaction.")));
if (!found)
{
SHMQueueInit(&(newtarget->predicateLocks));
***
*** 3337,3343 ReleaseOneSerializableXact(SERIALIZABLEXACT *sxact, bool
partial,
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
Re: [HACKERS] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 5:22 PM, Martijn van Oosterhout wrote: > On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote: >> Note that the past discussion was on the difficulty of matching the >> existing OpenSSL API using GnuTLS, which is apparently difficult to do. >> I wasn't trying to suggest there were issues specificially with GnuTLS's >> code quality. It's more that the APIs are just different enough that >> it's not trivial to do a swap--which is surprising given how many people >> have seemingly needed to do exactly this conversion. You'd think >> there'd be a simple "OpenSSL-like" interface available for GnuTLS by now >> or something. > > I spent some time a while back making PostgreSQL work with GnuTLS. The > actual SSL bit is trivial. The GnuTLS interface actually made sense > whereas the OpenSSL one is opaque (at least, I've never seen any > structure in it). The GnuTLS interface was designed in the modern era > and it shows. > > The problems are primarily that psql exposes in various ways that it > uses OpenSSL and does it in ways that are hard to support backward > compatably. So for GnuTLS support you need to handle all those bits > too. > > For example, the patch as presented introduced a passthrough mode that > allowed applications to read/write over the SSL connection without > actually knowing the underlying library. It had to fix psql to use this > info. It had to provide ways for applications to determine the info > they needed about the SSL, since it wouldn't beable to just grab the > OpenSSL handle. > > All this made the patch large, which caused it to be rejected. I found > that odd since the bulk of the patch was the renaming of two files, > which makes for huge diffs while the changes where minimal. I beleive > git is smarter about renames which means the diff may magically become > much smaller just by using git, yay! > > Supporting GnuTLS for that backend was just icing, but trivial once the > frontend was done. It can be left out. We should probably revisit this for 9.2. -- 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] Sorting. When?
2011/2/11 Kevin Grittner : > "mac_man2...@yahoo.it" wrote: > >> I need to know, from an algorithmic point of view, in which cases >> sorting is invoked. [..] > Are your really looking to categorize the types of queries where > sorting is *invoked*, or the ones where it is *considered*? Or > perhaps only those where it is *required*, since there are no > possible plans without sorting? Or, if you are seeking the exact rules that are used by the planner to determine all possible plans from which the one with minimum cost is chosen (and hence all ways in which sorts can be used), I think that the source code is the only complete reference. A non-complete introduction is: http://www.postgresql.org/docs/9.0/static/planner-optimizer.html> Basically, physical operators (seq scan, index scan, hash join, merge join, nested loop, filter, set operation, etc) may require their input to satisfy certain sort constraints (for example, both inputs of a merge join need to be sorted on the join attribute(s)). If it happens to be of lowest cost to explicitly sort the inputs right before consuming them, that will be done. If there is a way to get the same input in an already-ordered way (for example an index scan, or the output of a merge join), so that the cost is less than the non-ordered way + an explicit sort, then that already-ordered way will be chosen. Super-basic example: SELECT * FROM t ORDER BY a; This may either perform a seq scan of table t and then do an explicit sort, or perform a full index scan of an index on attribute a (provided that such an index exists), in which case the explicit sort is not needed because the index scan will deliver the rows in already-sorted order. Which option is chosen depends on the cost: The costs of both plans are calculated and the least costly plan is chosen. See the (non-exhaustive) list of things that influence the costs provided by Kevin to get a feeling for how many variables there are that influence this choice. Nicolas -- 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] Range Types: empty ranges
On Fri, Feb 11, 2011 at 10:11:45AM -0800, Jeff Davis wrote: > The cost, of course, is that not all operations are well-defined for > empty ranges. I think those are mostly operators like those mentioned in > the other thread: ">>" (strictly right of), "<<" (strictly left of), and > "-|-" (adjacent); and perhaps "&>" and "&<". These are probably used a > little less frequently, and should probably not be used in a context > where empty ranges are permitted (if they are, it's likely a mistake and > an error should be thrown). But surely this is just a matter of your definitions? If you define "A strictly left of B" as "all points in A are less than all points in B", then you might have a problem with "all points" of an empty range. If you define it as "not (any points in A to the right of any points in B)" then the answer for an empty range is well defined (namely true). I think once you make workable definitions then empty ranges should pose no problems. Sure, it may be that an empty range will be both to the left and to the right of every other set. That doesn't make it wrong. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle signature.asc Description: Digital signature
Re: [HACKERS] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 02:09:09PM -0500, Greg Smith wrote: > Note that the past discussion was on the difficulty of matching the > existing OpenSSL API using GnuTLS, which is apparently difficult to do. > I wasn't trying to suggest there were issues specificially with GnuTLS's > code quality. It's more that the APIs are just different enough that > it's not trivial to do a swap--which is surprising given how many people > have seemingly needed to do exactly this conversion. You'd think > there'd be a simple "OpenSSL-like" interface available for GnuTLS by now > or something. I spent some time a while back making PostgreSQL work with GnuTLS. The actual SSL bit is trivial. The GnuTLS interface actually made sense whereas the OpenSSL one is opaque (at least, I've never seen any structure in it). The GnuTLS interface was designed in the modern era and it shows. The problems are primarily that psql exposes in various ways that it uses OpenSSL and does it in ways that are hard to support backward compatably. So for GnuTLS support you need to handle all those bits too. For example, the patch as presented introduced a passthrough mode that allowed applications to read/write over the SSL connection without actually knowing the underlying library. It had to fix psql to use this info. It had to provide ways for applications to determine the info they needed about the SSL, since it wouldn't beable to just grab the OpenSSL handle. All this made the patch large, which caused it to be rejected. I found that odd since the bulk of the patch was the renaming of two files, which makes for huge diffs while the changes where minimal. I beleive git is smarter about renames which means the diff may magically become much smaller just by using git, yay! Supporting GnuTLS for that backend was just icing, but trivial once the frontend was done. It can be left out. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle signature.asc Description: Digital signature
Re: [HACKERS] Range Types: empty ranges
FWIW, a very informal survey of probabilists didn't yield any reason for trying to put an order on the empty set ( unless the metric was cardinality or other equivalence relation ). I think the problem here is that the idea of union and intersection forming a ring over sets is being conflated with the order relation. Clearly, combining the two notions can be inconsistent. However... >> > A UNION (B INTERSECT C) = (A UNION B) INTERSECT (A UNION C) >> >> But the basic range type isn't even closed under UNION. > > An excellent point. Allow me to move the target a little: > > WHERE A && B AND A && C > and: > WHERE A && (B INTERSECT C) > > That seems like a logically sound transformation, but if (B INTERSECT C) > is empty, it relies on the empty range for those two to be equivalent. > > Now, I agree that lack of closure on UNION exhibits many of the problems > that I am pointing out related to forbidding empty ranges. However, I'm > not sure if that means we should give up on either. This seems potentially very useful, because we can transform WHERE A && B AND A && C from a bitmap scan into WHERE A && (B INTERSECT C), a simple index scan. In the union case ( even if we had a type that supported disjoint intervals), I doubt we would ever make that transformation because the index will probably still be over connected intervals. So, +1 for keeping it how it is ( but maybe with a better error message ). Best, Nathan -- 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] psql patch: tab-complete :variables also at buffer start
On Thu, Feb 10, 2011 at 8:13 AM, Itagaki Takahiro wrote: > On Thu, Feb 10, 2011 at 19:37, Christoph Berg wrote: >> Currently, tab-completing :variable names in psql does not work at the >> beginning of the line. Fix this by moving the code block before the >> "empty buffer" case. > > Seems reasonable to me. OK, committed. -- 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] Replication server timeout patch
On Fri, Feb 11, 2011 at 4:30 PM, Heikki Linnakangas wrote: > On 11.02.2011 22:11, Robert Haas wrote: >> >> On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote: >>> >>> I split this out of the synchronous replication patch for independent >>> review. I'm dashing out the door, so I haven't put it on the CF yet or >>> anything, but I just wanted to get it out there...I'll be around in >>> Not Too Long to finish any other details. >> >> This looks like a useful and separately committable change. > > Hmm, so this patch implements a watchdog, where the master disconnects the > standby if the heartbeat from the standby stops for more than > 'replication_[server]_timeout' seconds. The standby sends the heartbeat > every wal_receiver_status_interval seconds. > > It would be nice if the master and standby could negotiate those settings. > As the patch stands, it's easy to have a pathological configuration where > replication_server_timeout < wal_receiver_status_interval, so that the > master repeatedly disconnects the standby because it doesn't reply in time. > Maybe the standby should report how often it's going to send a heartbeat, > and master should wait for that long + some safety margin. Or maybe the > master should tell the standby how often it should send the heartbeat? I guess the biggest use case for that behavior would be in a case where you have two standbys, one of which doesn't send a heartbeat and the other of which does. Then you really can't rely on a single timeout. Maybe we could change the server parameter to indicate what multiple of wal_receiver_status_interval causes a hangup, and then change the client to notify the server what value it's using. But that gets complicated, because the value could be changed while the standby is running. -- 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] btree_gist (was: CommitFest progress - or lack thereof)
* Robert Haas (robertmh...@gmail.com) wrote: > > Teodor sent it to the list Dec 28, see > > http://archives.postgresql.org/message-id/4D1A1677.80300%40sigaev.ru [...] > That having been said, this looks like a fairly mechanical change to a > contrib module that you and Teodor wrote. So I'd say if you guys are > confident that it's correct, go ahead and commit. If you need it > reviewed, or if you can't commit it in the next week or so, I think > it's going to have to wait for 9.2. Alright, I've gone through this patch and the main thing it's missing is documentation, as far as I can tell. It passes all the regression tests (and adds a number of them which are then tested with, which is always nice) and while there are quite a few changes, they're all pretty mechanical and simple. There are some really minor whitespace issues too, but overall I think this is ready to be committed, so long as we have a promise that someone will write up the documentation for it. I'd write the docs, but I'm not 100% sure that I know what's going on enough to really write them correctly. :) I'm also hoping that someone else is already working on them. If not, feel free to ping me and I'll work on writing up *something*, at least. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Replication server timeout patch
On 11.02.2011 22:11, Robert Haas wrote: On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote: I split this out of the synchronous replication patch for independent review. I'm dashing out the door, so I haven't put it on the CF yet or anything, but I just wanted to get it out there...I'll be around in Not Too Long to finish any other details. This looks like a useful and separately committable change. Hmm, so this patch implements a watchdog, where the master disconnects the standby if the heartbeat from the standby stops for more than 'replication_[server]_timeout' seconds. The standby sends the heartbeat every wal_receiver_status_interval seconds. It would be nice if the master and standby could negotiate those settings. As the patch stands, it's easy to have a pathological configuration where replication_server_timeout < wal_receiver_status_interval, so that the master repeatedly disconnects the standby because it doesn't reply in time. Maybe the standby should report how often it's going to send a heartbeat, and master should wait for that long + some safety margin. Or maybe the master should tell the standby how often it should send the heartbeat? -- 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] Range Types: empty ranges
Jeff Davis wrote: >> Perhaps it was a mistake to get so concrete rather than >> conceptual -- basically, it seems like it could be a useful >> concept for any planned or scheduled range with an indeterminate >> end point, which you want to "reserve" up front and record in >> progress until complete. > > Maybe this is a range... would it be served by: > (5, INF) > or: > [5, INF) > ? > > That's already supported, and it means "all points greater than > 5". Well that would create a range of infinite size until you started using it, at which point it would drop to tiny and start to increase until completion, which would be kinda weird as well as error-prone. At least for the uses I'm considering. I'm sure we can work around it if it isn't supported, but for our purposes, [x,x) ranges would be a useful construct. >> Of course, the *most* useful places for our shop to have ranges >> are temporal. Many (most?) of those are situations where you >> start with a range with an unknown end and later (often years >> later) fill in the end of the range based on some event which >> finally closes it. Again, two discreet dates with a null-capable >> end-date work, but I can see where ranges could potentially be >> more powerful. > > Ranges support infinite boundaries, but do not support NULL > (previous discussion concluded that NULL boundaries were likely to > be confusing and served no obvious use case not handled by > infinity). Yeah, infinity works fine as long as you realize it's only temporary. I don't know whether there are any practical uses where on the low end it doesn't mean "some particular date we don't know or don't care enough to determine" and on the high end doesn't mean "some particular date which we don't know or which hasn't yet been fixed". For the latter we have, so far, been using NULL, since we were trying to stay portable and not all products support infinity. We're committing to PostgreSQL now, so we could start to use infinity for these temporarily indefinite values, and I would expect to do so in ranges. -Kevin -- 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] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 12:25 PM, Stephen Frost wrote: > * charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote: >> Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 >> compliance is essential to many Federal users. > > Essential? That's a bit much. Yes, it shows up on a FISMA review as an > open action item, but it's a risk that can both be accepted and > mitigated. I also thought FIPS-140 version required API changes.. > >> GnuTLS doesn't qualify. > > That should be "doesn't currently".. Not being a SSL aficionado by any means, but what about NSS? That's pretty mature, and could be another viable option. -- fdr -- 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] Careful PL/Perl Release Not Required
On Fri, Feb 11, 2011 at 11:07, David E. Wheeler wrote:
> I don't understand where the bug is. If a string is encoded in utf-8 Perl
> will not treat it as such unless the utf-8 flag is set.
Ok so I think we agreed this is right:
$ perl -E 'use URI::Escape; my $str = uri_unescape("%C3%A9"); say
sprintf("chr: %s hex: %s, len: %s", $str, unpack("H*", $str), length
$str)'
chr: é hex: c3a9, len: 2
Key part here is len = 2, or 2 characters.
Lets try that in a postgres 9.0 utf8 database:
=> create or replace function uri_decode(txt text, in_decode int,
out_decode int) returns text as $$
use URI::Escape;
my $str = shift;
utf8::decode($str) if(shift);
$str = uri_unescape($str);
utf8::decode($str) if(shift);
return $str;
$$ language plperlu;
-- For ease we are just going to look at the length as most terminals
will have utf8 and latin1 mapped.
=> SELECT length(uri_decode('%c3%a9', 0, 0));
length
2
(1 row)
Looks right.
What happens if we decode after uri_unescape, we should get 1 character no?
-- decode after uri_unescape
=> SELECT length(uri_decode('%c3%a9', 0, 1));
length
1
Ok thats right.
What happens if we decode before? Nothing should right? After all
'%c3%a9' is all asci. We should still get 2 characters.
=> SELECT length(uri_decode('%c3%a9', 1, 0));
length
1
Whoa! 1? Does vanilla perl do that?:
perl <<'perl'
use URI::Escape;
my $str = '%c3%a9';
utf8::decode($str);
$str = uri_unescape($str);
print sprintf("chr: %s hex: %s, len: %s\n", $str, unpack("H*", $str), length
$str);
perl
chr: é hex: c3a9, len: 2
Nope, so postgres gets it wrong here. Thats the problem.
In 9.1 it does "the right thing":
=> SELECT length(uri_decode(0, 0));
length
2
Yay! 2!
=> SELECT length(uri_decode(1, 0));
CONTEXT: PL/Perl function "uri_decode"
length
2
Yay! also 2!
=> SELECT length(uri_decode(0, 1));
length
1
Yay! 1
--
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] ALTER EXTENSION UPGRADE, v3
Tom Lane writes: > I don't see what that does for you. This is still all being examined by > a particular major release of PG, so what will it do with a require that > specifies some other major release? Nothing useful. And there's a very > significant downside, which is that this takes us right back to the > make-work of having to change all the contrib modules' control files in > every release cycle. Mmm, yes we're missing the | operator for dependencies here. I didn't expect extensions that support more than one major version at a time to use the feature, but obviously that's not good enough. > Once again, I see the version numbers as being specifiers for versions > of the install script files. Not the Postgres version those files are > being run in. Confusing the two is a bad idea. Confusing the install > script version numbers with minor release numbers (bugfix level > identifiers) is even worse. You *don't* want to change these numbers if > you're just fixing a bug at the C code level. Agreed on the C side maintenance and releasing. What if your extension is PL/pgSQL only and you just fixed a bug in one of the functions? -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] ALTER EXTENSION UPGRADE, v3
Tom Lane writes: > Anything that got kicked out to pgfoundry would presumably start acting > that way. Anything that's part of core git is going to stay on the same > release cycle as the core, thank you very much. Release engineering is > a big enough headache around here already. Yeah, I should have inquired before to propose. I see two solutions here, one is to just do as you say, the other one would be to have a separate git repository for extensions. You can ignore this if only the default option (your proposal) is sensible… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] ALTER EXTENSION UPGRADE, v3
Tom Lane writes:
>> The worst case is that if you are upgrading from 1.2 to 2.0 the path
>> is 1.2 -> 1.1 -> 2.0, even if there exists a path 1.2 -> 1.8 -> 1.9 ->
>> 2.0. This could potentially result in data loss, if the downgrade
>> drops some columns or something like that.
>
> Hmm. That seems like it would require a rather pathological collection
> of upgrade scripts. In particular why would you have a one-step upgrade
> from 1.1 to 2.0 but no short path from 1.2?
I think it just mean that we have to provide a function for extension
authors to check and validate their upgrade chains. We have to have a
way to check that without having to replay all the possible and
supported upgrade situations provided in the script, because it's a pain
to defend against cycles made up by the system that you didn't intend to
support.
Maybe something like:
=# SELECT * FROM pg_available_extension_upgrades('foo');
installed | available | chain
---+---+--
1.2 | 2.0 | 1.2 -> 1.1 -> 2.0
1.2 | 1.9 | 1.2 -> 1.8 -> 1.9 -> 2.0
1.2 | 1.8 | 1.2 -> 1.8
1.2 | 1.1 | 1.2 -> 1.1
(4 rows)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] ALTER EXTENSION UPGRADE, v3
Dimitri Fontaine writes: > Tom Lane writes: >> I think it'd likely be sufficient to bump them only once per release >> cycle, ie, there's no need to distinguish versions that never appeared >> in the wild. But if we forgot and created 1.1 early in the 9.2 release >> cycle and 1.2 late in the cycle, there's no great harm done either. >> What I don't want to be doing is creating artificial version bumps with >> empty upgrade scripts in every release cycle --- that's make-work for >> us, and make-work for our users too. > I would favor different release cycles for extensions than for the core > product. It's a technical fact that a single extension source can and > do support more than one major core version. And as soon as the code is > maintained, next extension release would happen at next minor upgrade > release. Anything that got kicked out to pgfoundry would presumably start acting that way. Anything that's part of core git is going to stay on the same release cycle as the core, thank you very much. Release engineering is a big enough headache around here already. 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] Sorting. When?
"mac_man2...@yahoo.it" wrote: > I need to know, from an algorithmic point of view, in which cases > sorting is invoked. Well, I think the only accurate answer to that is "when the estimated cost of a plan using a sort is lower than the estimated cost of any alternatives". There are cases where you can be sure a sort will be used, like when you have an ORDER BY clause and there is no index which can scan rows in that order; but there are a lot of situations where plans which involve sorts are in competition with plans which don't. The plan chosen can depend on such things as how bloated your table is, how close the order of the tuples in the heap corresponds to the order of a particular index, how many rows are in which tables, what work_mem is set to, etc. Are your really looking to categorize the types of queries where sorting is *invoked*, or the ones where it is *considered*? Or perhaps only those where it is *required*, since there are no possible plans without sorting? -Kevin -- 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 Index Advisor related hooks
Looks like the function get_actual_variable_range() was written with the
knowledge that virtual/hypothetical indexes may exist, but the assumption
seems wrong.
One one hand get_actual_variable_range() expects that virtual indexes do not
have an OID assigned, on the other hand explain_get_index_name_hook() is
handed just an index's OID to get its name back; IMHO these are based on two
conflicting assumptions about whether a virtual index will have an OID
assigned.
Attached patch fix_get_actual_variable_range.patch tries to fix this by
introducing a new hook that can help Postgres decide if an index is
fictitious or not.
Also attached is the patch expose_IndexSupportInitialize.patch, that makes
the static function IndexSupportInitialize() global so that the Index
Advisor doesn't have to reinvent the wheel to prepare an index structure
with opfamilies and opclasses.
Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c
index e24e718..609182e 100644
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -45,6 +45,7 @@ int constraint_exclusion = CONSTRAINT_EXCLUSION_PARTITION;
/* Hook for plugins to get control in get_relation_info() */
get_relation_info_hook_type get_relation_info_hook = NULL;
+is_fictitious_index_hook_type is_fictitious_index_hook = NULL;
static List *get_relation_constraints(PlannerInfo *root,
Oid relationObjectId, RelOptInfo *rel,
diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index c837fb6..57ee37c 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -4561,7 +4561,7 @@ get_actual_variable_range(PlannerInfo *root, VariableStatData *vardata,
* The index list might include fictitious indexes inserted by a
* get_relation_info hook --- don't try to access them.
*/
- if (!OidIsValid(index->indexoid))
+ if (is_fictitious_index_hook && (*is_fictitious_index_hook) (index->indexoid))
continue;
/*
diff --git a/src/include/optimizer/plancat.h b/src/include/optimizer/plancat.h
index 9316c9e..050cce0 100644
--- a/src/include/optimizer/plancat.h
+++ b/src/include/optimizer/plancat.h
@@ -24,6 +24,9 @@ typedef void (*get_relation_info_hook_type) (PlannerInfo *root,
RelOptInfo *rel);
extern PGDLLIMPORT get_relation_info_hook_type get_relation_info_hook;
+typedef bool (*is_fictitious_index_hook_type) (Oid index_oid);
+
+extern PGDLLIMPORT is_fictitious_index_hook_type is_fictitious_index_hook;
extern void get_relation_info(PlannerInfo *root, Oid relationObjectId,
bool inhparent, RelOptInfo *rel);
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c
index 43549c2..f78503f 100644
--- a/src/backend/utils/cache/relcache.c
+++ b/src/backend/utils/cache/relcache.c
@@ -233,14 +233,6 @@ static TupleDesc GetPgIndexDescriptor(void);
static void AttrDefaultFetch(Relation relation);
static void CheckConstraintFetch(Relation relation);
static List *insert_ordered_oid(List *list, Oid datum);
-static void IndexSupportInitialize(oidvector *indclass,
- Oid *indexOperator,
- RegProcedure *indexSupport,
- Oid *opFamily,
- Oid *opcInType,
- StrategyNumber maxStrategyNumber,
- StrategyNumber maxSupportNumber,
- AttrNumber maxAttributeNumber);
static OpClassCacheEnt *LookupOpclassInfo(Oid operatorClassOid,
StrategyNumber numStrats,
StrategyNumber numSupport);
@@ -1140,7 +1132,7 @@ RelationInitIndexAccessInfo(Relation relation)
* those obtainable from the system catalog entries for the index and
* access method.
*/
-static void
+void
IndexSupportInitialize(oidvector *indclass,
Oid *indexOperator,
RegProcedure *indexSupport,
diff --git a/src/include/utils/relcache.h b/src/include/utils/relcache.h
index 5314fc2..3984296 100644
--- a/src/include/utils/relcache.h
+++ b/src/include/utils/relcache.h
@@ -14,6 +14,7 @@
#ifndef RELCACHE_H
#define RELCACHE_H
+#include "access/skey.h"/* for StrategyNumber */
#include "access/tupdesc.h"
#include "nodes/bitmapset.h"
#include "nodes/pg_list.h"
@@ -109,4 +110,14 @@ extern bool criticalRelcachesBuilt;
/* should be used only by relcache.c and postinit.c */
extern bool criticalSharedRelcachesBuilt;
+/* Exposed as a global for the benefit of Index Advisor. */
+extern void IndexSupportInitialize(oidvector *indclass,
+ Oid *indexOperator,
+ RegProcedure *indexSupport,
+ Oid *opFamily,
+ Oid *opcInType,
+ StrategyNumber maxStrategyNumber,
+ StrategyNumber maxSupportNumber,
+ AttrNumber maxAttributeNumber);
+
#endif /* RELCACHE_H */
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Re: [HACKERS] Range Types: empty ranges
On Fri, 2011-02-11 at 15:14 -0500, Robert Haas wrote: > On Fri, Feb 11, 2011 at 3:03 PM, Jeff Davis wrote: > > Well, there is a certain amount of localized clarity, I will agree with > > that. The complexity comes when you accidentally rely on some > > transformation which seems logically sound, but could result in a > > transient empty range, which then throws an error. > > But by this argument you also need to support discontiguous ranges, don't you? > > I mean, if you want to insist that A intersect B has to still be a > legal range, what about A union B? > I responded to a similar question/point here: http://archives.postgresql.org/pgsql-hackers/2011-02/msg01073.php Regards, Jeff Davis -- 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] ALTER EXTENSION UPGRADE, v3
Tom Lane writes: > I think it'd likely be sufficient to bump them only once per release > cycle, ie, there's no need to distinguish versions that never appeared > in the wild. But if we forgot and created 1.1 early in the 9.2 release > cycle and 1.2 late in the cycle, there's no great harm done either. > What I don't want to be doing is creating artificial version bumps with > empty upgrade scripts in every release cycle --- that's make-work for > us, and make-work for our users too. I would favor different release cycles for extensions than for the core product. It's a technical fact that a single extension source can and do support more than one major core version. And as soon as the code is maintained, next extension release would happen at next minor upgrade release. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Replication server timeout patch
Hello list,
I split this out of the synchronous replication patch for independent
review. I'm dashing out the door, so I haven't put it on the CF yet or
anything, but I just wanted to get it out there...I'll be around in
Not Too Long to finish any other details.
--
fdr
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 2121,2126 SET ENABLE_SEQSCAN TO OFF;
--- 2121,2140
+
+ replication_timeout_server (integer)
+
+replication_timeout_server configuration parameter
+
+
+
+ If the primary server does not receive a reply from a standby server
+ within replication_timeout_server seconds then the
+ primary will terminate the replication connection.
+
+
+
+
*** a/src/backend/replication/walsender.c
--- b/src/backend/replication/walsender.c
***
*** 73,78 bool am_walsender = false; /* Am I a walsender process ? */
--- 73,80
/* User-settable parameters for walsender */
int max_wal_senders = 0; /* the maximum number of concurrent walsenders */
int WalSndDelay = 200; /* max sleep time between some actions */
+ int replication_timeout_server; /* If the receiver takes too long, time
+ * out and die after this duration */
/*
* These variables are used similarly to openLogFile/Id/Seg/Off,
***
*** 89,94 static uint32 sendOff = 0;
--- 91,99
*/
static XLogRecPtr sentPtr = {0, 0};
+ /* Remembers the last time the standby has notified the primary of progress */
+ static TimestampTz last_reply_timestamp;
+
/* Flags set by signal handlers for later service in main loop */
static volatile sig_atomic_t got_SIGHUP = false;
volatile sig_atomic_t walsender_shutdown_requested = false;
***
*** 250,255 WalSndHandshake(void)
--- 255,265
errmsg("invalid standby handshake message type %d", firstchar)));
}
}
+
+ /*
+ * Initialize our timeout checking mechanism.
+ */
+ last_reply_timestamp = GetCurrentTimestamp();
}
/*
***
*** 616,632 WalSndLoop(void)
if (!XLogSend(output_message, &caughtup))
break;
! if (caughtup && !got_SIGHUP && !walsender_ready_to_stop && !walsender_shutdown_requested)
{
! /*
! * XXX: We don't really need the periodic wakeups anymore,
! * WaitLatchOrSocket should reliably wake up as soon as
! * something interesting happens.
! */
/* Sleep */
! WaitLatchOrSocket(&MyWalSnd->latch, MyProcPort->sock,
! WalSndDelay * 1000L);
}
}
else
--- 626,650
if (!XLogSend(output_message, &caughtup))
break;
! if (caughtup && !got_SIGHUP && !walsender_ready_to_stop &&
! !walsender_shutdown_requested)
{
! long timeout;
!
! if (replication_timeout_server == -1)
! timeout = -1L;
! else
! timeout = 100L * replication_timeout_server;
/* Sleep */
! if (WaitLatchOrSocket(&MyWalSnd->latch, MyProcPort->sock,
! timeout) == 0)
! {
! ereport(LOG,
! (errmsg("streaming replication timeout after %d s",
! replication_timeout_server)));
! break;
! }
}
}
else
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
***
*** 1484,1489 static struct config_int ConfigureNamesInt[] =
--- 1484,1499
},
{
+ {"replication_timeout_server", PGC_SIGHUP, WAL_SETTINGS,
+ gettext_noop("Replication connection will timeout after this duration."),
+ NULL,
+ GUC_UNIT_S
+ },
+ &replication_timeout_server,
+ 30, -1, INT_MAX, NULL, NULL
+ },
+
+ {
{"temp_buffers", PGC_USERSET, RESOURCES_MEM,
gettext_noop("Sets the maximum number of temporary buffers used by each session."),
NULL,
*** a/src/backend/utils/misc/postgresql.conf.sample
--- b/src/backend/utils/misc/postgresql.conf.sample
***
*** 203,208
--- 203,209
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_status_interval = 10s # replies at least this often, 0 disables
+ #replication_timeout_server = 120 # -1 means wait forever
#--
*** a/src/include/replication/walsender.h
--- b/src/include/replication/walsender.h
***
*** 70,75 extern volatile sig_atomic_t walsender_ready_to_stop;
--- 70,76
/* user-settable parameters */
extern int WalSndDelay;
extern int max_wal_senders;
+ extern int replication_timeout_server;
extern int WalSenderMain(void);
extern void WalSndSignals(void);
--
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] Range Types: empty ranges
On Fri, 2011-02-11 at 14:19 -0600, Kevin Grittner wrote: > Well, in the receipt number example there are multiple ranges in use > for each year, and ranges for multiple years. If we get to the idea > of a multi-ranges, this would be very handy for certain types of > reports -- especially for auditors. It's not that we can't do with > with discrete begin and end columns -- we do that now; but it seemed > a potentially beneficial use of ranges for us, if they can represent > the needed states. People already talk about these as ranges, just > in terms of the common English understanding of the word. I think that might indicate that the word "range" is a little too loose. The definition that I've been using is more like a mathematical interval. > Perhaps it was a mistake to get so concrete rather than conceptual > -- basically, it seems like it could be a useful concept for any > planned or scheduled range with an indeterminate end point, which > you want to "reserve" up front and record in progress until > complete. Maybe this is a range... would it be served by: (5, INF) or: [5, INF) ? That's already supported, and it means "all points greater than 5". > Of course, the *most* useful places for our shop to have ranges are > temporal. Many (most?) of those are situations where you start with > a range with an unknown end and later (often years later) fill in > the end of the range based on some event which finally closes it. > Again, two discreet dates with a null-capable end-date work, but I > can see where ranges could potentially be more powerful. Ranges support infinite boundaries, but do not support NULL (previous discussion concluded that NULL boundaries were likely to be confusing and served no obvious use case not handled by infinity). Regards, Jeff Davis -- 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] ALTER EXTENSION UPGRADE, v3
Dimitri Fontaine writes: > Tom Lane writes: >> I don't see that this proposal changes anything about that. It's still >> the case that the underlying .so is tied to a major PG version. What >> you'll ship is a control file and assorted .sql files that represent the >> user APIs you are interested in supporting on that major PG version. > That's why I proposed that the require control field would contain the > PostgreSQL release against which the extension is built. > require = 'postgresql-9.0' I don't see what that does for you. This is still all being examined by a particular major release of PG, so what will it do with a require that specifies some other major release? Nothing useful. And there's a very significant downside, which is that this takes us right back to the make-work of having to change all the contrib modules' control files in every release cycle. Once again, I see the version numbers as being specifiers for versions of the install script files. Not the Postgres version those files are being run in. Confusing the two is a bad idea. Confusing the install script version numbers with minor release numbers (bugfix level identifiers) is even worse. You *don't* want to change these numbers if you're just fixing a bug at the C code level. 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] ALTER EXTENSION UPGRADE, v3
Tom Lane writes: > Dimitri Fontaine writes: >> Will we have to provide different upgrade scripts for different past >> major versions of PostgreSQL? If so, I would say "9.0" or "8.4" would >> be better names. hstore at least is an example that would need this >> treatment I guess. > > I don't foresee us bothering with that. We will only be trying to > upgrade installations that got to 9.1 legitimately. Shops that upgrade at each new releases are the exception, not the rule. Very few people will have the luxury of upgrading their production from 9.0 to 9.1, most will jump right from 8.3 or 8.4 straight to 9.1. Don't we want to support them, or I am not understanding your words? > I should also make clear that I intend to start out all the contrib > modules at version 1.0. *NOT* 9.1. These things are going to get > version number bumps only when the contents of their install scripts > change, not whenever the surrounding database changes version. If we > number them at 9.1 to start with, it will just promote confusion. Agreed. But we don't have any sorting, so upgrading from 8.4 to 1.0 is no problem for us. Just apply the hstore:8.4:1.0.sql script. I don't see wrapping back up to 8.4 happening soon enough for us to regret it, we won't ship hstore with upgrade support from 8.4-pre-extensions to 8.4-wrapped, will we? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] Sorting. When?
Nicolas, thanks. Unfortunately I don't think I can get precise infos from that link. That "explains" how the EXPLAIN works, while I need to know, from an algorithmic point of view, in which cases sorting is invoked. Actually, maybe I can spend some time in trying to perform samples queries and trying to deduce which operations calls the sorting module. But I think it is not the most effective way to do that, since that would mean running a bounch of queries for different values of work_mem, or for different size of the involved tables. Even if I try to do that, some cases can not be evident to my sight. I am searching for someone telling me (how to get) a list of operations invoking sorting, and in which cases they do that. Just for example: - ORDER BY, always invokes sorting. - DISTINCT, always invokes sorting - Merge Join, just in case (..bla bla bla..) - ... Is it possible? Any other suggestion? Thanks for your time. Best regards. Fava Il 11/02/2011 11:50, Nicolas Barbier ha scritto: [ Please don't top-post.http://en.wikipedia.org/wiki/Posting_style> ] 2011/2/11 mac_man2...@yahoo.it: So, is there any precise way to discover when sorting is invoked? EXPLAIN shows how a query would be executed; explicit sorts should be mostly obvious. http://www.postgresql.org/docs/9.0/static/sql-explain.html> Nicolas -- 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] Debian readline/libedit breakage
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > We have code that exists in both psql and the backend (cf src/port/) > so I'm not sure this really will satisfy the more rabid GPL partisans. We're talking Debian, who, yes, are a bit pickier when it comes to trying to actually follow the licneses they release, but they're also technically competent. I expect the answer would depend on if the backend process links against both readline and openssl or not. > And this whole discussion is about satisfying the most rabid of them, > remember. I don't really think that anything other than "relicense all > of Postgres as GPL" will make them happy. Of course, relicensing it under the GPL wouldn't actually help this situation, at all, nor has anyone brought it up that I'm aware of.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
Aidan Van Dyk writes: > So, I like that the attempt is to support multiple versions. But > unless you can manage the files (both shared libraries, and any > scripts to create/update SQL objects) for different version > independently, I can't see the "multiple versions at once" capabilites > that are being discussed being actually being used by anything more > than the most basic extensions... No, you're missing the use case here I think. It's all about releasing minor upgrades (of extensions) and allowing users to jump through more than one of them at a time. Like upgrading from 1.1.0 to 1.3.5. > Just like if I need a bugfix of PostgreSQL 8.4, I'm not forced to > *install* 9.0, because PG has decide that the proper way to release > ist o make a single release of all versions. If you have extension which needs multiple major version releases, then yes, as PostgreSQL packages, you need to put the extension major version number into its name. I don't see that as a problem of the mechanisms proposed here. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] ALTER EXTENSION UPGRADE, v3
Tom Lane writes: > I don't see that this proposal changes anything about that. It's still > the case that the underlying .so is tied to a major PG version. What > you'll ship is a control file and assorted .sql files that represent the > user APIs you are interested in supporting on that major PG version. That's why I proposed that the require control field would contain the PostgreSQL release against which the extension is built. require = 'postgresql-9.0' Then, we have to separate multi-major version support, that almost all extensions have, with extension release schedule and extension new major versions. My proposal here was to distinguish between a "support" update and a "stable" update, so that users are warned and helped somehow. Other than that, I don't see any reason not to rename the extension in such cases, like we have postgis-1.4 and postgis-1.5. That's also another good reason not to use dash as a version separator in upgrade scripts, too. Note that debian uses the semicolon to represent epoch, as a way to fix upgrades that break their sorting rules. But we don't have no sorting rules. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] Debian readline/libedit breakage
Robert Haas writes: > On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane wrote: >> We have code that exists in both psql and the backend (cf src/port/) >> so I'm not sure this really will satisfy the more rabid GPL partisans. >> And this whole discussion is about satisfying the most rabid of them, >> remember. I don't really think that anything other than "relicense all >> of Postgres as GPL" will make them happy. > Which, by the way, *no one* has the authority to do. Right. So the long term solution in my mind is to migrate away from readline and towards libedit. I'm just not sufficiently worried about this to put any of my own cycles into making libedit good enough. 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] Debian readline/libedit breakage
* charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote: > Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 > compliance is essential to many Federal users. Essential? That's a bit much. Yes, it shows up on a FISMA review as an open action item, but it's a risk that can both be accepted and mitigated. I also thought FIPS-140 version required API changes.. > GnuTLS doesn't qualify. That should be "doesn't currently".. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Debian readline/libedit breakage
If psql uses libreadline and libgnutls, does that mean psql will be distributed under the GPL in the future? Or Dual-licensed? If I read the readline license right, applications that link to it must be GPL. That's why we (EMC/Greenplum) switch to libedit, even though readline is nicer... We didn't want to ship part of our product as GPL -- 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] ALTER EXTENSION UPGRADE, v3
Robert Haas writes: > On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane wrote: >> I should also make clear that I intend to start out all the contrib >> modules at version 1.0. > What happens if their contents change several times during a major > release cycle? I think it'd likely be sufficient to bump them only once per release cycle, ie, there's no need to distinguish versions that never appeared in the wild. But if we forgot and created 1.1 early in the 9.2 release cycle and 1.2 late in the cycle, there's no great harm done either. What I don't want to be doing is creating artificial version bumps with empty upgrade scripts in every release cycle --- that's make-work for us, and make-work for our users too. 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] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 3:10 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Why do we have to involve the whole of PostgreSQL? Since the only piece >> that links to libreadline is psql, perhaps we could fix this by having >> only psql optionally use GnuTLS. > > We have code that exists in both psql and the backend (cf src/port/) > so I'm not sure this really will satisfy the more rabid GPL partisans. > And this whole discussion is about satisfying the most rabid of them, > remember. I don't really think that anything other than "relicense all > of Postgres as GPL" will make them happy. Which, by the way, *no one* has the authority to do. -- 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] ALTER EXTENSION UPGRADE, v3
On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane wrote: > Dimitri Fontaine writes: >> Tom Lane writes: >>> However, we're going to have to make a choice for the contrib modules, >>> and I'll bet lunch that most people will follow whatever precedent we >>> set with those. I was thinking about using either "old" or "unpackaged". >>> Thoughts? > >> Will we have to provide different upgrade scripts for different past >> major versions of PostgreSQL? If so, I would say "9.0" or "8.4" would >> be better names. hstore at least is an example that would need this >> treatment I guess. > > I don't foresee us bothering with that. We will only be trying to > upgrade installations that got to 9.1 legitimately. > > I should also make clear that I intend to start out all the contrib > modules at version 1.0. *NOT* 9.1. These things are going to get > version number bumps only when the contents of their install scripts > change, not whenever the surrounding database changes version. If we > number them at 9.1 to start with, it will just promote confusion. What happens if their contents change several times during a major release cycle? -- 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] Range Types: empty ranges
Jeff Davis wrote: > Trying to incorporate a "start value" is adding extra information > in there, and it's not really a part of the same algebra. It > sounds more like a contiguous sequence with a "start value" and a > "current value" to me. Well, in the receipt number example there are multiple ranges in use for each year, and ranges for multiple years. If we get to the idea of a multi-ranges, this would be very handy for certain types of reports -- especially for auditors. It's not that we can't do with with discrete begin and end columns -- we do that now; but it seemed a potentially beneficial use of ranges for us, if they can represent the needed states. People already talk about these as ranges, just in terms of the common English understanding of the word. Perhaps it was a mistake to get so concrete rather than conceptual -- basically, it seems like it could be a useful concept for any planned or scheduled range with an indeterminate end point, which you want to "reserve" up front and record in progress until complete. The alternative would be that such "ranges to be" have a parallel "planned start value" column of the same type as the range, to be used as the start of the range once it is not empty. Or, as another way to put it, it seems potentially useful to me to have an empty range which is pinned to a location, in *addition* to the unpinned empty ranges such as would be needed to represent the intersection of two non-overlapping ranges. Of course, the *most* useful places for our shop to have ranges are temporal. Many (most?) of those are situations where you start with a range with an unknown end and later (often years later) fill in the end of the range based on some event which finally closes it. Again, two discreet dates with a null-capable end-date work, but I can see where ranges could potentially be more powerful. -Kevin -- 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] ALTER EXTENSION UPGRADE, v3
Tom Lane writes: > OK, let me see if I can summarize what I think we've agreed to: > > CREATE syntax is extended to > > CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv] Agreed. > If VERSION is not specified, v is taken from default_version in the > control file, or fail if that's not given either. We create the > pg_extension entry and then run the script extname-v.sql, or > extname-oldv-v.sql if FROM is present. Check. > ALTER syntax is extended with > > ALTER EXTENSION extname UPDATE [TO v] > > Again, if v is not specified, it is taken from default_version in the > control file, or fail if that's not given either. Here we take oldv > from the current pg_extension.extversion field, and then run the script > extname-oldv-v.sql. Well I don't think it's the same default, but I'm in the minority, so you got your votes here already. Just for the record and summary. > We will add logic to find a chain of update scripts leading from oldv to > v, in case that exact combination is not available in the extension's > script directory. (NOTE: maybe in the CREATE ... FROM case, it would be > a better idea to not do that search, but insist on finding exactly > extname-oldv-v.sql? That would provide at least a little bit of extra > protection against wrong FROM choice. Not sure how much it helps > though.) Chaining in all cases is better. Less documentation, less code, less burden on authors. Better :) > Version identifiers will be ColId_or_Sconst in the grammar, ie, you can > omit quotes if they're valid SQL identifiers. I'm not sure this helps > with typical choices of version strings, but we might as well allow it. That allows to get prepared for version aliases if we ever get there too. Good. > Version strings will have no hard-wired semantics except equality; we > don't need a sorting rule. We must however forbid "-" in version > strings, to avoid ambiguity as to whether a file name represents an > install or upgrade script. (Note: "-" in extension names poses a > hazard as well; not within a single extension, but for example > foo-bar's install scripts could be confused with foo's upgrade > scripts. However, I think we need not forbid "-" in extension names > since this risk can be avoided by giving foo-bar its own script > directory.) It also seems to me to be a good idea to forbid ".." and > directory separators in both types of names, because otherwise CREATE > EXTENSION could be used to probe the file system. That's not really an > issue right now, with use of the command being restricted to superusers > anyway, but it's inevitable that we'll want to relax that restriction. Check. We could use : as the version separator too. > We will also add code to allow per-version control files > extname-v.control in the script directory. After determining the > version we plan to install or update to, we read the per-version control > file if any, and let it override parameters from the primary control > file. (This implies for example that a per-version control file's > encoding setting would control all update scripts read while trying to > get to that version. I'm not sure how useful that is --- given the > chaining behavior, really you're going to have to use the same encoding > throughout the extension's update files. Maybe better to disallow > encoding in per-version control files?) I would think that if we have the extname-v.control facility, which I think we must have, we should check for this file at each steps of the chain, and override each time. Encodings are not what I'm worried about here, 'required' is. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] ALTER EXTENSION UPGRADE, v3
Dimitri Fontaine writes: > Tom Lane writes: >> However, we're going to have to make a choice for the contrib modules, >> and I'll bet lunch that most people will follow whatever precedent we >> set with those. I was thinking about using either "old" or "unpackaged". >> Thoughts? > Will we have to provide different upgrade scripts for different past > major versions of PostgreSQL? If so, I would say "9.0" or "8.4" would > be better names. hstore at least is an example that would need this > treatment I guess. I don't foresee us bothering with that. We will only be trying to upgrade installations that got to 9.1 legitimately. I should also make clear that I intend to start out all the contrib modules at version 1.0. *NOT* 9.1. These things are going to get version number bumps only when the contents of their install scripts change, not whenever the surrounding database changes version. If we number them at 9.1 to start with, it will just promote confusion. 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] Range Types: empty ranges
On Fri, Feb 11, 2011 at 3:03 PM, Jeff Davis wrote: > Well, there is a certain amount of localized clarity, I will agree with > that. The complexity comes when you accidentally rely on some > transformation which seems logically sound, but could result in a > transient empty range, which then throws an error. But by this argument you also need to support discontiguous ranges, don't you? I mean, if you want to insist that A intersect B has to still be a legal range, what about A union B? -- 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] Range Types: empty ranges
On Fri, 2011-02-11 at 14:14 -0500, Robert Haas wrote: > > It's really that it has nice mathematical properties coming from set > > theory. Take the distributive law: > > > > A UNION (B INTERSECT C) = (A UNION B) INTERSECT (A UNION C) > > But the basic range type isn't even closed under UNION. An excellent point. Allow me to move the target a little: WHERE A && B AND A && C and: WHERE A && (B INTERSECT C) That seems like a logically sound transformation, but if (B INTERSECT C) is empty, it relies on the empty range for those two to be equivalent. And that would be a runtime error, caught during testing only if you're lucky. Now, I agree that lack of closure on UNION exhibits many of the problems that I am pointing out related to forbidding empty ranges. However, I'm not sure if that means we should give up on either. Regards, Jeff Davis -- 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] Replication server timeout patch
On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote: > I split this out of the synchronous replication patch for independent > review. I'm dashing out the door, so I haven't put it on the CF yet or > anything, but I just wanted to get it out there...I'll be around in > Not Too Long to finish any other details. This looks like a useful and separately committable change. However, it looks to me like this renders wal_sender_delay aka WalSndDelay completely unused. If we don't need that GUC any more, we should rip it out completely. The comment in WalSndHandshake should have a tab at the beginning of every line. Right now the first line has a tab and the rest have spaces. The first hunk in WalSndLoop is a meaningless whitespace change. I wonder if we ought to just call this replication_timeout, rather than replication_timeout_server. Simon's patch (from which this extracted) also has replication_timeout_client, but the two aren't symmetrical. The replication_timeout_client in this patch is the amount of time after which the master acknowledges the commit even though the synchronous standby hasn't acked yet. So it only applies to the synchronous replication case, whereas this is useful for both synchronous and asynchronous replication. I'm inclined to think that knob is utterly useless anyway; surely waiting more than zero will reduce the throughput of the system to some minute fraction of its normal value, while waiting less than infinity throws out the data guarantee that made you pick synchronous replication in the first place. Even if we do decide to keep that knob, I don't think we'll want the value to be symmetric with this one. -- 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] Debian readline/libedit breakage
Alvaro Herrera writes: > Why do we have to involve the whole of PostgreSQL? Since the only piece > that links to libreadline is psql, perhaps we could fix this by having > only psql optionally use GnuTLS. We have code that exists in both psql and the backend (cf src/port/) so I'm not sure this really will satisfy the more rabid GPL partisans. And this whole discussion is about satisfying the most rabid of them, remember. I don't really think that anything other than "relicense all of Postgres as GPL" will make them happy. 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] Debian readline/libedit breakage
Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140 compliance is essential to many Federal users. GnuTLS doesn't qualify. -- 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] ALTER EXTENSION UPGRADE, v3
"David E. Wheeler" writes: > On Feb 11, 2011, at 11:50 AM, Dimitri Fontaine wrote: >> It would be good to avoid regexp and globing pattern characters, I would >> say. >> >> There's the coma, as in "foo,1.0,1.1.sql", so ugly that it's unused :) I >> wonder if : would be good? "foo:1.0:1.1.sql". A very quick test seems >> to show that macosx is ok with that scheme. > I like comma and :. The latter is used on Mac OS classic, so I don't think > that's an issue. Does PostgreSQL run on VMS? Uh ... colon is a special character in Windows filenames still, no? 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] Debian readline/libedit breakage
Greg, * Greg Smith (g...@2ndquadrant.com) wrote: > Note that the past discussion was on the difficulty of matching the > existing OpenSSL API using GnuTLS, which is apparently difficult to > do. Oh, yes, that's more a reflection on the crappy API that OpenSSL has than on anything else, in my view... > I wasn't trying to suggest there were issues specificially with > GnuTLS's code quality. Ah, I'm glad to hear that. > You'd think there'd be a simple "OpenSSL-like" interface available > for GnuTLS by now or something. There is, but it was written by Steve Langasek (as I recall...) for when this was done for OpenLDAP and was licensed under the GPL (and, yes, I did bitch at him about this... Didn't help. :/). I'm not sure if that compatability layer would work (in terms of being acceptable by core) for PG in any case tho. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
On Fri, Feb 11, 2011 at 7:49 PM, Tom Lane wrote: > If you were expecting this proposal to make things easier as far as > dealing with multiple major releases, sorry, our ambitions don't extend > that far yet. Sorry, I might have been confusing here... I'm not talking about *PG* major releases. I'm talking about "major release" of my extensions. So, assoming I only care about PG 9.1, but I have afoo-1.x and afoo-2.x that I develop and release (much like PostgreSQL has 8.4.x and 9.0.x it releases), I want to be able to provide a bug-fix of my afoo-1.x extension, and not require that for them to get that bug fix, they also need to get the latest 2.x installed as well (which may or may not be in use elsewhere in the cluster, or by a 2nd cluster on the same machine). Or, similarly, if I have a "master" type branch of an extension in use in my qa DB, upgrading it requires forcing an upgrade of the old 8.4 branch extension in use in my prod database, simply because the extension infrastructure has forced extension authors to only be able to release a single "extension" that alwyas packages the lastest of all back branches... Of course, it won't, because just like the RPM/DPKG situation, packagers are going to put the "major version" number into the extension name to avoid that. So, I like that the attempt is to support multiple versions. But unless you can manage the files (both shared libraries, and any scripts to create/update SQL objects) for different version independently, I can't see the "multiple versions at once" capabilites that are being discussed being actually being used by anything more than the most basic extensions... Just like if I need a bugfix of PostgreSQL 8.4, I'm not forced to *install* 9.0, because PG has decide that the proper way to release ist o make a single release of all versions. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- 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] Debian readline/libedit breakage
On Fri, 2011-02-11 at 14:59 -0500, charles.mcdev...@emc.com wrote: > If psql uses libreadline and libgnutls, does that mean psql will be > distributed under the GPL in the future? Or Dual-licensed? libgnutls is libgpl, not GPL, so this is not a problem. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- 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] Range Types: empty ranges
On Fri, 2011-02-11 at 13:50 -0500, Robert Haas wrote: > On Fri, Feb 11, 2011 at 1:11 PM, Jeff Davis wrote: > > Similarly, "intersection" of ranges is somewhat analogous to > > multiplication of numbers. > > I had a feeling that we might be going in this direction. It strikes > me that this case is a bit like division by zero. Except that we do happen to allow the value zero and wait 'til someone divides by it before throwing an error. So I think that's more of a point toward allowing empty ranges than rejecting them. > It's kind of a > nuisance that dividing by zero throws an error and we COULD fix that > by making it return NULL or NaN or some new distinguished value DbZ. But empty ranges are actually quite well-defined, in a way similar to an empty set. * it can meaningfully result in a non-empty range at a later stage of computation * it increases the number of tautologies, rather than decreasing them like NULL I guess what I'm saying is that DbZ doesn't seem particularly useful to carry along, while and empty range plausibly is. > But then we'd have to define what happens when you feed DbZ into every > other operation in the system, and similarly here. If your point is that empty ranges need to be handled specially sometimes, I agree. That is the semantic cost which I identified in the original email. Are the benefits worth it? > If we define two > non-overlapping ranges as intersecting to NULL, or as throwing an > error, then everything else is clear after that. Well, there is a certain amount of localized clarity, I will agree with that. The complexity comes when you accidentally rely on some transformation which seems logically sound, but could result in a transient empty range, which then throws an error. Regards, Jeff Davis -- 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] multiset patch review
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> I will remove parser changes from the patch; it will add only a few array
> functions. Then, please let me know functions you don't want to include
> in the core, if any. I'll remove them at the same time.
Seems like this should be 'waiting on author', but since it was marked
'needs review', I started taking a look at it. Without the grammar
changes, it's just adding a couple of functions. In general, I'm all
for that, but I don't like this:
Input arrays are always flattened into one-dimensional arrays.
That just strikes me as completely broken when it comes to PG Arrays.
What does the spec say about this, if anything? Is that required by
spec, or is the spec not relevant to this because MULTISETs are only one
dimensional..?
I would think that we would have a way to define what dimension or piece
of the array that would be sorted or returned as a set, etc. I could
see having a 'flatten' function which could be called first, if that's
really what you want.. Or maybe we just need a slice function whose
result could then be passed in to these functions, perhaps..
In my view, we should be throwing an error if we get called on a
multi-dim array and we can't perform the operation on that in an
obviously correct way, not forcing the input to match something we can
make work.
From above, that makes me not thrilled with the 'flatten' boolean for
array_cat_internal(), nor with how it was implemented, or how those
changes apparently didn't justfiy *any* comment updates..
I'm not thrilled with called ArrayGetNItems array_cardinality(). Why
not just provide a function with a name like "array_getnitems()"
instead?
trim_array() suffers from two problems: lack of comments, and no spell
checking done on those that are there.
Should get_type_cache() really live in array_userfuncs.c ?
There's more, primairly lack of comments and what I consider poor
function naming ("sort_or_unique()" ? really?), but in the end my
feeling is that this could survive just fine, for now, as a contrib
module, and that it really isn't close enough to being committable to
make it into 9.1 in any case.
I'll mark it waiting on author, since I think the formal 'returned with
feedback' needs to come from someone else, but that's where I think this
is headed.
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: [HACKERS] Range Types: empty ranges
On Feb 11, 2011, at 10:28 AM, Josh Berkus wrote: > So, if we allow empty ranges of this kind, I would want a GUC for > "allow_empty_ranges". GUC you, josh. ;-P D -- 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] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 11:49 AM, Alvaro Herrera wrote: > Why do we have to involve the whole of PostgreSQL? Since the only piece > that links to libreadline is psql, perhaps we could fix this by having > only psql optionally use GnuTLS. (I don't know if you can make an > OpenSSL server talk to a GnuTLS client -- are these things supposed to > be interoperable?) I agree with this: barring shockingly convenient engineering details, my plan was to just evaluate the option of doing this for the psql client. -- fdr -- 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] ALTER EXTENSION UPGRADE, v3
On Feb 11, 2011, at 11:50 AM, Dimitri Fontaine wrote: > It would be good to avoid regexp and globing pattern characters, I would > say. > > There's the coma, as in "foo,1.0,1.1.sql", so ugly that it's unused :) I > wonder if : would be good? "foo:1.0:1.1.sql". A very quick test seems > to show that macosx is ok with that scheme. I like comma and :. The latter is used on Mac OS classic, so I don't think that's an issue. Does PostgreSQL run on VMS? Best, David -- 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] ALTER EXTENSION UPGRADE, v3
Tom Lane writes: > In principle we are leaving it to the extension author to choose that. Most extensions already have a version number. ip4r is 1.05, prefix is 1.1.0, dbi-link is 2.0.0, temporal is 20091213, tablelog is 0.4.4, etc. All those extensions will need a newer 'extension' release to ship with the control file, at least. So those are some of the old version numbers that we will find. > However, we're going to have to make a choice for the contrib modules, > and I'll bet lunch that most people will follow whatever precedent we > set with those. I was thinking about using either "old" or "unpackaged". > Thoughts? Will we have to provide different upgrade scripts for different past major versions of PostgreSQL? If so, I would say "9.0" or "8.4" would be better names. hstore at least is an example that would need this treatment I guess. Now we could trick and prepend a "0." so that it's easy to break the old version naming system and get to use a proper per-extension numbering here. That would mean that core provided extension could have a different release cycle than the core product. Do we want that? Thinking about that, maybe what we want to do with contrib is separate that in several directories, like e.g. "examples", "extensions", "tools" and such. Tools would fit contribs that do not ship with SQL level support, like pg_archivecleanup or pg_standby and some others. Each time contrib quality is talked about we're explained that most of them are examples only, not production ready quality code, hence my proposal. > It can be specified by a "directory" parameter in the control file, > and defaults to the same place the control file is. Right now, that's > $PREFIX/share/contrib/. One other thing that ought to be discussed is > whether to stick with that choice or change it. Given that some people > have great antipathy to the word "contrib", I suspect there will be > argument to change it --- but to do so, I think we'd have to change the > default MODULEDIR in PGXS, and I'm not sure that's a good idea. I don't readily grasp the consequences of that. >>> Version strings will have no hard-wired semantics except equality; we >>> don't need a sorting rule. We must however forbid "-" in version >>> strings, to avoid ambiguity as to whether a file name represents an >>> install or upgrade script. > >> Yeah. Might be worth considering using some other less common character as >> the delimiter. Maybe + or ^? not a big deal, though. I guess / should also >> be forbidden, eh? > > I could go with + ... anyone know if that is problematic in filenames on > Windows or elsewhere? It would be good to avoid regexp and globing pattern characters, I would say. There's the coma, as in "foo,1.0,1.1.sql", so ugly that it's unused :) I wonder if : would be good? "foo:1.0:1.1.sql". A very quick test seems to show that macosx is ok with that scheme. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] Debian readline/libedit breakage
Excerpts from Greg Smith's message of vie feb 11 14:51:17 -0300 2011: > So where are we at? > > -GNU libreadine is certainly never going to add an OpenSSL exemption > -If the OpenSSL project was going to switch to a reasonable license, > they'd have done it years ago > -There are many known and serious bugs/limitations in libedit relative > to libreadline > -Adding GnuTLS support to PostgreSQL would require solving several code > quality issues Why do we have to involve the whole of PostgreSQL? Since the only piece that links to libreadline is psql, perhaps we could fix this by having only psql optionally use GnuTLS. (I don't know if you can make an OpenSSL server talk to a GnuTLS client -- are these things supposed to be interoperable?) -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 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] ALTER EXTENSION UPGRADE, v3
Aidan Van Dyk writes: > On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane wrote: >> No, you ship *one* package that supports both 1.1 and 2.0. > Hm... As an example of a project that generally has pretty good > software release practices, I'm glat that the PostgreSQL project > doesn't operate this way. > Having to download/install/upgrade a package with all of pg > 9.1.$lateset and 9.0.$latest just to get a fix for 8.4.$latest would > be a bit of a bummer... I don't see that this proposal changes anything about that. It's still the case that the underlying .so is tied to a major PG version. What you'll ship is a control file and assorted .sql files that represent the user APIs you are interested in supporting on that major PG version. For systems like Debian that support concurrent installation of multiple major PG versions, you would be installing all these files into a version-specific share/ directory. If you don't feel like supporting multiple API versions on a given PG major release, then nothing much changes from the way you packaged stuff before. The only real change is that you have a fairly clean way to package scripts that fix bugs in the extension's catalog entries, which was something that could only be done in a very ad-hoc way before. If you were expecting this proposal to make things easier as far as dealing with multiple major releases, sorry, our ambitions don't extend that far yet. 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] ALTER TYPE 2: skip already-provable no-work rewrites
On Fri, Feb 11, 2011 at 2:17 PM, Noah Misch wrote: > Good to know. I can envision that perspective, and I share it when the > savings > is rather more substantial, say >10% of the patch or >100 lines. Below that > threshold, the energy I expend grasping two interface changes in one patch > series exceeds my annoyance at the premature generality. It's a fair point. One other thing that may be worth mentioning is that you're diving into the community at a fairly high level. It's obvious that you have a pretty solid understanding of the code, better than mine in some areas, and I don't want to be the dumb guy who won't commit your patch because I'm too, like, dumb. OTOH, as you've probably realized, our community dynamic is that the committer is the one who gets yelled at when something is broken. >> Then I'll review that separately. I think this change stands on its >> own, and committing it in steps will be simple for me than doing the >> whole thing in one go. > > That works for me. Know that, barring other suggestions, the followup patch > will replace AlteredTableInfo.rewrite with the enum field. Just want to make > sure that's not a surprise. ... And now that I've read your second reply, I > probably didn't even have to mention it. It's all good. You might want to consider a second boolean in lieu of a three way enum. I'm not sure if that's cleaner but if it lets you write: if (blah) at->verify = true; instead of: if (blah) at->worklevel = Min(at->worklevel, WORK_VERIFY); ...then I think that might be cleaner. -- 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] Range Types: empty ranges
On Fri, 2011-02-11 at 13:08 -0600, Kevin Grittner wrote: > It makes more sense in the context of a range of some type with a > clearly defined granularity. Our accounting system, for example, > can assign a new range of receipt IDs for each calendar year. If > you want a variable to represent the receipts for traffic receipts > for 2012, you might, in preparation for the upcoming year, define > something to declare the range as '[12TR01,12TR01)'. When > the first receipt is assigned as 12TR01, that is updated to > '[12TR01,12TR02)'. Just as an off-the-cuff example. > > Basically, with a type having well-defined granularity, a [) range > could usefully represent, "start to last used", and start out empty. I think this is trying to make a range into something that's not. A range is a set of values with the additional constraint that there are no "gaps". Trying to incorporate a "start value" is adding extra information in there, and it's not really a part of the same algebra. It sounds more like a contiguous sequence with a "start value" and a "current value" to me. Sequences have other useful operations, like "next", and things like "overlaps" don't really seem to make sense (at least not in a practical way that I can tell). Regards, Jeff Davis -- 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] ALTER EXTENSION UPGRADE, v3
On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane wrote: >> This gives my first problem. I can't package afoo-2.x seperately from >> afoo-1.x, because they both want to write the afoo control file. > > No, you ship *one* package that supports both 1.1 and 2.0. Hm... As an example of a project that generally has pretty good software release practices, I'm glat that the PostgreSQL project doesn't operate this way. Having to download/install/upgrade a package with all of pg 9.1.$lateset and 9.0.$latest just to get a fix for 8.4.$latest would be a bit of a bummer... And a hopefull extension author/packages/user, I *want* to be able to release/distribute different versions seperately, just like PostgreSQL does. And I'll do that by packaging my extension with a "major" version in the name, much like the packages for PostgreSQL does. But once I've done that, I don't need the multiple extension versions, all I need is the ability to run $something when I upgrade an extension, once the files under it have been upgraded. ;-) >> But now, let's make it harder. I've found a grave bug in 1.1, which >> causes the PG backend to segfault. Easy fix, good thing, so now I >> release 1.2: > > Unless the bug is such that you have to change the installation script > file, there is no reason to bump the version number at all. These > version numbers apply to the install SQL script, not the underlying .so. Right. If everything is exactly binary compatible and it's just a .so fix, I don't need to. But let's assume something like slonly (or bucardo or longdiste, or PyQ, or PostGIS) start's trying to make use of extensions. I can very much see a "bug fix" minor version upgrade changing things that might need trigers/etc to be altered to take advantage of the fixed way of doing things. Or a SQL view/function had a bug with an null handling joins that needs fixing, etc. Lots of reasons for an "upgrade" to need to change an SQL object. And of course, if I have slony 1.2.$x replicating one of my databases, I'ld love to be able to try slony 2 and have it packaged on my system too to test somethign else. And not have to upgrade my slony 2 instance just to get the critical bugfix for my production slony 1.2$x+1. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- 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] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 2:09 PM, Greg Smith wrote: > Note that the past discussion was on the difficulty of matching the existing > OpenSSL API using GnuTLS, which is apparently difficult to do. I believe that the OpenSSL API is "make some function calls, and if it works, then you're using it right; if not, copy some source code from the examples and use the undocumented APIs that appear there to fix whatever problem you're having." At least, that's been my approach. -- 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] ALTER EXTENSION UPGRADE, v3
On Fri, Feb 11, 2011 at 6:30 PM, Tom Lane wrote: > No --- in the current vision, a control file may describe a whole > collection of versions of the same extension, and the parameter in > question is selecting the default or preferred version to install. > I'm not wedded to "default_version", but I think just plain "version" > is a misnomer. As someone who wants to use extensions and packages (rpm/dpkg) together to distribute PG database pieces, I think this multi-version approach is going to be problematic. Here's why. I release exetension "afoo", initial as version 1.0. From my understanding, it's going to contain: afoo control file, named something particular) - default_version = 1.0 - encoding utf8 foo-1.0.sql installstion script and any requried shared libraries And I now release and updated version 1.1 which fixes a problem. No problem: afoo control file: - default_version = 1.1 - encoding utf8 afoo-1.1.sql installation afoo-upgrade-1.0-1.1.sql upgrade script any required shared libraries for afoo-1. Now, I decide to add some major new changes to my afoo for version 2. I'ld like to package it up: afoo control file - default_version = 2.0 - encoding utf8 afoo-2.0.sql installation afoo-upgrade-1.1-2.0-sql upgrade script Any ne shared libreries for afoo-2. This gives my first problem. I can't package afoo-2.x seperately from afoo-1.x, because they both want to write the afoo control file. RPM/DPKG will cause me grief here. But now, let's make it harder. I've found a grave bug in 1.1, which causes the PG backend to segfault. Easy fix, good thing, so now I release 1.2: afoo control file - default_version = 1.2 - encoding utf8 afoo-1.2.sql installation afoo-upgrade-1.0-1.1.sql upgrade afoo-upgrade-1.1-1.2.sql upgrade any shared libraries for afoo-1 So, this is not a problem for upgrading 1.0/1.1 -> 1.2. But if I have 1.1 on my system, and let's say I forced a 2.0 into the system (telling dpkg/rpm to overwrite the common file), I'm going to do that again here now with 1.2, and my afoo control file will have default_version = 1.2 instead of the 2.0 So, I'm not even working about the in-database side of the multi-versions (alhthough I definately want the ability to have multiple versions in the same database), but we're not even going to be able to get the files onto the system to support multiple versions nicely. So this is going to drive me the same direction the same problem drove packages for rpm/dpkg. I'm going to have to name my extension "afoo-1" and "afoo-2" to be able to have them both co-exist on the filesystem independantly, and at that point, *I* don't need multiple versions of it anymore. I'm going to keep the same extension objects/libraries backwards compatible, and I just need a way to tell PG to run something after I've replaced the shared libraries to perform any upgrade tweeks. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- 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] ALTER EXTENSION UPGRADE, v3
Aidan Van Dyk writes: > And I now release and updated version 1.1 which fixes a problem. No problem: >afoo control file: > - default_version = 1.1 > - encoding utf8 >afoo-1.1.sql installation >afoo-upgrade-1.0-1.1.sql upgrade script >any required shared libraries for afoo-1. > Now, I decide to add some major new changes to my afoo for version 2. > I'ld like to package it up: >afoo control file > - default_version = 2.0 > - encoding utf8 >afoo-2.0.sql installation >afoo-upgrade-1.1-2.0-sql upgrade script >Any ne shared libreries for afoo-2. > This gives my first problem. I can't package afoo-2.x seperately from > afoo-1.x, because they both want to write the afoo control file. No, you ship *one* package that supports both 1.1 and 2.0. > But now, let's make it harder. I've found a grave bug in 1.1, which > causes the PG backend to segfault. Easy fix, good thing, so now I > release 1.2: Unless the bug is such that you have to change the installation script file, there is no reason to bump the version number at all. These version numbers apply to the install SQL script, not the underlying .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] ALTER EXTENSION UPGRADE, v3
On Feb 11, 2011, at 10:58 AM, Aidan Van Dyk wrote: > I release exetension "afoo", initial as version 1.0. From my > understanding, it's going to contain: >afoo control file, named something particular) > - default_version = 1.0 > - encoding utf8 >foo-1.0.sql installstion script >and any requried shared libraries > > And I now release and updated version 1.1 which fixes a problem. No problem: > afoo control file: > - default_version = 1.1 > - encoding utf8 > afoo-1.1.sql installation > afoo-upgrade-1.0-1.1.sql upgrade script > any required shared libraries for afoo-1. Oh. Would be nice if default_version assumed that an unversioned file was the default, actually. That way I don't have to rename the file in my repository every time I want to make a release. That will mess with my Git version history. > Now, I decide to add some major new changes to my afoo for version 2. > I'ld like to package it up: > afoo control file >- default_version = 2.0 >- encoding utf8 > afoo-2.0.sql installation > afoo-upgrade-1.1-2.0-sql upgrade script > Any ne shared libreries for afoo-2. > > This gives my first problem. I can't package afoo-2.x seperately from > afoo-1.x, because they both want to write the afoo control file. > RPM/DPKG will cause me grief here. 1.x would have its own control file. 1 control file per version (at most). > But now, let's make it harder. I've found a grave bug in 1.1, which > causes the PG backend to segfault. Easy fix, good thing, so now I > release 1.2: > afoo control file >- default_version = 1.2 >- encoding utf8 > afoo-1.2.sql installation > afoo-upgrade-1.0-1.1.sql upgrade > afoo-upgrade-1.1-1.2.sql upgrade > any shared libraries for afoo-1 > > So, this is not a problem for upgrading 1.0/1.1 -> 1.2. But if I have > 1.1 on my system, and let's say I forced a 2.0 into the system > (telling dpkg/rpm to overwrite the common file), I'm going to do that > again here now with 1.2, and my afoo control file will have > default_version = 1.2 instead of the 2.0 Why wouldn't it have 2.1? You'd have added afoo-upgrade-1.1-1.2.sql and afoo-upgrade-2.0-2.2.sql. > So, I'm not even working about the in-database side of the > multi-versions (alhthough I definately want the ability to have > multiple versions in the same database), but we're not even going to > be able to get the files onto the system to support multiple versions > nicely. I'm not following why not. > So this is going to drive me the same direction the same problem drove > packages for rpm/dpkg. I'm going to have to name my extension > "afoo-1" and "afoo-2" to be able to have them both co-exist on the > filesystem independantly, and at that point, *I* don't need multiple > versions of it anymore. I'm going to keep the same extension > objects/libraries backwards compatible, and I just need a way to tell > PG to run something after I've replaced the shared libraries to > perform any upgrade tweeks. Oh, I think I see. You want to distribute 1.2 and 2.1 as separate downloads. I think the idea here is that you'd still have only one distribution download, but it would contain both 1.2 and 2.1. Then you have no conflicts. Best, David -- 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] Debian readline/libedit breakage
On Fri, Feb 11, 2011 at 20:09, Greg Smith wrote: > Stephen Frost wrote: > > -Adding GnuTLS support to PostgreSQL would require solving several > code quality issues > > > I'm curious about this, but I don't know that I've got time to dive into > it and solve it. :/ > > > Note that the past discussion was on the difficulty of matching the existing > OpenSSL API using GnuTLS, which is apparently difficult to do. I wasn't > trying to suggest there were issues specificially with GnuTLS's code > quality. It's more that the APIs are just different enough that it's not > trivial to do a swap--which is surprising given how many people have > seemingly needed to do exactly this conversion. You'd think there'd be a > simple "OpenSSL-like" interface available for GnuTLS by now or something. There is one, but it's not complete - it will work for simple users, though, AFAIK. -- 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
Re: [HACKERS] ALTER TYPE 2: skip already-provable no-work rewrites
On Fri, Feb 11, 2011 at 01:55:45PM -0500, Robert Haas wrote: > On Fri, Feb 11, 2011 at 1:08 PM, Noah Misch wrote: > > Even supposing we push off all scan-only cases to another patch, it would be > > good to have the tablecmds.c-internal representation of that in mind. ?No > > sense > > in simplifying a 12-line change to an 8-line change, only to redo it next > > patch. > > Incidentally, I don't really agree with this, as a philosophical > point. There can be a lot of point to simplifying things, even if it > means redoing a little work, if it makes them easier to understand, > both for the people reviewing at the time and for the benefit of > people reading the commit log in the future. Good to know. I can envision that perspective, and I share it when the savings is rather more substantial, say >10% of the patch or >100 lines. Below that threshold, the energy I expend grasping two interface changes in one patch series exceeds my annoyance at the premature generality. On Fri, Feb 11, 2011 at 01:34:14PM -0500, Robert Haas wrote: > On Fri, Feb 11, 2011 at 1:08 PM, Noah Misch wrote: > >> Upon examination, it appeared to me that trying to make the > >> AlteredTableInfo contain an enum indicating whether we were doing a > >> scan, a rewrite, or nothing was requiring more code change than I > >> could really justify. > > > > Offhand, I count 12 changed lines to introduce the enum. ?There may be other > > good reasons not to do it, but surely that wasn't it? > > I was unable to see what were getting out of that logic, and I > couldn't readily verify that it was correct. The value probably gets clearer when you need to use all three states. > I think what I'd like to do if there are no major objections is commit > this as-is, and then if you could perhaps provide a patch containing > the set of changes that are necessary to recapture the cases I > inadvertently failed to handle, namely: > > > 2) Skip rewrite for T -> constraint-free domain over T > > 3) Downgrade rewrite to scan for T -> constrained domain over T > > Then I'll review that separately. I think this change stands on its > own, and committing it in steps will be simple for me than doing the > whole thing in one go. That works for me. Know that, barring other suggestions, the followup patch will replace AlteredTableInfo.rewrite with the enum field. Just want to make sure that's not a surprise. ... And now that I've read your second reply, I probably didn't even have to mention it. Thanks again, nm -- 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] ALTER EXTENSION UPGRADE, v3
Robert Haas writes: > On Fri, Feb 11, 2011 at 1:06 PM, Tom Lane wrote: >> I'm not very happy with that at all, either as to the concept or the >> specific version-alias names. I don't think that CREATE and ALTER >> really need different default version targets. And those choices of >> names carry far too much baggage. "Default" is what they are as far as >> the system is concerned, but names like those imply a lot more. >> >> Anybody else have an opinion on this detail? > > I agree with you. Ok, I'm in the minority here. That happened before :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] Range Types: empty ranges
"Kevin Grittner" wrote: > Basically, with a type having well-defined granularity, a [) range > could usefully represent, "start to last used", and start out > empty. I guess that would actually be "start to next available" -Kevin -- 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] ALTER EXTENSION UPGRADE, v3
=?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= writes: > This has the side effect that you can also have downgrade scripts. I > don't know if this is designed or just coincidental, so thought it > would be worth mentioning. Yeah, that's intentional and IMO worth supporting. We do have to be sure that the chain-finding algorithm doesn't choke on loops in the graph, but AFAICS Dijkstra's algorithm doesn't have a problem with that. As long as we consider that each step has positive cost, it won't execute a loop. > The worst case is that if you are upgrading from 1.2 to 2.0 the path > is 1.2 -> 1.1 -> 2.0, even if there exists a path 1.2 -> 1.8 -> 1.9 -> > 2.0. This could potentially result in data loss, if the downgrade > drops some columns or something like that. Hmm. That seems like it would require a rather pathological collection of upgrade scripts. In particular why would you have a one-step upgrade from 1.1 to 2.0 but no short path from 1.2? 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] Range Types: empty ranges
On Fri, Feb 11, 2011 at 2:06 PM, Jeff Davis wrote: > On Fri, 2011-02-11 at 10:28 -0800, Josh Berkus wrote: >> I guess I'm having trouble tying the concept of empty ranges to any >> reality external to the database. > > That's true, but in the same sense as zero has no meaning outside of the > database. > > It's really that it has nice mathematical properties coming from set > theory. Take the distributive law: > > A UNION (B INTERSECT C) = (A UNION B) INTERSECT (A UNION C) But the basic range type isn't even closed under UNION. It seems like what you really need if you want this stuff to work out smoothly is a MULTIRANGE type. Then this problem goes away: the union or intersection of two ranges is a multirange, and after that everything is closed. -- 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] ALTER EXTENSION UPGRADE, v3
On Feb 11, 2011, at 10:30 AM, Tom Lane wrote: > No --- in the current vision, a control file may describe a whole > collection of versions of the same extension, and the parameter in > question is selecting the default or preferred version to install. > I'm not wedded to "default_version", but I think just plain "version" > is a misnomer. current_version, then. >> Oh, so what should oldv be to indicate creating from a legacy extension? > > In principle we are leaving it to the extension author to choose that. > However, we're going to have to make a choice for the contrib modules, > and I'll bet lunch that most people will follow whatever precedent we > set with those. I was thinking about using either "old" or "unpackaged". > Thoughts? unpackaged++ > It can be specified by a "directory" parameter in the control file, > and defaults to the same place the control file is. Right now, that's > $PREFIX/share/contrib/. Frankly, given the likely proliferation of upgrade scripts, I think it ought to be $PREFIX/share/contrib/$extension/ > One other thing that ought to be discussed is > whether to stick with that choice or change it. Given that some people > have great antipathy to the word "contrib", I suspect there will be > argument to change it --- but to do so, I think we'd have to change the > default MODULEDIR in PGXS, and I'm not sure that's a good idea. Add EXTENSIONDIR and make it "extensions". Best, David -- 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] Debian readline/libedit breakage
Stephen Frost wrote: -Adding GnuTLS support to PostgreSQL would require solving several code quality issues I'm curious about this, but I don't know that I've got time to dive into it and solve it. :/ Note that the past discussion was on the difficulty of matching the existing OpenSSL API using GnuTLS, which is apparently difficult to do. I wasn't trying to suggest there were issues specificially with GnuTLS's code quality. It's more that the APIs are just different enough that it's not trivial to do a swap--which is surprising given how many people have seemingly needed to do exactly this conversion. You'd think there'd be a simple "OpenSSL-like" interface available for GnuTLS by now or something. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
Re: [HACKERS] Range Types: empty ranges
Robert Haas wrote: >> I think that range '[15:15:00,15:15:00)' should be valid as a >> zero-length range between, for example, '[15:00:00,15:15:00)' and >> '[15:15:00,15:30:00)'. > > How would that actually work? I kind of agree with Josh: I'd be > inclined to make the type input function boot such constructs at > the door. It makes more sense in the context of a range of some type with a clearly defined granularity. Our accounting system, for example, can assign a new range of receipt IDs for each calendar year. If you want a variable to represent the receipts for traffic receipts for 2012, you might, in preparation for the upcoming year, define something to declare the range as '[12TR01,12TR01)'. When the first receipt is assigned as 12TR01, that is updated to '[12TR01,12TR02)'. Just as an off-the-cuff example. Basically, with a type having well-defined granularity, a [) range could usefully represent, "start to last used", and start out empty. -Kevin -- 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] Range Types: empty ranges
On Fri, 2011-02-11 at 10:28 -0800, Josh Berkus wrote:
> I guess I'm having trouble tying the concept of empty ranges to any
> reality external to the database.
That's true, but in the same sense as zero has no meaning outside of the
database.
It's really that it has nice mathematical properties coming from set
theory. Take the distributive law:
A UNION (B INTERSECT C) = (A UNION B) INTERSECT (A UNION C)
If (B INTERSECT C) is empty, then the result should be A. With empty
ranges, that holds on both sides. Without them, it doesn't hold on the
left side.
People implicitly use this kind of logic all the time when constructing
queries. If one form works, and the other throws an error, it will cause
confusion.
> For example, what would the time range:
>
> '('15:15:00','15:15:00')'
>
> ... represent exactly? "A non-existant point in time which might or
> might not be near 3:15 PM"?
That's meaningless and will throw an error. An empty range is not
anchored at any particular point, so any two empty ranges are equal.
> BUT ... if I, in one of my applications, accidentally defined something
> as having the range '('15:15:00','15:15:00')', I would *want* the
> database to through an error and not accept it.
Absolutely. That kind of input should throw an error (and does).
> So, if we allow empty ranges of this kind, I would want a GUC for
> "allow_empty_ranges".
I think that would be the least desirable option. If we don't like empty
ranges, let's prohibit them entirely.
Or, there are always check constraints...
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Replication server timeout patch
Hello list,
I split this out of the synchronous replication patch for independent
review. I'm dashing out the door, so I haven't put it on the CF yet or
anything, but I just wanted to get it out there...I'll be around in
Not Too Long to finish any other details.
--
fdr
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 2121,2126 SET ENABLE_SEQSCAN TO OFF;
--- 2121,2140
+
+ replication_timeout_server (integer)
+
+replication_timeout_server configuration parameter
+
+
+
+ If the primary server does not receive a reply from a standby server
+ within replication_timeout_server seconds then the
+ primary will terminate the replication connection.
+
+
+
+
*** a/src/backend/replication/walsender.c
--- b/src/backend/replication/walsender.c
***
*** 73,78 bool am_walsender = false; /* Am I a walsender process ? */
--- 73,80
/* User-settable parameters for walsender */
int max_wal_senders = 0; /* the maximum number of concurrent walsenders */
int WalSndDelay = 200; /* max sleep time between some actions */
+ int replication_timeout_server; /* If the receiver takes too long, time
+ * out and die after this duration */
/*
* These variables are used similarly to openLogFile/Id/Seg/Off,
***
*** 89,94 static uint32 sendOff = 0;
--- 91,99
*/
static XLogRecPtr sentPtr = {0, 0};
+ /* Remembers the last time the standby has notified the primary of progress */
+ static TimestampTz last_reply_timestamp;
+
/* Flags set by signal handlers for later service in main loop */
static volatile sig_atomic_t got_SIGHUP = false;
volatile sig_atomic_t walsender_shutdown_requested = false;
***
*** 250,255 WalSndHandshake(void)
--- 255,265
errmsg("invalid standby handshake message type %d", firstchar)));
}
}
+
+ /*
+ * Initialize our timeout checking mechanism.
+ */
+ last_reply_timestamp = GetCurrentTimestamp();
}
/*
***
*** 616,632 WalSndLoop(void)
if (!XLogSend(output_message, &caughtup))
break;
! if (caughtup && !got_SIGHUP && !walsender_ready_to_stop && !walsender_shutdown_requested)
{
! /*
! * XXX: We don't really need the periodic wakeups anymore,
! * WaitLatchOrSocket should reliably wake up as soon as
! * something interesting happens.
! */
/* Sleep */
! WaitLatchOrSocket(&MyWalSnd->latch, MyProcPort->sock,
! WalSndDelay * 1000L);
}
}
else
--- 626,650
if (!XLogSend(output_message, &caughtup))
break;
! if (caughtup && !got_SIGHUP && !walsender_ready_to_stop &&
! !walsender_shutdown_requested)
{
! long timeout;
!
! if (replication_timeout_server == -1)
! timeout = -1L;
! else
! timeout = 100L * replication_timeout_server;
/* Sleep */
! if (WaitLatchOrSocket(&MyWalSnd->latch, MyProcPort->sock,
! timeout) == 0)
! {
! ereport(LOG,
! (errmsg("streaming replication timeout after %d s",
! replication_timeout_server)));
! break;
! }
}
}
else
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
***
*** 1484,1489 static struct config_int ConfigureNamesInt[] =
--- 1484,1499
},
{
+ {"replication_timeout_server", PGC_SIGHUP, WAL_SETTINGS,
+ gettext_noop("Replication connection will timeout after this duration."),
+ NULL,
+ GUC_UNIT_S
+ },
+ &replication_timeout_server,
+ 30, -1, INT_MAX, NULL, NULL
+ },
+
+ {
{"temp_buffers", PGC_USERSET, RESOURCES_MEM,
gettext_noop("Sets the maximum number of temporary buffers used by each session."),
NULL,
*** a/src/backend/utils/misc/postgresql.conf.sample
--- b/src/backend/utils/misc/postgresql.conf.sample
***
*** 203,208
--- 203,209
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_status_interval = 10s # replies at least this often, 0 disables
+ #replication_timeout_server = 120 # -1 means wait forever
#--
*** a/src/include/replication/walsender.h
--- b/src/include/replication/walsender.h
***
*** 70,75 extern volatile sig_atomic_t walsender_ready_to_stop;
--- 70,76
/* user-settable parameters */
extern int WalSndDelay;
extern int max_wal_senders;
+ extern int replication_timeout_server;
extern int WalSenderMain(void);
extern void WalSndSignals(void);
--
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] Range Types: empty ranges
On Fri, Feb 11, 2011 at 1:50 PM, Kevin Grittner
wrote:
> Josh Berkus wrote:
>
>> if I, in one of my applications, accidentally defined something
>> as having the range '('15:15:00','15:15:00')', I would *want* the
>> database to through an error and not accept it.
>
> I can agree with that, but I think that range '[15:15:00,15:15:00)'
> should be valid as a zero-length range between, for example,
> '[15:00:00,15:15:00)' and '[15:15:00,15:30:00)'.
How would that actually work? I kind of agree with Josh: I'd be
inclined to make the type input function boot such constructs at the
door.
--
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] ALTER TYPE 2: skip already-provable no-work rewrites
On Fri, Feb 11, 2011 at 1:08 PM, Noah Misch wrote: > Even supposing we push off all scan-only cases to another patch, it would be > good to have the tablecmds.c-internal representation of that in mind. No > sense > in simplifying a 12-line change to an 8-line change, only to redo it next > patch. Incidentally, I don't really agree with this, as a philosophical point. There can be a lot of point to simplifying things, even if it means redoing a little work, if it makes them easier to understand, both for the people reviewing at the time and for the benefit of people reading the commit log in the future. -- 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] Range Types: empty ranges
On Fri, Feb 11, 2011 at 1:11 PM, Jeff Davis wrote: > Similarly, "intersection" of ranges is somewhat analogous to > multiplication of numbers. I had a feeling that we might be going in this direction. It strikes me that this case is a bit like division by zero. It's kind of a nuisance that dividing by zero throws an error and we COULD fix that by making it return NULL or NaN or some new distinguished value DbZ. But then we'd have to define what happens when you feed DbZ into every other operation in the system, and similarly here. If we define two non-overlapping ranges as intersecting to NULL, or as throwing an error, then everything else is clear after that. I'm not sure it's worth complicating the representation and the definitions of other operations to cater to this case. -- 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
