On Sat, 8 Jun 2002, Bruce Momjian wrote:
> It is the idea were are supposed to go into beta with a bug-free release
> that bother me.
But its you that's always tried to advocate that ... no? If not, then I
am confused, cause I know *I've* never ... to me, switching to beta mode
has always been
Marc G. Fournier wrote:
> On Sat, 8 Jun 2002, Bruce Momjian wrote:
>
> > Yes, but there is a downside to this. We have trouble enough figuring
> > out if a patch is a "feature" or "bug fix" during beta. How are people
> > going to decide if a feature is "big" or not to work on during August?
>
On Sat, 8 Jun 2002, Bruce Momjian wrote:
> Yes, but there is a downside to this. We have trouble enough figuring
> out if a patch is a "feature" or "bug fix" during beta. How are people
> going to decide if a feature is "big" or not to work on during August?
> It has a paralyzing effect on our
Tom Lane wrote:
> Uh guys ... what I *said* was:
>
> > I think we are planning to go beta in late summer (end of August, say).
> > Probably in July we'll start pressing people to finish up any major
> > development items, or admit that they won't happen for 7.3.
>
> By which I meant that in July
Uh guys ... what I *said* was:
> I think we are planning to go beta in late summer (end of August, say).
> Probably in July we'll start pressing people to finish up any major
> development items, or admit that they won't happen for 7.3.
By which I meant that in July we should start hounding anyo
Manfred Koizar wrote:
> On Fri, 7 Jun 2002 02:01:40 -0400 (EDT), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >I think it is inevitable that there be enough binary file changes the
> >pg_upgrade will not work for 7.3 --- it just seems it is only a matter
> >of time.
>
> As far as it concerns chan
On Fri, 7 Jun 2002 02:01:40 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>I think it is inevitable that there be enough binary file changes the
>pg_upgrade will not work for 7.3 --- it just seems it is only a matter
>of time.
As far as it concerns changes proposed by me, I'll (try to) pr
Marc G. Fournier wrote:
> On Fri, 7 Jun 2002, Bruce Momjian wrote:
>
> > I will say that I was disappointed by previous release delays and will be
> > more vocal about moving things forward than I have in the past.
>
> I don't know ... I kinda like being able to confidently say to clients
> that
On Fri, 7 Jun 2002, Bruce Momjian wrote:
> I will say that I was disapointed by previous release delays and will be
> more vocal about moving things forward than I have in the past.
I don't know ... I kinda like being able to confidently say to clients
that "the latest release is always the most
Marc G. Fournier wrote:
> On Fri, 7 Jun 2002, Bruce Momjian wrote:
> > > > I am concerned about slowing down too early. We did that in previous
> > > > releases and didn't get the beta focus we needed, and it was too
> > > > paralyzing on people to know what is to be slowed and what to keep
> > >
On Fri, 7 Jun 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Fri, 7 Jun 2002, Bruce Momjian wrote:
> >
> > > Tom Lane wrote:
> > > > Manfred Koizar <[EMAIL PROTECTED]> writes:
> > > > > No comment on a planned 7.3 timeframe? :-(
> > > >
> > > > I think we are planning to go beta in l
Marc G. Fournier wrote:
> On Fri, 7 Jun 2002, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > > Manfred Koizar <[EMAIL PROTECTED]> writes:
> > > > No comment on a planned 7.3 timeframe? :-(
> > >
> > > I think we are planning to go beta in late summer (end of August, say).
> > > Probably in July w
On Fri, 7 Jun 2002, Bruce Momjian wrote:
> Tom Lane wrote:
> > Manfred Koizar <[EMAIL PROTECTED]> writes:
> > > No comment on a planned 7.3 timeframe? :-(
> >
> > I think we are planning to go beta in late summer (end of August, say).
> > Probably in July we'll start pressing people to finish up
Tom Lane wrote:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> > what about WITHOUT OIDS? I know dropping the OID from some tables and
> > keeping it for others is not trivial, because t_oid is the _first_
> > field of HeapTupleHeaderData. I'm vaguely considering a few possible
> > implementatio
Tom Lane wrote:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> > No comment on a planned 7.3 timeframe? :-(
>
> I think we are planning to go beta in late summer (end of August, say).
> Probably in July we'll start pressing people to finish up any major
> development items, or admit that they won
Manfred Koizar <[EMAIL PROTECTED]> writes:
> No comment on a planned 7.3 timeframe? :-(
I think we are planning to go beta in late summer (end of August, say).
Probably in July we'll start pressing people to finish up any major
development items, or admit that they won't happen for 7.3. So we've
On Tue, 21 May 2002 11:53:04 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>The system tables that have OIDs will certainly continue to have OIDs.
That's clear. I should have written: "... rip out oids from tuple
headers of system tables."
>Ugh. While certainly we should have been using accessor
>
Manfred Koizar <[EMAIL PROTECTED]> writes:
> That was one of the possible solutions I thought of, unfortunately the
> one I'm most afraid of. Not because I think it's not the cleanest
> way, but I don't (yet) feel comfortable enough with the code to rip
> out oids from system tables.
The system
On Tue, 21 May 2002 09:57:32 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> what about WITHOUT OIDS? I know dropping the OID from some tables and
>> keeping it for others is not trivial, because t_oid is the _first_
>> field of HeapTupleHeaderData. I'm
Manfred Koizar <[EMAIL PROTECTED]> writes:
> what about WITHOUT OIDS? I know dropping the OID from some tables and
> keeping it for others is not trivial, because t_oid is the _first_
> field of HeapTupleHeaderData. I'm vaguely considering a few possible
> implementations and will invest more wo
On Thu, 02 May 2002 21:10:40 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> Is saving 4 bytes per tuple a "darn good reason"?
>
>[...] Now if
>we could get rid of 8 bytes in the header, I'd get excited ;-)
Tom,
what about WITHOUT OIDS? I know dropping
On Thu, 02 May 2002 21:10:40 -0400, Tom Lane wrote:
>Hmm ... that might work. Actually, we are trying to stuff *five*
>numbers into these fields: xmin, xmax, cmin, cmax, and a VACUUM FULL
>transaction id (let's call it xvac just to have a name). The code
>currently assumes that cmin is not inte
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Let me throw in one of my infamous wild ideas in an attempt to rescue
> my proposal: We have 4 32-bit-numbers: xmin, cmin, xmax, and cmax.
> The only case, where we need cmin *and* cmax, is, when xmin == xmax.
> So if we find a single bit to flag this
Tom,
thanks for answering.
On Thu, 02 May 2002 17:16:38 -0400, you wrote:
>The hole in this logic is that there can be multiple active scans with
>different values of CurrentCommandId (eg, within a function
>CurrentCommandId may be different than it is outside). If you overwrite
>cmin with cmax
Manfred Koizar <[EMAIL PROTECTED]> writes:
> (3d) t_xmin == t_xmax == current transaction. The tuple has been
> inserted and then deleted by the current transaction. Then I claim
> (but I'm not absolutely sure), that insert and delete cannot have
> happened in the same command,
> so t_cmin < t_c
Hi,
having been chased away from pgsql-novice by Rasmus Mohr, I come here
to try my luck :-) I'm still new to this; so please be patient, if I
ask silly questions.
There has been a discussion recently about saving some bytes per tuple
header. Well, I have the suspicion, we can eliminate 4 byt
26 matches
Mail list logo
