Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote: Simon Riggs wrote: I would prefer that we backported pg_standby into 8.2 contrib, so the solution is where people need it to be. If not... Don't know about the policy to put things in already-released-version but if it's not the case, we could at least put the code somewhere in the ftp.postgresql.org. IMHO pgfoundry project will confuse people. Both: ftp and pgfoundry. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, October 10, 2007 07:09:20 +0100 Simon Riggs
[EMAIL PROTECTED] wrote:
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
solution is where people need it to be. If not...
Don't know about the policy to put things in already-released-version
but if it's not the case, we could at least put the code somewhere in
the ftp.postgresql.org. IMHO pgfoundry project will confuse people.
Both: ftp and pgfoundry.
ftp://ftp.postgresql.org/pub/projects/{gborg,pgFoundry}
-
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFHDLxU4QvfyHIvDvMRAjkCAJ9nN3JxEV/drYMO7uMN2uH1phhJbwCgiCKN
etp2sBtJoBTtqoAVUgLSkzw=
=yAQh
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Wednesday 10 October 2007 02:09, Simon Riggs wrote:
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
solution is where people need it to be. If not...
Don't know about the policy to put things in already-released-version
but if it's not the case, we could at least put the code somewhere in
the ftp.postgresql.org. IMHO pgfoundry project will confuse people.
Both: ftp and pgfoundry.
Putting it on pgfoundry would automatically put it in the ftp tree
(ftp://ftp.postgresql.org/pub/projects/pgFoundry). If it was to go on
pgfoundry (which I'd recommend) I'd suggest removing it from 8.3 contrib
before we release (cause having it in both places is really going to cause
confusion)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Robert Treat wrote: On Wednesday 10 October 2007 02:09, Simon Riggs wrote: On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote: Simon Riggs wrote: I would prefer that we backported pg_standby into 8.2 contrib, so the solution is where people need it to be. If not... Don't know about the policy to put things in already-released-version but if it's not the case, we could at least put the code somewhere in the ftp.postgresql.org. IMHO pgfoundry project will confuse people. Both: ftp and pgfoundry. Putting it on pgfoundry would automatically put it in the ftp tree (ftp://ftp.postgresql.org/pub/projects/pgFoundry). If it was to go on pgfoundry (which I'd recommend) I'd suggest removing it from 8.3 contrib before we release (cause having it in both places is really going to cause confusion) One of pgfoundry's explicit purposes is for backports of features. Given that we (rightly) don't backport new features in mainline releases, where else should they go? I don't buy the confusing argument. If necessary the author can plaster big red notices in a README on the pgfoundry release saying don't use this past postgres version x cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Wednesday 10 October 2007 10:57, Andrew Dunstan wrote:
Robert Treat wrote:
On Wednesday 10 October 2007 02:09, Simon Riggs wrote:
On Wed, 2007-10-10 at 01:14 -0300, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
I would prefer that we backported pg_standby into 8.2 contrib, so the
solution is where people need it to be. If not...
Don't know about the policy to put things in already-released-version
but if it's not the case, we could at least put the code somewhere in
the ftp.postgresql.org. IMHO pgfoundry project will confuse people.
Both: ftp and pgfoundry.
Putting it on pgfoundry would automatically put it in the ftp tree
(ftp://ftp.postgresql.org/pub/projects/pgFoundry). If it was to go on
pgfoundry (which I'd recommend) I'd suggest removing it from 8.3 contrib
before we release (cause having it in both places is really going to
cause confusion)
One of pgfoundry's explicit purposes is for backports of features.
I can't think of any contrib modules we've added that also required backwards
comptible modules to be released on foundry at the same time. ISTM that such
a requirement would be an argument that such a thing doesn't belong in
contrib at all.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Robert Treat [EMAIL PROTECTED] writes: On Wednesday 10 October 2007 10:57, Andrew Dunstan wrote: One of pgfoundry's explicit purposes is for backports of features. I can't think of any contrib modules we've added that also required backwards comptible modules to be released on foundry at the same time. ISTM that such a requirement would be an argument that such a thing doesn't belong in contrib at all. AFAICT there isn't any market for a backport of txid. Slony won't depend on it before their next release, which will require PG = 8.3 for other reasons. Skytools already has an internal version in their existing releases. And the code won't work before PG 8.2 so any backport couldn't go very far anyway. So while Andrew's statement is true in general, I don't think it's very relevant to a consideration of what to do with txid. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Tom Lane wrote: Robert Treat [EMAIL PROTECTED] writes: On Wednesday 10 October 2007 10:57, Andrew Dunstan wrote: One of pgfoundry's explicit purposes is for backports of features. I can't think of any contrib modules we've added that also required backwards comptible modules to be released on foundry at the same time. ISTM that such a requirement would be an argument that such a thing doesn't belong in contrib at all. AFAICT there isn't any market for a backport of txid. Slony won't depend on it before their next release, which will require PG = 8.3 for other reasons. Skytools already has an internal version in their existing releases. And the code won't work before PG 8.2 so any backport couldn't go very far anyway. So while Andrew's statement is true in general, I don't think it's very relevant to a consideration of what to do with txid. The context of this quote was referring to pg_standby, not txid. We wouldn't be having this discussion at all if we had not had a horribly long period beween feature freeze and beta. We'd be way past the stage where anyone would consider adding something to contrib or anywhere else. The only cure I can see for that is that we need much more stringent criteria for what is a candidate to make the cut. I know I committed things that really weren't ready when I got hold of them, and required a lot of work to get them anything like ready. Arguably that didn't matter because they weren't on the critical path, but I think all projects need to be handled equitably. I'm sure Tom faced the same problem I did ten times over. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Andrew Dunstan [EMAIL PROTECTED] writes: We wouldn't be having this discussion at all if we had not had a horribly long period beween feature freeze and beta. I'm not sure about that. The bottom line to me is that we are doing a favor to the Slony and Skytools projects, who figured out *after* our feature freeze that they could use some common code but it would be too late if it wasn't available in 8.3. Even had the freeze period been only a couple weeks, that could have happened --- it was just the sort of unfortunate timing that the universe likes to play on humans ;-) There was some complaining in this thread that we were showing favoritism to the txid patch. I'll plead guilty instead to favoritism to the Slony and Skytools projects --- the patch would certainly have gotten bounced without the support of those projects. I don't have a good grasp on the importance of Skytools, but I do know about Slony, and I don't have a problem with cutting them a break on a small, low-risk patch, even if it is a feature addition. The patches that got passed over for 8.3 were neither small nor low-risk; in fact, the reason the process dragged out so long was exactly that we busted our butts to get in everything that had any chance at all of getting in. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Mon, 2007-10-08 at 17:38 -0400, Robert Treat wrote: On Monday 08 October 2007 16:29, Magnus Hagander wrote: The whole contrib thing confuses a lot of users. Is it included, or isn't it? IMHO, that distinction need to be clear, and I thought we were working (if not actively then at least passively) to retire contrib, moving things either to core or to pgFoundry. Adding yet another important feature that's just in contrib is making things worse, not better. IMHO, of course ;-) +1. I felt the same way about pg_standby, which would have been far more accessible for 8.2 users had it lived on pg_foundry. I think we should move a version of pg_standby to pg_foundry anyway, specifically to support 8.2 users. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Tue, Oct 09, 2007 at 08:20:45AM +0100, Simon Riggs wrote: On Mon, 2007-10-08 at 17:38 -0400, Robert Treat wrote: On Monday 08 October 2007 16:29, Magnus Hagander wrote: The whole contrib thing confuses a lot of users. Is it included, or isn't it? IMHO, that distinction need to be clear, and I thought we were working (if not actively then at least passively) to retire contrib, moving things either to core or to pgFoundry. Adding yet another important feature that's just in contrib is making things worse, not better. IMHO, of course ;-) +1. I felt the same way about pg_standby, which would have been far more accessible for 8.2 users had it lived on pg_foundry. I think we should move a version of pg_standby to pg_foundry anyway, specifically to support 8.2 users. Are you saying you want two versions of pg_standby, one in contrbi and one on pgfoundry, or are you saying we should take the one in contrib away? //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Did it? I see nothing for txid in relesase.sgml. Right. release.sgml will be updated in batches as we near final release. We don't update for individual commits. Ok. I will explain about txid for local users myself. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Tue, 2007-10-09 at 10:58 +0200, Magnus Hagander wrote: On Tue, Oct 09, 2007 at 08:20:45AM +0100, Simon Riggs wrote: On Mon, 2007-10-08 at 17:38 -0400, Robert Treat wrote: On Monday 08 October 2007 16:29, Magnus Hagander wrote: The whole contrib thing confuses a lot of users. Is it included, or isn't it? IMHO, that distinction need to be clear, and I thought we were working (if not actively then at least passively) to retire contrib, moving things either to core or to pgFoundry. Adding yet another important feature that's just in contrib is making things worse, not better. IMHO, of course ;-) +1. I felt the same way about pg_standby, which would have been far more accessible for 8.2 users had it lived on pg_foundry. I think we should move a version of pg_standby to pg_foundry anyway, specifically to support 8.2 users. Are you saying you want two versions of pg_standby, one in contrbi and one on pgfoundry, or are you saying we should take the one in contrib away? I would prefer that we backported pg_standby into 8.2 contrib, so the solution is where people need it to be. If not... -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Simon Riggs wrote: I would prefer that we backported pg_standby into 8.2 contrib, so the solution is where people need it to be. If not... Don't know about the policy to put things in already-released-version but if it's not the case, we could at least put the code somewhere in the ftp.postgresql.org. IMHO pgfoundry project will confuse people. -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote: Log Message: --- Added the Skytools extended transaction ID module to contrib as discussed on CORE previously. This module offers transaction ID's containing the original XID and the transaction epoch as a bigint value to the user level. It also provides a special txid_snapshot data type that contains an entire transactions visibility snapshot information, which is useful to determine if a particular txid was visible to a transaction or not. The module has been tested by porting Slony-I from using its original xxid data type. Jan A couple of questions on this. I'm not objecting to the tech stuff itself, but on procedure: 1) Why was this added without any discussion, or even notification, on -hackers before it was done? Last I checked, -core claim not to deal with such technicalities, but defer to -hackers (or other lists as needed). I certainly trust -core to make the right call no these things, but it's not the procedure that we claim to have. If that procedure is changing (I've been getting a sneaky feeling that it's tilting a bit in that direction before this one), that's fine, but it should be communicated to the community so everybody knows how it works. 2) How can this go in *months* after feature freeze, and even after we tagged and bundled beta1? This makes such discission even more important, IMHO. 3) I thought the general agreement was to cut down on contrib, and move things either to pgfoundry or to core. Why are we adding more? I'm sure there's motivation for this as discussed on -core, but the rest of us would like to know that as well... Like why we're not trying to make it a real feature, if it's something that's important enough to break the rules as in #2 above. Or I could've missed the discussion on -hackers that actually took place - in that case, just discard this message. but the only one I recall is someone asking for pl/proxy to go in. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Magnus Hagander wrote: Or I could've missed the discussion on -hackers that actually took place - in that case, just discard this message. but the only one I recall is someone asking for pl/proxy to go in. There was some discussion (subject: Provide 8-byte transaction IDs to user level), but that itself happened after feature freeze and didn't seem too conclusive. I share your other concerns. This process certainly seems to have been less than transparent. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Andrew Dunstan [EMAIL PROTECTED] writes: I share your other concerns. This process certainly seems to have been less than transparent. FWIW, Jan asked -core about a week ago whether it'd be okay to add this code post-beta, and we concluded it would be okay on the grounds that (1) we've always been laxer about contrib than the core code, (2) we'd already granted similar permission to Oleg and Teodor to add some example tsearch dictionaries to contrib post-beta. But I was expecting some -hackers discussion and/or a proposed patch on -patches next. I agree that Jan skipped a step. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On 10/8/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote: Log Message: --- Added the Skytools extended transaction ID module to contrib as discussed on CORE previously. To explain the situation, the public discussion about the current submission happened here: http://lists.pgfoundry.org/pipermail/skytools-users/2007-September/000245.html and here: http://lists.slony.info/pipermail/slony1-hackers/2007-September/57.html And ofcourse, the original submission was at 2006-07 to _8.2_: http://archives.postgresql.org/pgsql-patches/2006-07/msg00157.php It was rejected then mostly on 3 reasons (from my POV): - it was messy and contained unnecesary cruft. - it was submitted to core not /contrib - slony was not interested in it at that moment Now as you can read from recent disussion we had, we found out that it would be *really* *really* cool if it would appear in 8.3... Talk about last moment... Because of the bad timing it would have been -core call anyway whether it gets in or not so Jan asked -core directly. That's my explanation about what happened, obviously Jan and Tom have their own opinion. -- marko ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Marko Kreen wrote: Now as you can read from recent disussion we had, we found out that it would be *really* *really* cool if it would appear in 8.3... Talk about last moment... That discussion didn't happen on any list I read, so to me it just came as a bolt from the blue. Surely there should at the very least have been a patch posted, core approval or not. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Marko Kreen wrote: On 10/8/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote: Log Message: --- Added the Skytools extended transaction ID module to contrib as discussed on CORE previously. To explain the situation, the public discussion about the current submission happened here: http://lists.pgfoundry.org/pipermail/skytools-users/2007-September/000245.html and here: http://lists.slony.info/pipermail/slony1-hackers/2007-September/57.html Ok. That certainly explains it - it did sound weird to have that go in without any public discussion at all - but none of those lists are pgsql-hackers ;-) And ofcourse, the original submission was at 2006-07 to _8.2_: http://archives.postgresql.org/pgsql-patches/2006-07/msg00157.php Ah. I only searched for this year, since I only considered submissions for 8.3. But still, it wasn't AFAIK on any of the patch lists etc. It was rejected then mostly on 3 reasons (from my POV): - it was messy and contained unnecesary cruft. - it was submitted to core not /contrib - slony was not interested in it at that moment Now as you can read from recent disussion we had, we found out that it would be *really* *really* cool if it would appear in 8.3... Talk about last moment... Well, if it's really really cool to have, why do we put it in /contrib? If it's that cool, it should be in core, no? That's not just making comments, I really *do* think that it should be in core if it's interesting enough to be added to contrib at this time. Because of the bad timing it would have been -core call anyway whether it gets in or not so Jan asked -core directly. That's my explanation about what happened, obviously Jan and Tom have their own opinion. Right. I can see your point, but it's my understanding that -hackers is really the ones supposed to decide on this. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Magnus Hagander [EMAIL PROTECTED] writes: Marko Kreen wrote: Because of the bad timing it would have been -core call anyway whether it gets in or not so Jan asked -core directly. That's my explanation about what happened, obviously Jan and Tom have their own opinion. Right. I can see your point, but it's my understanding that -hackers is really the ones supposed to decide on this. It would ultimately have been core's decision, but the discussion should have happened on -hackers. There was no reason for it to be private. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On 10/8/2007 1:34 PM, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Marko Kreen wrote: Because of the bad timing it would have been -core call anyway whether it gets in or not so Jan asked -core directly. That's my explanation about what happened, obviously Jan and Tom have their own opinion. Right. I can see your point, but it's my understanding that -hackers is really the ones supposed to decide on this. It would ultimately have been core's decision, but the discussion should have happened on -hackers. There was no reason for it to be private. That blame certainly belongs to me and I apologize for jumping that and adding it to contrib without any -hackers discussion. It is definitely a timing issue since I write this very email from JFK, boarding a flight to Hong Kong in less than an hour and will be mostly offline for the rest of the week. I agree with the technical issue Tom brought up. Slony itself doesn't rely on strtoull() either and this slipped through. I will see that I fix that by using Slony's int64 scanning code. I can work on it during the flight and commit the fix when I arrive in the hotel. To Magnus: It certainly would have been cool to have this in core, but two weeks ago we didn't know if we can get the code into shape for that before BETA (as it is right now I would say it still isn't). So we shot for the next best target, which was contrib, where post BETA changes aren't as critical. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On 10/8/07, Magnus Hagander [EMAIL PROTECTED] wrote: Marko Kreen wrote: On 10/8/07, Magnus Hagander [EMAIL PROTECTED] wrote: On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote: Log Message: --- Added the Skytools extended transaction ID module to contrib as discussed on CORE previously. To explain the situation, the public discussion about the current submission happened here: http://lists.pgfoundry.org/pipermail/skytools-users/2007-September/000245.html and here: http://lists.slony.info/pipermail/slony1-hackers/2007-September/57.html Ok. That certainly explains it - it did sound weird to have that go in without any public discussion at all - but none of those lists are pgsql-hackers ;-) Yes, sorry about that. Just the discussion started very hypetetically, with us probing each other opinion, and there was nothing to discuss with -hackers. When we saw a concrete plan for the module, then it was too late to do a regular -hackers submission, due to the beta timeline we needed -core opinion immidiately. Now, after -core gave a nod, then yes, the patch should have been to -hackers with a notice that it is on fast-path. [btw, this is me guessing Jan's thinking, but I would have acted same way.] Now as you can read from recent disussion we had, we found out that it would be *really* *really* cool if it would appear in 8.3... Talk about last moment... Well, if it's really really cool to have, why do we put it in /contrib? If it's that cool, it should be in core, no? Main cool thing came from fact that this is the last moment Slony could do such big conversion of it's codebase. That's not just making comments, I really *do* think that it should be in core if it's interesting enough to be added to contrib at this time. Yes, it is cool enough to be in core and I think that's the goal. But asking for it to be accepted to core a week before beta and couple months after feature freeze would be asking bit too much, don't you think? ;) -- marko ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Jan Wieck wrote: On 10/8/2007 1:34 PM, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Marko Kreen wrote: Because of the bad timing it would have been -core call anyway whether it gets in or not so Jan asked -core directly. That's my explanation about what happened, obviously Jan and Tom have their own opinion. Right. I can see your point, but it's my understanding that -hackers is really the ones supposed to decide on this. It would ultimately have been core's decision, but the discussion should have happened on -hackers. There was no reason for it to be private. That blame certainly belongs to me and I apologize for jumping that and adding it to contrib without any -hackers discussion. It is definitely a timing issue since I write this very email from JFK, boarding a flight to Hong Kong in less than an hour and will be mostly offline for the rest of the week. I agree with the technical issue Tom brought up. Slony itself doesn't rely on strtoull() either and this slipped through. I will see that I fix that by using Slony's int64 scanning code. I can work on it during the flight and commit the fix when I arrive in the hotel. Good. Win32 is pretty much dead right now, so we can't proceed with things like testing the buildfarm with msvc/ecpg. To Magnus: It certainly would have been cool to have this in core, but two weeks ago we didn't know if we can get the code into shape for that before BETA (as it is right now I would say it still isn't). So we shot for the next best target, which was contrib, where post BETA changes aren't as critical. Right. My thought is still that if it isn't good enough for core, it shouldn't be in contrib. If it *is* good enough, and we want it, we should accept that it came in long after freeze and put it in core anyway. If it *isn't*, then it should be on pgfoundry and be moved into core when it's ready - for 8.4 or so. The whole contrib thing confuses a lot of users. Is it included, or isn't it? IMHO, that distinction need to be clear, and I thought we were working (if not actively then at least passively) to retire contrib, moving things either to core or to pgFoundry. Adding yet another important feature that's just in contrib is making things worse, not better. IMHO, of course ;-) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Marko Kreen wrote: Because of the bad timing it would have been -core call anyway whether it gets in or not so Jan asked -core directly. That's my explanation about what happened, obviously Jan and Tom have their own opinion. Right. I can see your point, but it's my understanding that -hackers is really the ones supposed to decide on this. It would ultimately have been core's decision, but the discussion should have happened on -hackers. There was no reason for it to be private. Hmm. I thought that -core doesn't decide on things like these, they just vote on -hackers and have no special powers (other than being very respected community members that we all listen to, of course). I seem to recall hearing all the time (most often from people on core, but I'm certainly one of the people who relay that information further) that core specifically *doesn't* decide on things like that (being direct technical issues, or just the talk about the name-change that's been flooding -advocacy), but that core are only there for dealing with companies that don't want to deal in public, and for making decisions if -hackers can't agree, security sensitive stuff, and things like that. It may be that it just was like that before, and isn't anymore, and my information is outdated. I don't mind, really, because I certainly trust -core to make good decisions. But if that's so, then at least I have to change what I tell people that ask... //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Magnus Hagander [EMAIL PROTECTED] writes: The whole contrib thing confuses a lot of users. Is it included, or isn't it? IMHO, that distinction need to be clear, and I thought we were working (if not actively then at least passively) to retire contrib, moving things either to core or to pgFoundry. Adding yet another important feature that's just in contrib is making things worse, not better. IMHO, of course ;-) I disagree with this principle. I think contrib has a role to play and there are modules which belong in contrib for now and forever. The key distinction isn't code quality -- I think that's an effect rather than a cause. The key distinction is the intended audience. Contrib is for things which are integral parts of the system and as such would be harder to maintain in pgfoundry, but have a very limited audience, especially things that a typical admin wouldn't necessarily want in his install for security or safety reasons. So pageinspect, adminpack, pg_buffercache, pg_standby, etc, these are all things which are tightly tied to the system. They often need to be modified when making unrelated changes to the core and can't be maintained as a separate add-on by a different group of maintainers. But they're not appropriate to install by default because they have a limited audience. Some of the modules in there are legacy modules which today would probably be done as pgfoundry modules. The GIST data types, earthdistance, isn, etc. We did actively prune out a lot of modules like that which were poorly maintained and bitrotting. The ones which remain are in reasonably good shape and have wide enough user-bases that moving them to pgfoundry would cause more upgrade pain than it would help. But that doesn't mean we're phasing contrib out entirely. The question remains whether txid is more like pageinspect/pg_standby/etc or more like earthdistance/isn. It does sound like the whole point of it is to provide an interface to core that pgfoundry modules can use, so presumably it's dealing with the nitty gritty stuff that pgfoundry modules would have trouble maintaining. Also, we only want *one* official such module. I think pushing it to pgfoundry doesn't make any sense. Does it make sense to put it in core? it has a limited audience in that only skype and slony users need it. On the other hand there's not much reason an admin wouldn't want it installed I don't think. What happens if we put it in core now and then the replication folk add more to the interface and include things that not all admins would want installed? And is the interface mature enough that users should be building applications depending on this interface directly? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Monday 08 October 2007 16:29, Magnus Hagander wrote:
The whole contrib thing confuses a lot of users. Is it included, or
isn't it? IMHO, that distinction need to be clear, and I thought we
were working (if not actively then at least passively) to retire
contrib, moving things either to core or to pgFoundry. Adding yet
another important feature that's just in contrib is making things
worse, not better.
IMHO, of course ;-)
+1. I felt the same way about pg_standby, which would have been far more
accessible for 8.2 users had it lived on pg_foundry.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Tom Lane wrote: (1) we've always been laxer about contrib than the core code, While that appears to be true, I think (a) there is no technical reason allowing us to do that, and (b) most people don't seem to like it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Mon, 08 Oct 2007 17:38:48 -0400 Robert Treat [EMAIL PROTECTED] wrote: On Monday 08 October 2007 16:29, Magnus Hagander wrote: The whole contrib thing confuses a lot of users. Is it included, or isn't it? IMHO, that distinction need to be clear, and I thought we were working (if not actively then at least passively) to retire contrib, moving things either to core or to pgFoundry. Adding yet another important feature that's just in contrib is making things worse, not better. IMHO, of course ;-) +1. I felt the same way about pg_standby, which would have been far more accessible for 8.2 users had it lived on pg_foundry. Well pg_standby is certainly an excellent example :). We have had this similar discussion before, this exact discussion is one of the reasons Tsearch2 got pushed into core. Contrib is just a dead zone for the user populous. Most people consider it unsupported *stuff* with no particular purpose (regardless of the real meaning). If you look at contrib in other projects they are always user contributed modules that are cool, but your mileage may vary. Personally, I would like to see contrib completely removed. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ signature.asc Description: PGP signature
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Mon, 08 Oct 2007 22:32:55 +0200 Magnus Hagander [EMAIL PROTECTED] wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Marko Kreen wrote: Because of the bad timing it would have been -core call anyway whether it gets in or not so Jan asked -core directly. That's my explanation about what happened, obviously Jan and Tom have their own opinion. Right. I can see your point, but it's my understanding that -hackers is really the ones supposed to decide on this. It would ultimately have been core's decision, but the discussion should have happened on -hackers. There was no reason for it to be private. Hmm. I thought that -core doesn't decide on things like these, they just vote on -hackers and have no special powers (other than being very respected community members that we all listen to, of course). That was my understanding as well. I quote from Tom Lane on August 30th of this year: I think you're overstating the amount of power the core committee has. Core sets release schedules, but beyond that has no more power than any other committer. The pool of committers is quite a bit bigger than core. In practice, of course, core has quite a lot of political power because folk are often willing to follow our lead. But we'd lose that real quick if we tried to lead in the wrong direction. Source: http://people.planetpostgresql.org/xzilla/index.php?/archives/317-PostgreSQL-is-Not-a-Democracy.html Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ signature.asc Description: PGP signature
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Magnus Hagander [EMAIL PROTECTED] writes: Right. My thought is still that if it isn't good enough for core, it shouldn't be in contrib. If it *is* good enough, and we want it, we should accept that it came in long after freeze and put it in core anyway. If it *isn't*, then it should be on pgfoundry and be moved into core when it's ready - for 8.4 or so. The long and the short of it was that the patch wasn't ready. To put it in core for 8.3, we'd have either had to delay the beta yet more, or force initdb post-beta1, neither of which would have flown. The whole contrib thing confuses a lot of users. To me, contrib exists mostly as a forcing function to ensure that we keep the extension-module system working. If we got rid of it entirely, as some here propose, we'd be more likely to break things that we'd not find out about until much later (like when some pgfoundry project tried to update their code, which almost certainly wouldn't be till the next beta cycle). Contrib also has a role to play as a repository of code examples that people can crib from when developing new extension modules. I would not want to claim that it's all best practice code --- a lot of it definitely isn't --- but it stands a lot better chance of representing current good practice if it's maintained with the core code than if it's out on pgfoundry. On pgfoundry, it won't get included in the global- search-and-replace patches that we do so many of, and it'll most likely accumulate a lot of cruft from trying to be compatible with multiple core releases. So I have no interest in trying to retire contrib. I think there's room for debate about exactly which modules to include, of course. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
A Dimarts 09 Octubre 2007, Joshua D. Drake va escriure: Contrib is just a dead zone for the user populous. Most people consider it unsupported *stuff* with no particular purpose (regardless of the real meaning). I think no visible documentation is the reason for this misconception and 8.3 will provide contrib documentation together with core docs. Let's see what happens then... -- Albert Cervera i Areny http://www.NaN-tic.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Tom Lane wrote: So I have no interest in trying to retire contrib. I think there's room for debate about exactly which modules to include, of course. I dont' think there's much call for retiring it. I think there is interest in renaming it, as contrib is a wholly misleading name, and rearranging the modules somewhat, and above all in documenting it properly. One of the original goals of the buildfarm was to lessen the extent to which contrib was a second class citizen by making sure it was tested on the same schedule as the rest of Postgres. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
On Sun, Oct 07, 2007 at 11:32:19PM +, Jan Wieck wrote: Log Message: --- Added the Skytools extended transaction ID module to contrib as discussed on CORE previously. This module offers transaction ID's containing the original XID and the transaction epoch as a bigint value to the user level. It also provides a special txid_snapshot data type that contains an entire transactions visibility snapshot information, which is useful to determine if a particular txid was visible to a transaction or not. The module has been tested by porting Slony-I from using its original xxid data type. Jan A couple of questions on this. I'm not objecting to the tech stuff itself, but on procedure: 1) Why was this added without any discussion, or even notification, on -hackers before it was done? Last I checked, -core claim not to deal with such technicalities, but defer to -hackers (or other lists as needed). I certainly trust -core to make the right call no these things, but it's not the procedure that we claim to have. If that procedure is changing (I've been getting a sneaky feeling that it's tilting a bit in that direction before this one), that's fine, but it should be communicated to the community so everybody knows how it works. 2) How can this go in *months* after feature freeze, and even after we tagged and bundled beta1? This makes such discission even more important, IMHO. 3) I thought the general agreement was to cut down on contrib, and move things either to pgfoundry or to core. Why are we adding more? I'm sure there's motivation for this as discussed on -core, but the rest of us would like to know that as well... Like why we're not trying to make it a real feature, if it's something that's important enough to break the rules as in #2 above. Or I could've missed the discussion on -hackers that actually took place - in that case, just discard this message. but the only one I recall is someone asking for pl/proxy to go in. More question. Who is in charge of updating HISTORY? I see no commit messages for this. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Tatsuo Ishii wrote: More question. Who is in charge of updating HISTORY? I see no commit messages for this. It is a generated file. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
More question. Who is in charge of updating HISTORY? I see no commit messages for this. It is a generated file. I mean release.sgml. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Tatsuo Ishii wrote: More question. Who is in charge of updating HISTORY? I see no commit messages for this. It is a generated file. I mean release.sgml. Tom and others made commits to this and we will update it again before final. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Tatsuo Ishii wrote: More question. Who is in charge of updating HISTORY? I see no commit messages for this. It is a generated file. I mean release.sgml. Tom and others made commits to this and we will update it again before final. Did it? I see nothing for txid in relesase.sgml. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Tatsuo Ishii wrote: Tatsuo Ishii wrote: More question. Who is in charge of updating HISTORY? I see no commit messages for this. It is a generated file. I mean release.sgml. Tom and others made commits to this and we will update it again before final. Did it? I see nothing for txid in relesase.sgml. Right. release.sgml will be updated in batches as we near final release. We don't update for individual commits. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
