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.
>
>
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 kno
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.
>
>
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
> > 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
>
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 w
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
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
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 kno
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 f
Ü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
>
Ü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,
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...
"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
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
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 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
"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 comp
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
>
"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 ag
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 now,
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
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 re
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
"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 sam
Ü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 i
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 fo
Ü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 <[EMA
Ü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 thi
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
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
>
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 o
"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
t
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 wi
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 ther
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 s
"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, co
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 exis
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?
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
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
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
>
"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 st
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
Po
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
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
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 sho
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 expecte
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.
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:
> > 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.
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.
>
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 tha
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, bu
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, I
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
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.
Th
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 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 backi
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 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 com
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 form
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 ver
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)---
T
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 a
> > > > > 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
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
Ü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
> > > comp
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 o
> > > 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
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 commented in that thread. I agree
that we broke
Hi,
On Wed, 2007-10-10 at 06:25 +0300, Hannu Krosing wrote:
> Should packagers be concerned with /contrib at all ?
IMHO, yes. We (PGDG RPMs) ship contrib modules with a separate RPM, in
case someone wants to use it.
> Arguably, a good packager should make its own decisions about what to
> includ
On Wed, 10 Oct 2007 06:25:49 +0300
Hannu Krosing <[EMAIL PROTECTED]> wrote:
> As noted before /contrib is a technical way of ensuring that something
> gets updated together with core, not a recommendation to include it
> in a "package".
>
> Arguably, a good packager should make its own decisions
Ühel kenal päeval, T, 2007-10-09 kell 22:36, kirjutas Stefan
Kaltenbrunner:
> 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 w
Andrew Dunstan wrote:
>
>
> Devrim G?ND?Z wrote:
> > What we should to do is to prevent such things happening in the future,
> > rather than reverting this patch and delaying replication issues.
> >
> >
> >
>
> The next time the same sort of argument will be made. The way to prevent
> it in
Devrim GÜNDÜZ wrote:
What we should to do is to prevent such things happening in the future,
rather than reverting this patch and delaying replication issues.
The next time the same sort of argument will be made. The way to prevent
it in future is not to allow it now.
One of the thing
On Tue, 09 Oct 2007 17:07:29 -0700
Neil Conway <[EMAIL PROTECTED]> wrote:
> 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 an
On Tue, 09 Oct 2007 17:04:41 -0700
Devrim GÜNDÜZ <[EMAIL PROTECTED]> 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.
>
> That means another delay for improving PostgreSQL replication.
No. It can go on
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,
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 f
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 t
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 rever
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 o
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
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 unde
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 b
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
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 c
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,
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
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, s
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 happ
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 yo
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
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 wo
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
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
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. Tha
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
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
> bec
1 - 100 of 109 matches
Mail list logo
