On 10/10/07, Marko Kreen [EMAIL PROTECTED] wrote:
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
* Why is txid_current_snapshot() excluding subtransaction XIDs? That
might be all right for the current uses in Slony/Skytools, but it seems
darn close to a bug for any other use.
In queue
On 10/11/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
Could you describe bit more? The is_visible_txid() works
on data returned by txid_current_snapshot()? How can there
be any subtrans id's if txid_current_snapshot() wont return
them?
Ah, I see:
On 10/10/07, Marko Kreen [EMAIL PROTECTED] wrote:
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
* Why is txid_current_snapshot() excluding subtransaction XIDs? That
might be all right for the current uses in Slony/Skytools, but it seems
darn close to a bug for any other use.
In queue
Magnus Hagander wrote:
The results have nothing to do with whether the process was followed.
We do not ignore process violations just because the outcome was OK.
Agreed. But reversing something that came out OK for no other reason
than that the process was violated? I know you don't,
We allow /contrib to be more lax about beta changes.
the postgresql ecosystem is growing and there is a lot of people like
packagers that will be a quite irritated if we keep randomly adding
completely new code and modules during BETA.
Should packagers be concerned with /contrib at
Ühel kenal päeval, K, 2007-10-10 kell 07:44, kirjutas Magnus Hagander:
We allow /contrib to be more lax about beta changes.
the postgresql ecosystem is growing and there is a lot of people like
packagers that will be a quite irritated if we keep randomly adding
completely new code
On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote:
I think this project has got too big for us to make things up as we go
along. We need to follow processes that are well understood and
transparent.
Well said, I very much agree.
Mostly we do, but since we've just spent more than 6
Hi,
On Tue, 2007-10-09 at 17:10 -0700, Joshua D. Drake wrote:
(Will all respect to pginstaller team, I'm *think* it won't take
much
time to add txid to installer, at least compared to the time that we
spent discussing this issue.)
With respect, you don't know. My understanding of the
We allow /contrib to be more lax about beta changes.
the postgresql ecosystem is growing and there is a lot of people like
packagers that will be a quite irritated if we keep randomly adding
completely new code and modules during BETA.
Should packagers be concerned
Simon Riggs wrote:
Personally, I want to see Jan contribute more, not less. The link with
Slony and related replication technology is critically important to
Postgres, which is why Jan has spent so long on it.
Generally we should be encouraging everybody to contribute; the project
must have
Devrim GÜNDÜZ wrote:
(Will all respect to pginstaller team, I'm *think* it won't take much
time to add txid to installer, at least compared to the time that we
spent discussing this issue.)
Time is not the issue.
/D
---(end of broadcast)---
TIP
On Wed, 2007-10-10 at 07:08 +0100, Simon Riggs wrote:
On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote:
I think this project has got too big for us to make things up as we go
along. We need to follow processes that are well understood and
transparent.
Well said, I very much
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the patch and requiring that the patch go through the formal
review
On 10/10/2007 12:05 AM, Shane Ambler wrote:
Devrim GÜNDÜZ wrote:
Hi,
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
You know, txid was discussed in Slony-I + Skytools lists for a
reasonably long time, and Tom also
On Wed, 2007-10-10 at 11:50 +0300, Marko Kreen wrote:
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
Yes, reverting is an option
Reverting is only an option if we need to solve a technical problem. If
there is no
On Wed, Oct 10, 2007 at 11:50:12AM +0300, Marko Kreen wrote:
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the
Magnus Hagander wrote:
On Wed, Oct 10, 2007 at 11:50:12AM +0300, Marko Kreen wrote:
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not
On 10/10/07, Magnus Hagander [EMAIL PROTECTED] wrote:
All objections have been procedural, AFICS.
Lets not talk about mistakes we made for a moment.
And I agree with the rest of the objections in general. But I'd
like to summarise why I still hope the exception can be made
even this late.
This
On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
On 10/10/07, Magnus Hagander [EMAIL PROTECTED] wrote:
All objections have been procedural, AFICS.
Lets not talk about mistakes we made for a moment.
And I agree with the rest of the objections in general. But I'd
like to
Marko Kreen wrote:
On 10/10/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the patch and requiring that the patch go
Agreed. I think if we had followed procedure the code would have been
accepted post-beta1.
---
Marko Kreen wrote:
On 10/10/07, Magnus Hagander [EMAIL PROTECTED] wrote:
All objections have been procedural, AFICS.
Lets
Magnus Hagander wrote:
Now txid can change that. E.g. in Skype, it has become irreplaceable
tool for coordinating work between several databases. Here we are
probably going overboard with usage of queues...
If it is this irreplacable killer feature, it should *not* be in contrib.
It
Magnus Hagander wrote:
If it is this irreplacable killer feature, it should *not* be in contrib.
It should be in the core backend, and we should be discussing if we can
bend the rules for that. This is the proper forum for discussing that, so
let's bring that question to the table.
Our beta-1
Magnus Hagander wrote:
If it is this irreplacable killer feature, it should *not* be in contrib.
It should be in the core backend, and we should be discussing if we can
bend the rules for that. This is the proper forum for discussing that, so
let's bring that question to the table.
+1 there,
Simon Riggs wrote:
On Tue, 2007-10-09 at 18:35 -0400, Andrew Dunstan wrote:
I think this project has got too big for us to make things up as we go
along. We need to follow processes that are well understood and
transparent.
Well said, I very much agree.
Mostly we do, but since
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
Now txid can change that. E.g. in Skype, it has become irreplaceable
tool for coordinating work between several databases. Here we are
probably going overboard with usage of queues...
If
Bruce Momjian [EMAIL PROTECTED] writes:
Marko Kreen wrote:
Also I think several people are annoyed by the Jan asked permission
from -core part of the process.
I don't think this is accurate. Jan talked to Tom, not all of core, and
Tom just gave general approval. Tom still expected this to
Bruce Momjian [EMAIL PROTECTED] writes:
I also agree with this. We have to pretend it isn't in /contrib now,
figure out where want it, then put it there (contrib, pgfoundry, core).
Putting it in core now would mean forcing a post-beta1 initdb, which
I don't think adequate cause has been shown
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
Now txid can change that. E.g. in Skype, it has become irreplaceable
tool for coordinating work between several databases. Here we are
On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I also agree with this. We have to pretend it isn't in /contrib now,
figure out where want it, then put it there (contrib, pgfoundry, core).
Putting it in core now would mean forcing a
Hi,
On Wed, 2007-10-10 at 09:19 +0100, Simon Riggs wrote:
I should add that I'm not unhappy about how things have happened and I
have no complaints to lodge anywhere with anybody. Just wanted to give
Jan a bit of moral support
I have the same feelings, so +1.
Regards,
--
Devrim GÜNDÜZ
Marko Kreen [EMAIL PROTECTED] writes:
IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal state...
Well, it exports backend internal state that did not exist before 8.2
(ie, XID epoch). So it doesn't seem all that set in stone
On Wed, 2007-10-10 at 10:29 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
Mostly we do, but since we've just spent more than 6 months between
Feature Freeze and Beta. There were no well understood or transparent
processes during that period, so nobody is on solid ground trying to
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal state...
Well, it exports backend internal state that did not exist before 8.2
(ie, XID
Simon Riggs wrote:
On Wed, 2007-10-10 at 10:29 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
Mostly we do, but since we've just spent more than 6 months between
Feature Freeze and Beta. There were no well understood or transparent
processes during that period, so nobody is on solid
Magnus Hagander [EMAIL PROTECTED] writes:
(Assuming it's technically sound - I still haven't checked the actual
code, but I'm assuming it's Ok since Jan approved it)
I hadn't looked at it either, but here are a few things that need
review:
* Why no binary I/O support for the new datatype? We
On Wed, Oct 10, 2007 at 11:47:15AM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal state...
Well, it exports backend internal state that did not exist before
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I also agree with this. We have to pretend it isn't in /contrib now,
figure out where want it, then put it there (contrib, pgfoundry, core).
On Wed, 10 Oct 2007 11:04:53 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
Now txid can change that. E.g. in Skype, it has become
irreplaceable tool for coordinating work between several
On Wed, 10 Oct 2007 18:33:03 +0300
Marko Kreen [EMAIL PROTECTED] wrote:
Considering the core operations are now being in active use
some 6-7 years, I really fail to see how there can be anything
to tweak, unless you are speaking changing naming style.
Well that is the problem right there
On Wed, 10 Oct 2007 13:01:54 +0200
Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
yeah I agree that code like this should be either in core or
somewhere else (either pgfoundry or even shipped as part of the
replication solutions mentioned which is basically something slony
did for ages with
Joshua D. Drake [EMAIL PROTECTED] writes:
If it doesn't need to be in core, in certainly has zero need to be in
contrib and can push to pgFoundry.
One advantage of having it in contrib is buildfarm testing, as indeed we
already found out ... although it's true that *keeping* it there now
that
On Wed, 2007-10-10 at 12:08 -0400, Bruce Momjian wrote:
The results have nothing to do with whether the process was followed.
We do not ignore process violations just because the outcome was OK.
And Jan did not come even close to following procedure. He just asked
core if they would
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
(Assuming it's technically sound - I still haven't checked the actual
code, but I'm assuming it's Ok since Jan approved it)
I hadn't looked at it either, but here are a few things that need
review:
*
Ühel kenal päeval, K, 2007-10-10 kell 12:18, kirjutas Tom Lane:
Magnus Hagander [EMAIL PROTECTED] writes:
(Assuming it's technically sound - I still haven't checked the actual
code, but I'm assuming it's Ok since Jan approved it)
I hadn't looked at it either, but here are a few things that
Ühel kenal päeval, K, 2007-10-10 kell 11:06, kirjutas Joshua D. Drake:
On Wed, 10 Oct 2007 18:01:34 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED]
On Wed, 10 Oct 2007 18:01:34 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
On Wed, Oct 10, 2007 at 11:30:47AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I also agree with this. We have to pretend it isn't in /contrib
now,
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
If it doesn't need to be in core, in certainly has zero need to be in
contrib and can push to pgFoundry.
One advantage of having it in contrib is buildfarm testing, as indeed we
already found out ...
Ühel kenal päeval, K, 2007-10-10 kell 18:23, kirjutas Magnus Hagander:
On Wed, Oct 10, 2007 at 11:47:15AM -0400, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal
Joshua D. Drake [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] wrote:
Putting it in core or contrib means that when we change the snapshot
mechanics in 8.4 the same developer will be able to fix the module at
the same time (and find out if his changes break it at the same
time).
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, K, 2007-10-10 kell 12:18, kirjutas Tom Lane:
* Why is txid_current_snapshot() reading SerializableSnapshot rather
than an actually current snap as its name suggests?
Why is SerializableSnapshot going away ?
How will we do
Tom Lane wrote:
The proposed behavior of txid_current_snapshot would defeat any possibility
of such an optimization, because we'd have to keep around the xact's oldest
snapshot on the off chance that txid_current_snapshot would be called later
in the xact.
I think txid_current_snapshot should
Hello,
Well this certainly turned into something bigger than I thought it ever
would. The questions that come into play with this whole thread are
larger than just, the process wasn't followed, what do we do?
We obviously don't want to make life difficult for our sibling projects
such as Slony
On Oct 10, 2007, at 13:30 , Tom Lane wrote:
That could perhaps be
addressed by merging it into 8.4 before anyone does any snapshot
fixing,
but our track record on causing such things to happen in a particular
sequence isn't great ...
Granted, everyone's focused on the 8.3 branch right
Marko Kreen [EMAIL PROTECTED] writes:
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
* Why is txid_current_snapshot() excluding subtransaction XIDs? That
might be all right for the current uses in Slony/Skytools, but it seems
darn close to a bug for any other use.
...
But I agree,
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 10/10/07, Tom Lane [EMAIL PROTECTED] wrote:
* Why is txid_current_snapshot() excluding subtransaction XIDs? That
might be all right for the current uses in Slony/Skytools, but it seems
darn close to a
Joshua D. Drake [EMAIL PROTECTED] writes:
There are quite a few contributors that are upset that this whole
process went down the way that it did. I would say they are likely in
the majority versus the people that just want to leave it alone and
move on.
That means it is not complete.
On Wed, 10 Oct 2007 21:02:30 +0100
Gregory Stark [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
There are quite a few contributors that are upset that this whole
process went down the way that it did. I would say they are likely
in the majority versus the people
Looking at the discussion, I think we should just keep it in /contrib.
The code is tightly tied to our backend transaction system so there is
logic to have it in /contrib rather than pgfoundry. I do think we
should just move it into core for 8.4 though.
On Wed, 10 Oct 2007 17:10:17 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Looking at the discussion, I think we should just keep it
in /contrib. The code is tightly tied to our backend transaction
system so there is logic to have it in /contrib rather than
pgfoundry. I do think we
Marko Kreen [EMAIL PROTECTED] writes:
Could you describe bit more? The is_visible_txid() works
on data returned by txid_current_snapshot()? How can there
be any subtrans id's if txid_current_snapshot() wont return
them?
Ah, I see: txid_current() never reports a subxact ID so there's no need
Florian Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think txid_current_snapshot should read ActiveSnapshot. If the user wants
to get a beginning-of-xact rather than beginning-of-statement snapshot from
it, he should be required to call it in a serializable transaction.
Hm... does txid
Ühel kenal päeval, K, 2007-10-10 kell 10:10, kirjutas Joshua D. Drake:
On Wed, 10 Oct 2007 18:33:03 +0300
Marko Kreen [EMAIL PROTECTED] wrote:
Considering the core operations are now being in active use
some 6-7 years, I really fail to see how there can be anything
to tweak, unless you
Ühel kenal päeval, K, 2007-10-10 kell 17:17, kirjutas Tom Lane:
Marko Kreen [EMAIL PROTECTED] writes:
Could you describe bit more? The is_visible_txid() works
on data returned by txid_current_snapshot()? How can there
be any subtrans id's if txid_current_snapshot() wont return
them?
On Thu, 11 Oct 2007 01:43:16 +0300
Hannu Krosing [EMAIL PROTECTED] wrote:
AH, now I see it , and I think I understand your concerns better ;)
this statement is obvious naivety.
Then you should not feel threatened by including this in contrib
Please do not mistake my concerns for
On 10/10/2007 12:08 PM, Bruce Momjian wrote:
The results have nothing to do with whether the process was followed.
We do not ignore process violations just because the outcome was OK.
Agreed. But reversing something that came out OK for no other reason
than that the process was violated? I
Tom Lane wrote:
Florian Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think txid_current_snapshot should read ActiveSnapshot. If the user
wants to get a beginning-of-xact rather than beginning-of-statement
snapshot from it, he should be required to call it in a serializable
transaction.
Tatsuo Ishii wrote:
I don't undrestand why the txid stuff is in 8.3beta(this is an unsual
case right?), but if we decide to keep it, please consider updating
release.sgml. Bruce explained me that release.sgml will not be updated
until the official release, but this is the unusual case and we
I don't undrestand why the txid stuff is in 8.3beta(this is an unsual
case right?), but if we decide to keep it, please consider updating
release.sgml. Bruce explained me that release.sgml will not be updated
until the official release, but this is the unusual case and we need to
break the rule, I
The results have nothing to do with whether the process was followed.
We do not ignore process violations just because the outcome was OK.
Agreed. But reversing something that came out OK for no other reason
than that the process was violated? I know you don't, but some people
are
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Uh, it *was* after beta1.
Oh, so it didn't hold up beta1 --- that's good.
--
Bruce
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Uh, it *was* after beta1.
Oh, so it didn't hold up
Andrew Dunstan wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers
discussion.
Uh, it *was* after beta1.
Andrew Dunstan wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Uh, it *was* after
Jan Wieck wrote:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Doing it the way you did with no warning, right before beta, and then
leaving is the worse of all times. I am surprised we are not
Bruce Momjian wrote:
Andrew Dunstan wrote:
Can somebody please explain to me what beta means if you can commit new
stuff after it has been declared?
We allow /contrib to be more lax about beta changes.
I think we should be looking long and hard at that. I can't see any
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Uh, it *was*
Bruce Momjian wrote:
Can somebody please explain to me what beta means if you can commit new
stuff after it has been declared?
We allow /contrib to be more lax about beta changes.
Why? When people were complaining about not being able to use TSearch
because their ISPs wouldn't install
Dave Page wrote:
Bruce Momjian wrote:
Can somebody please explain to me what beta means if you can commit new
stuff after it has been declared?
We allow /contrib to be more lax about beta changes.
Why? When people were complaining about not being able to use TSearch
because their
Magnus Hagander wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers
discussion.
Uh, it *was*
On 10/9/2007 1:06 AM, Bruce Momjian wrote:
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
Bruce Momjian wrote:
Dave Page wrote:
Bruce Momjian wrote:
Can somebody please explain to me what beta means if you can commit new
stuff after it has been declared?
We allow /contrib to be more lax about beta changes.
Why? When people were complaining about not being able to use TSearch
Bruce Momjian wrote:
Dave Page wrote:
Bruce Momjian wrote:
Can somebody please explain to me what beta means if you can commit new
stuff after it has been declared?
We allow /contrib to be more lax about beta changes.
Why? When people were complaining about not being able to use TSearch
On 10/9/2007 4:22 PM, Bruce Momjian wrote:
Jan Wieck wrote:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Doing it the way you did with no warning, right before beta, and then
leaving is the worse
Jan Wieck wrote:
On 10/9/2007 4:22 PM, Bruce Momjian wrote:
Jan Wieck wrote:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Doing it the way you did with no warning, right before beta, and then
On 10/9/2007 5:13 PM, Bruce Momjian wrote:
Jan Wieck wrote:
On 10/9/2007 4:22 PM, Bruce Momjian wrote:
Jan Wieck wrote:
I don't see how timing has anything to do with this. You could have
added it between beta1 and beta2 after sufficient hackers discussion.
Doing it the way you did
On Tue, 2007-10-09 at 17:13 -0400, Bruce Momjian wrote:
I go back to my original question, do you understand the process that
has to be followed for patch submission/application, and that it
applies to all of us, including you?
I think you're braking a little hard here. Nothing bad has
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member :-) ) is that Core is an
administrative group, not a group of committers. Some members of Core
are committers, some not, some committers are in Core,
On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member :-) ) is that Core is an
administrative group, not a group of committers. Some members of Core
On Tue, 09 Oct 2007 17:55:48 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member :-) ) is that Core is an
administrative group, not a group of
Andrew Dunstan wrote:
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member :-) ) is that Core is an
administrative group, not a group of committers. Some members of Core
are committers, some
Simon Riggs wrote:
On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member :-) ) is that Core is an
administrative group, not a group of committers.
On Wed, 2007-10-10 at 00:19 +0200, Magnus Hagander wrote:
Simon Riggs wrote:
On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member :-) ) is
Simon Riggs wrote:
On Wed, 2007-10-10 at 00:19 +0200, Magnus Hagander wrote:
Simon Riggs wrote:
On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member
Simon Riggs wrote:
On Tue, 2007-10-09 at 17:55 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
That close to
release, only Core members should be doing that and Jan is Core.
My understanding (not being a member :-) ) is that Core is an
administrative group, not a group
On Tue, Oct 09, 2007 at 01:06:11AM -0400, Bruce Momjian wrote:
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
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the patch and requiring that the patch go through the formal
review
process.
I have no opinion as to the patch itself (other than the fact that
it's a not bug fix), but I think this patch should be
On Tue, 9 Oct 2007 18:35:52 -0500
Michael Glaesemann [EMAIL PROTECTED] wrote:
On Oct 9, 2007, at 0:06 , Bruce Momjian wrote:
I am surprised we are not backing
out the patch and requiring that the patch go through the formal
review
process.
I have no opinion as to the patch
Hi,
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
IMO, the patch is reverted, and submitted for 8.4 or pgfoundry.
That means another delay for improving PostgreSQL replication.
I think we are all pretty sure that Jan knows what he is doing -- he has
involved in replication issues
On Tue, 2007-10-09 at 16:50 -0700, Joshua D. Drake wrote:
I think this almost says it all. My particular gripe about this whole
thing is that there are other features that are not too intrusive (or
appear so anyway) that are easily more useful that are not being
considered at all. Namely,
1 - 100 of 110 matches
Mail list logo
