Port Bug Report: No primary key possible with type reltime & timestamp

Updated TODO item:

* Creating index of TIMESTAMP & RELTIME fails, rename to DATETIME(Thomas)

Use timespan and datetime instead. They are better supported; perhaps
in the next release "reltime" and "timestamp" will simply be aliases
for them...

- Thomas

Porting:
1) Seems like -O0/-O1 works best for this machine. It appears u get
spin lock errors/timeouts if i optimize at -O3, and -O2

2) in nabstime.h, the typedefs AbsoluteTime & RelativeTime ( was that
Absolutetime & Relativetime ) should be kept at a fixed ( for all ports
) size like int32. Adjusting it to what ever size time_t becomes leads
to problems with 'signed' words v. 'non-signed' extended longwords. For
instance the constant 0x80000001 is a negative 32bit integer, but as a
time_t it just a large positive number!.

3) Having problems with sign extension also creates problems for '@ 3
seconds ago'::reltime. see #2

4) You dont store reltime or abstime as 64bit's into the db. Are there
any plans to use 64bit alpha/linux timevalues as reltime & abstime ?
maybe reltime64 & abstime64? whats the sql world doing with 'seconds
since 1970' if the year is > 2038 ( which is the 32bit signed overflow )
?

5) having $(CC) -mieee all over just isn't good, particular if no float
operations are done. It slows down everthing. Is there a way to limit
this in the makefile?
gat

BTW these are porting issues ( but as well hacking issues ).

Yes, the 6.5.1 code will use:

CFLAGS:-O -mieee # optimization -O2 removed because of egcs problem
OK, the real problem is that we are using "magic" values to mark certain
values, and this is not done portably. Can you suggestion good values?
Can you send over a patch?
What does that flag do, and where would it be needed or not needed?

Well, a reply, anyway

1) reltime & abstime values are stored in the DB as 4 byte values. The
definitions for abstime&reltime are also stored in the DB ( this from empiracle
debugging ) . If you do not plan to embrace the notion of #of seconds >
2^(32-1), and you dont want to alter the DB notion that storage is 4 bytes then

typedef int32 Absolutetime;
typedef int32 Relativetime;

would appear to be most preferable & more stable (majic #'s work ) than

typedef time_t Absolutetime;
typedef time_t Relativetime;

This is not a complete solution , as there are still some sign extension
problems as demonstratable by the regression tests.
If you want to use 64bit Absolutetime & reltimes, then you should adjust (
or make more abstract ) the concept of abstime&reltime. BUT
THIS IS NOT A PORTING ISSUE! I would just like to get the abstime*reltime to
behave much like the 32bit folks.

2) Can u add HAS_LONG_LONG to $(CFLAGS)
I dont have long long, but it turns on some code ( somewhere ) that fixes
another problem.

3) -mieee informs the egcs compiler fot the alpha to inject 'trapb'
instructions at various places in a floating point computation. The trapb is a
pipeline stall forcing the processor to stop issueing instructions until all
current instructions in the pipeline have executed. This is done to capture a
possible 'fault' at a resomable time so you can backtrack to the instruction
that faulted and take some corrective measure. There are also rules for
backtracing, and repairing. The usage of -mieee inserted these trapb's all over
the place. The current egcs compiler appears to do a better job at it For
purely int operations, then a module need not be enhanced by the -mieee switch.

4) I'd give u some patches, but still getting the regression tests to work.
Where do I get 6.5.1, so I can work with that as a base

5) What is the floating point rounding set to ( up/down ). There seems to be an
extra digit of precision in ur i386, where the alpha port appears to round up (
and have 1 digit less :( )

gat

Bruce Momjian wrote:

Makes sense. Using time_t does not make sense if we are forcing
everything to 4 bytes.
Check configure. It runs a test to see if long long works, and sets that
in include/config.h.
I am stumped on why we even need -mieee, but someone supplied a patch to
add it.
Go to ftp.postgresql.org, and get the "snapshot". That will be 6.5.1 on
July 19th.
Not sure where that is set. Would be fpsetround() on BSD/OS, however, I
don't see us setting it anywhere, so my guess is that we are using the
OS default for this.

1) The reason why for -mieee is that if u care for some of the 'rare' floating point
exceptions ( as defined by alpha floating point hardware ) then u want to handle
them - as per ieee specifications to give u the correct ieee result. When the
processor cant handle the exceptions it (can ) traps to software assist routines
( hidden in the kernel ). But in order for the kernel to fix the exception u have to
stop the pipeline as close to the problem, so u can backtrace the user pc ( which is
by now quite a few instructions ahead of where the exception occured ) to the point
where it occured to see what register needs to have the correct value inserted.
Without the -mieee, the compiler will not arrange the float operations so that
it can be backstepped when a fault occures. The kernel then cannot fix the problem,
and forces a floating point exception onto the program. Death usually follows.
Therefor only do -mieee where u need to. ERGO can this flag be set individually
as per each individual makefile, and not as per ./configure ?
2) Then I want to report a bug - HAS_LONG_LONG in one of the 'c' files needs to be
turned on - I think there is only one - also for RH6.0/alpha. I dont think that
RH6.0/alpha has long long as a type and just uses long to define a 64bit quantity
3) Then can I presume that Absolutetime/Relativetime in nabstime.h will be changed
to int32?

Bruce Momjian wrote:

Add 'set -x' to configure, and figure how how the test is working in
configure. Look at the configure output. It shows how it is setting
those flags.
Added to TODO:

* Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports

In the regression test rules.sql there is this SQL command

update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;

Which causes my alpha port to go core. The above line can be reduced to:

update rtest_v1 set a = rtest_t3.a + 20 ;

which also causes the same problem. It seems that the 64 bit address
((Expr*)nodeptr)->oper gets truncated ( high 32 bits ) somewhere along the way.

I was able to locate the errant code in rewriteManip.c:712. but There seems to be a
bigger problem other than eraseing the upper 32bit address. It seems that
FindMatchingNew() returns a node of type T_Expr, rather than the expected type of
T_Var. Once u realize this then u can see why the now MISCAST "(Var *)
*nodePtr)->varlevelsup = this_varlevelsup" will cause a problem. On my alpha this erases
a portion in the address in the T_Expr. On the redhat 5.2/i386 this code seems to be
benign, BUT YOU ARE ERASEING SOMETHING that doesn't belong to to T_Expr !

So what gives?
gat
Maybe an assert() will help in finding some of the miscast returned types? Wuddya think?
sure would catch some of the boo-boo's hanging around

rewriteManip.c:
if (this_varno == info->new_varno &&
this_varlevelsup == sublevels_up)
{
n = FindMatchingNew(targetlist,
((Var *) node)->varattno);
if (n == NULL)
{
if (info->event == CMD_UPDATE)
{
*nodePtr = n = copyObject(node);
((Var *) n)->varno = info->current_varno;
((Var *) n)->varnoold = info->current_varno;
}
else
*nodePtr = make_null(((Var *) node)->vartype);
}
else
{
*nodePtr = copyObject(n);
((Var *) *nodePtr)->varlevelsup = this_varlevelsup; /* This
line zaps the address */
}
}

Yeah. This was reported by Pedro Lobo on 11 June, and we've been
patiently waiting for Jan to decide what to do about it :-(

You could stop the coredump by putting a test into ResolveNew:

{
*nodePtr = copyObject(n);
+ if (IsA(*nodePtr, Var))
((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
}

but what's not so clear is what's supposed to happen when the
replacement item *isn't* a Var. I tried to convince myself that nothing
needed to happen in that case, but wasn't successful. (Presumably the
replacement expression contains no instances of the variable being
replaced, so recursing into it with ResolveNew shouldn't be needed
--- but maybe its varlevelsup values need adjusted?)

regards, tom lane

That someone would be me. :) I supplied a patch to add about a
year ago as that was the only way I could get some of the date/time code
work correctly. If it is needed anywhere anymore, then it is down in
src/backend/util/adt, as that is where the datetime code is/was that were
causing FPEs to occur on regression testing. Without that flag, the
datetime code used to blow up all over the place. Might be worthwhile to
try removing it, recompiling, and running regression tests to see if it
needed anymore. That, and fixing the datetime code so it is not needed in
the first place (if it is still needed).
The biggest problem area for pgsql on Linux/Alpha at the moment is
in the datetime code, including what reltime and abstime regression tests
exercise.
If anyone wants me to test pgsql patches on Alpha, feel free to
send them my way, and I will give them a test on my XL366 Alpha running
Debian 2.1.
TTYL.

----------------------------------------------------------------------------
----------------------------------------------------------------------------

Thats NOT THE PROBLEM.
Although u have localize the -mieee/float in the date stuff, u have needlessly
inflicted the -mieee switch on ALL compiled modules.
I would have prefered it to be makefile ( Certainly on a SUBSYS.o, and even better on
on a per module.o) compile under a makefile switch
ie: ( or something simular )

if eq($(CPUID),alpha)
myfloat.o: myfloat.c
$(CC) $(CFLAGS) -mieee myfloat.c -o myfloat.o
fi


Ryan Kirkpatrick wrote:

OK, I have added code in utils/adt/Makefile as:

# seems to be required for some date/time stuff 07/19/1999 bjm
ifeq ($(CPU),alpha)
CFLAGS+= -mieee
endif

This is in the current tree, not 6.5.1. Please test and let me know if
this helps. I also added a Makefile-visible variable called CPU. Seems
we really don't have such a variable already available in the
Makefile-scope.

I imagine that this flag is specific to the compiler. It would
probably be best to leave it to patches until the alpha issues are
solved for every OS environment; sorry I don't have a platform myself
to test on.

btw, RedHat is interested in doing a maintenance release of Postgres
rpms, and would dearly love to have the Alpha port problems solved (or
vica versa; they hate that their shipping rpms are broken or not
available on one of their three supported architectures).

Uncle G, could you tell us the actual port string configure generates
for your platform? At the moment, PORTNAME on my i686 box says
"linux", and I don't see architecture info. But perhaps we can have
configure deduce an ARCH parameter too? It already knows it when first
identifying the system...

- Thomas

Well, in order to do this properly for linux/alpha & the egcs compiler u
need to know more, or realize more on the dangers of casting. Please
note that I haven't said improperly, blithely, or arbitarily. Things
just happen in the alpha if things are not properly casted. In the case
of postgres this happens to be a (major) problem with function calls &
function parameters. I have fixed just enough to get the regression
tests to work.
BTW I'd really love to have a redhat 6.0/alpha cd but not at the going
price of $79.00
What is PORTNAME. i ( as well as others ) use uname.

I heard that Costco (a discounting volume retailer) has the grey-box
(MacMillan?) version of RH6.0 for $25...
It is defined in src/Makefile.global. We would need to be able to
check for both OS (linux) and architecture (alpha); perhaps Bruce's
recent change to give a "CPU" variable is just what we need. I'll add
the PORTNAME check to the relevant Makefile.

If you can send patches for what you have changed, I can incorporate
them into an RPM for testing (built on a RH5.2-i686 box, but the
source rpm can be rebuilt on yours).

- Thomas

OK, I have made it:

ifeq ($(CPU),alpha)
ifeq ($(CC), gcc)
CFLAGS+= -mieee
endif
ifeq ($(CC), egcs)
CFLAGS+= -mieee
endif
endif

I can always rip it out later.

Great. I think that is closer to what is needed...

- Thomas

I did that originally to see if it would solve any other of the
problems that the regression tests were revealing at that time. Though, I
will admit it was a mistake to leave it as a global flag without more
research into if it helped anywhere or not. Unfortuntely, I got busy with
school about then and never got back to it. :(

----------------------------------------------------------------------------
----------------------------------------------------------------------------

Let me reiterate Thomas's comments on this. Alpha has been a very
bad port for us. I realize the problems are complex, but each alpha
person seems to know only 80% of what we need to get things working
100%. We get partial solutions to small problems, that just seem to
fix things long enough for current release. We had one release that
would not even initdb on alpha. We really need alpha folks to get their
noses to the grindstones and give us some solid causes/fixes to their
problems.

Ok,
I would have liked to have seen the fix to typedef time_t AbsoluteTime in
nabstime.h, rather than this, but i guess its some movement :-/

As per ur request, I am sending u ( bruce) my changed *.[ch] files from the
July 20 source ( they are not diffs ) . All the regressions tests work except
for geometry ( precision ? ) and Rules ( of which i will follow up (later)
with a question.

I u folks got any questions please let me know, As i'm sure that you will
have some.

Regarding the Test&set problems, u have to compile spin.c with -fno-inline.
i'd give u a makefile but i'm not sure how u folks are handling the
ifeq ($(OS), linux )
ifeq ($(CPU), alpha )
spin.o: spin.c
$(CC) $(CFLAGS) -c -fno-inline spin.c -o spin.o
endif
endif

I'm using -O3, and seems happy
gat

Bruce Momjian wrote:

Can I now put back optimization to -O2 on alpha? Please send me your
other diffs.

I dont know.
u seem to want to inflict -fno-inline on all modules, which was not my
fix for the test&set problem. I just wanted the -fno-inline to be set for
only spin.c, which is the only module on redhat linux/alpha to have this
particular problem.

Bruce Momjian wrote:

Can't really hurt to put it on all files in a directory. I hesistate to
put per-file flags. It is bad enough we are doing per-directory
flags. If you see any performance difference on per directory vs. per
file, I will change it, ok?

It is on our list. Too late to get that into 6.5.1:

* Make Absolutetime/Relativetime int4 because time_t can be int8 on some ports
I will not accept non-diff files. See tools/make_diff or use cvs diff.
Is this the kind of Alpha support I get? :-;

I have added to backend/storage/ipc/Makefile:

# seems to be required 1999/07/22 bjm
ifeq ($(CPU),alpha)
ifeq ($(CC), gcc)
CFLAGS+= -fno-inline
endif
ifeq ($(CC), egcs)
CFLAGS+= -fno-inline
endif
endif

Sounds great! Would you please send the changed *.[ch] files to me
(only, no need to echo to the rest of the list) as well, I would like to
try them out.
Also, if you don't feel like making diffs, I can make them (once I
get your changed filed) and send them back to Bruce.
Finally, we are getting somewhere on the Pgsql Linux/Alpha port!!!
:)

----------------------------------------------------------------------------
----------------------------------------------------------------------------

Ryan, I just sent you the diffs I received.

Got them, Thanks! I will check them out tomorrow and let you know
how I fair with them. TTYL.

----------------------------------------------------------------------------
----------------------------------------------------------------------------

Where are we on the Alpha port? Once we have some reasonable behavior,
I'd like to build some source RPMs which contain the patches. They do
not have to be applied to the main tree if that is premature, but once
they are put into a source RPM then Uncle G can build some binary RPMs
for Alpha and try them out.

RedHat will release new RPMs when the Alpha port works, since they're
anxious that the Alpha is supported...

As an aside, I've just posted Intel RPMs for v6.5.1 on

ftp://postgresql.org/pub/{RPMS,SRPMS}/*.rpm

- Thomas

I just bounced the alpha patch over to you, Thomas. If you like it, it
can be applied.

Great. But I'm looking for feedback from Ryan if he has a chance to
test it.

- Thomas

Sorry, I have been a bit busy over the weekend. I did get to test
it on Friday though. The patch applied flawlessly to that day's snapshot.
Though I quickly hit a minor, but annoying snag. The configure script
detects my XLT 366 Alpha's CPU as 'alphaev5', which means that none of the
alpha conditional clauses in the makefiles get evaluated correctly, and
one ends up with a binary that gets stuck spinlocks (when using -O2 for
CFLAGS).
I couldn't find anyway to tell make to look for alpha only at the
start of the CPU string (i.e. '$CPU =~ /^alpha.*/' in perl syntax), but
there might be one I missed. I simply ran configure, then edited
makefile.global, and changed 'alphaev5' to 'alpha' and complied as usual.
This time it worked great! No stuck spinlocks (and -O2 was used!),
and all the regression tests, saved for rules as Uncle G. has already
mentioned.
So, other than the CPU type detection problem, everything looks
very good. I have given postgres a decent work out, loading large data
sets (8 tables, 88k records), and then accessing via a web interface I am
writing for work, without any problems at all.
If no one minds, I will forward Uncle G.'s patches onto some
Debian-Alpha hackers that contacted me a while back about the status of
pgsql on alphas, and see what reaction they have to them.
TTYL.

----------------------------------------------------------------------------
----------------------------------------------------------------------------

Hmm. That can probably be worked around with an entry in
Makefile.custom, though I haven't looked at the specific usage.
Forwarding the patches is good. Is there anything in them which could
possibly damage a non-alpha machine? If not, and if they are on the
right track (they must be, since things actually work finally :) then
they should eventually end up in our main tree.

In glancing through the patches, I notice that one change is to pass
"Datum" to all ADT functions which take a char, int2, or int4. That
certainly makes the code uglier, but I can see that fudging the calls
as we did earlier might have led to trouble.

In the meantime, they could end up in Linux RPMs as patches to the
pristine distribution, and could be in new RPMs released through
RedHat. They will be very excited (or at least as excited as they
get... ;)

- Thomas

One thing I did forget to mention, is that I am getting a decent
handful of unaligned traps from postmaster. To put a number on that, from
running the regression tests three times, once with numeric_big enabled, I
got ~164 unaligned traps.
Not a show stopper, but something that probably needs to looked
into at some point in order to maximize performance of pgsql on Alphas.
I will pass the patches on to the Debian people and see what their
experience is with them. I know they have a handful of patches they
already apply to pgsql as it is (mostly reorganization of files I think),
so to add one more won't cause them too much more trouble for the time
being.
And something similar for the debian packages as well. I will make
sure the debian peple get the patches, though I will leave the
responsiblity of getting the patches to the redhat people to someone else.
:) TTYL.

----------------------------------------------------------------------------
----------------------------------------------------------------------------

Does it give you the location? I have already applied some alignment
cleanups to the current cvs tree.

When I sat down to send out Uncle G.'s patches to the debian
developers I realized that the patches really only apply to a moving
target. What I mean, is that they will only apply to current snapshots
(i.e. Jun 23's), but not to the older 6.5.1 release. By giving out these
patches, and telling them to just go and get a snapshot, they might end up
getting the snapshot on a day that pgsql is broken, or the patch will no
longer apply. The best solution I can think of is just to take one of the
snapshots (today's if it works, testing it now, otherwise last Fridays),
and setting it aside along with the patches in a seperate 'linux_alpha'
directory so packagers can have something "non-moving" to package for
thier distributions. Is this a good idea, or does someone have a better
one?

Also, I found at least a temporary solution to the problem of
alpha CPUs being detected as alphaev5, etc... and breaking the 'alpha'
makefile conditionals. Just add 'CPU:alpha' to the linux_alpha template.
Is there a reason that this would be a bad idea? I don't even really see
the reason why config.guess wants to differeniate between different alpha
CPUs in the first place?

----------------------------------------------------------------------------
----------------------------------------------------------------------------

I would try applying to 6.5.1, make any hand tweeks needed, and generate
a patch from that for 6.5.1.
Some optmizations are turned off in some Makefiles like
backend/utils/adt and backend/storage/ipc. Now that I think of it, you
can't send out patches for 6.5.1 because we don't have the alpha stuff
in there that was put in after 6.5.1. I think the current snapshot may
be safe for general use.

From what I can tell (i.e. via grep), the CPU variable is only
used to turn on/off the linux/alpha specific makefile rules that have been
added recently. Now, in the future that might change, and there be
optimizations only for a certain level of alpha chip, which the templates
hack could break. Of course, we could just deal with the problem when we
reach it, since it will not be difficult to undo the templates hack and
come up with another way to detect CPU type at the makefile level.
That is what I figured out when the diff between 6.5.1 and
Friday's snapshot came out at about 3.5MB. The time required to backport
the linux/alpha patches to 6.5.1 would be better spent else where.
I just grabbed today's snapshot, patches applied fined, compiled
and ran regression tests with no problems. Also, the regression tests only
generated 20 unaliagned traps this time, which is a reduction from earlier
(I think).
As for distribution packages, we want to get pgsql packages for
alpha with these patches out there so people can pound on them before we
roll the patches into the cvs tree for a formal release. That way,
anything still lingering would be found soon, rather than later. Of
course, we would want the packages to say clearly that they are beta or
preliminary version only, and so don't use for mission critical operations
until one has tested it out.
Anyway, I will make a set of patches on today's snapshot that
includes Uncle G's, and clean up of the linux_alpha template file (setting
-O2 again, and the CPU define), and then post that here to be forwarded on
to package developers by the respective people (I will get them to the
debian people). Also, either a copy of today's snapshot needs to be set
aside (on the ftp site) for applying these patches, or I will stick the
snapshot on my web site.
TTYL.

----------------------------------------------------------------------------
----------------------------------------------------------------------------

I'm disappointed that we won't have a set of patches for v6.5.1. Is
there any possibility of putting these patches into our REL6_5_PATCHES
branch to prepare for a v6.5.2 release? What in the current set of
patches would make this difficult? I believe that Tom Lane has been
pretty good about committing to that branch, and I don't know what
else might be missing.

I'm willing to try patching that branch if others could help with
testing (don't have an Alpha myself).

I've been trying to get things together so we can have a viable RPM
distribution of Postgres for Alphas. RedHat is interested, and I think
that it would help the Postgres cause. Does anyone else have this
specific interest, or should we just have them wait another 4 months??

Comments or suggestions?

- Thomas

OK, I don't want Thomas disappointed. We have the changes for alignment
I made, and some changes for optimization in certain places, and the
Uncle George patch, and the removal of the bad comment in the template
file.

My recommendation(hold on to your seats) is to take the current cvs
tree, patch it with Uncle George's patches and any others needed, and
release a 6.5.2 release that addresses alpha. We can back-patch 6.5.2,
but there is really no reason to do that. There is really nothing
'special' in the current tree. In fact, the most risky of them are the
alpha ones, and since that is what we are trying to fix, we are not
adding any new problems to the code.

I am working on some cache stuff, but that is not committed.
That is a long time.

OK. Another tack would be to do what you suggest on the main tree, and
then backpatch using diffs on the entire tree. Then we can release on
the v6.5.x branch as we would have liked.

I'll be happy to attempt the backpatching, and if I fail then we can
proceed with a v6.5.2 release based on the main tree. But I'm more
comfortable knowing that we've inspected every patch, and included
only those which address something significant.

Does this sound unrealistic? I'm guessing that the backpatching can
happen fairly easily, but I don't understand why someone just reported
3.5MB of diffs. Hmm, how much of those diffs are on the docs tree? I
did make a bunch of changes to get the man pages going, and they
aren't relevant for v6.5.2 which could be limited to the src/ tree.

- Thomas

Why not just use the current tree. What does backpatching the entire
tree do for us?
Oh, yes. I see. Good idea to just review the patches and see what is
involved. It is actually pretty easy to do that in one big patch.
Don't know.

I will leave you guys to the finer points of source tree
management (still learning all of the capablities of cvs myself).
I was the one who reported the 3.5MB of diffs. And yes, I did
check to see how many of them were docs, only about 20% of the total
diffs. :( I simply took an alpha patched snapshot from today and diffed it
against the 6.5.1 release (after removing all of the CVS directories from
the latter).
I still think that backpatching to create an "alpha" patch for
6.5.1 is a bad idea and a waste of time. It is also a waste of time for
distribution packagers who have deal with applying yet another patch to
the distribution source tree, and everything involved with that. Also,
there are those who just want to get the source and compile pgsql for
thier own use themselves, and many of them don't like having to mess with
patches. Overall, it just adds unnecessary work and complexity to the
release of a "Linux/Alpha Ready" version of pgsql.
IMHO a 6.5.2 release with all of the necessary alpha patches
already in the distribution source tree is a much cleaner, clearer
solution, for distribution packagers, average users, and
compile-it-yourself-people.
My two cents. TTYL.

----------------------------------------------------------------------------
----------------------------------------------------------------------------

I think he was going to generate a 6.5.2 by back-patching, not
distributing a new patch to make 6.5.2.

Yup.

OK, I'm trying to do this to help the Alpha folks, in such a way that
it helps the Alpha-linux-RH folks to get RPMs also. Having a 6.5.2
which does not run on Intel or Sparc does not help. Having a 6.5.2
which has diverged from the 6.5.x tree in unknown ways does not help.
Having us decide by consensus the appropriate model for s/w
development (main tree with changes progressing to a full release,
branch tree to carry maintenance changes) and then at the first
opportunity step away from that seems counterproductive in the
extreme. We ran into this same discussion during v6.4.x, and we're
doing it again.

If y'all can't maintain two branches, then let's stop doing it. otoh,
we can't do maintenance releases without a stable branch, so we'd
better think about it before giving up.

I've offered to help, much more than I should bother with. I'll leave
it to other Alpha stakeholders to decide what they want. I should
point out that I offered to our RedHat contacts to try to marshall an
Alpha-ready build, but so far it's like herding cats.

And *really*, if we have 3.5MB of diffs, who are we kidding about
knowing where they all came from and what they are doing? Backpatching
or developing patches on a clean 6.5.1 release is the only thing to do
for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
for RPMs.

My $0.03 ;)

- Thomas

OK, let's punt. If someone wants to develop an alpha-only patch for
6.5.1, they are welcome. We certainly had enought beta time to allow
Alpha people to address this. After the final minor release is just too
late. Sorry.

Okay, let me get this straight...v6.5 was in beta for, what, 2 months?
And it isn't until *after* v6.5.1 is released that the Alpha guys realized
that "oops, it doesn't work"? And they have a patch that amounts to ~1/2
the size of the current distribution to get this to work?

*rofl*

The stable branch is meant to allow *minor* changes to go into it, and, if
there are enough, to generate a new *stable* distribution. Minor changes
are "we put && instead of || in an if statement that only shows up #ifdef
<feature> is enabled"...or even where a bug is fixed that is based on us
missing an error check that adds a few lines of code.

I have no problems with building a v6.5.2, or .3, or .4, if required...but
a 3.5MB diff does not constitute a 'minor bug fix' and should be merged
into v6.6 only...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrap[email protected] secondary: scrappy@{freebsd|postgresql}.org

Yea, I think it has turned into a bit of a crazy mess. :) I had
meant to do something about Alpha for the 6.5 release, but it came too
soon after school got out to do anything (i.e. when I actually had free
time). Then Uncle G. came along, out of the blue, and fixed everything in
a few days, but then got impatient that we had not applied his patches
after a few more days and then moved on to other conquests. That left us
with patches that worked, which we were grateful for (at least I was), but
provided unknown affects on other platforms and only against an unstable,
in flux snapshot.
Then I tried to see how many differences there were between 6.5.1
and the current snapshot, only to find that the differences were "a lot".
Agreed. Uncle G's alpha patches alone break that as they are 62k
in size and touch quite a few files.
Yea, 3.5MB does not consitute a minor bug fix (maybe for M$ it
does, but lets not go there). And that includes all changes between 6.5.1
and the current snapshot, not just the alpha ones.

So, after reading the emails that arrived while writing my last
one... If I could get my hands on Bruce's alignment patches, then by
Monday, I should be able to have a set of alpha patches against 6.5.1 that
provide a working alpha version for the time being (until 6.6 comes around
and we can clean up the alpha patches and put them in the main tree).

PS. As far as I can tell, us Alpha guys are pretty few in number,
at least those who are actually subscribed to the pgsql-ports and
pgsql-hackers email lists and try and do something for pgsql on
Linux/Alpha. Unfortuntely this "Alpha guy" often finds himself very busy
and his C skills not up to the task of hunting down obscure platform bugs
in a huge mass of code. Something along the lines of "The spirit is
willing, but the flesh is weak." :(

----------------------------------------------------------------------------
----------------------------------------------------------------------------

I second this. In the last few months, PostgreSQL has really been
making progress in the mindshare area -- once, what was written off as
being unreliable, buggy, and slow, not to mention feature-lean, is now
being touted by many as "commercial quality", "the Free Software
equivalent to Oracle", "stable", "reliable", and "fast".

I'm all for having the latest and greatest snapshots working on the
Alpha -- Woo Hoo, etc, etc. I'm all for the current CVS tree building
like a champ on Alpha -- this is good stuff. HOWEVER, if there is a
need for a 6.5.x running on Alpha, then 6.5.1 needs to get the Alpha
patches (possibly a few other reliability patches -- but, keep the
number of patches down to a minimum -- this is still a 6.5.x release --
bug fixing only.) for a 6.5.2, where the advertised bugfixes include the
long-awaited Alpha patches.

For goodness sakes, Alpha is a major architecture -- this needs to be
done right. Make the number of possible variables a minimum -- let's
get a patch set working that applies to virgin 6.5.1. If backporting
and backpatching is required to do this, in the name of ROBUSTNESS -- by
all means -- let's do it.

(I say all this after Thomas had to "slap me around" a little -- I have
been getting the cart before the horse on some of the RPM issues, and
needed a good reminder of just what kind of software package I'm working
on! This is an RDBMS -- people will be using this for major data -- like
the guy from Australia who e-mailed here not long ago about 6.5 vs
6.4.2, and mentioned that his database had a few MILLION rows -- did
anybody catch the significance of that? (Wayne Pierkarski from
senet.com.au) Thanks for the wakeup call, Thomas.)

Thanks and kudos go the the guys who have made the Alpha port work --
now, let's get a patch set against 6.5.1 that works -- if that proves
too difficult, we'll just have to wait until pre-6.6, as Thomas already
said.

PostgreSQL is kicking major tuples -- let's keep it that way....

My 1.5 cents...

Lamar Owen
WGCR Internet Radio

Ok, you lost me on the terminology there then. What exactly is
'back-patching'?
I do follow your logic on a stable vs. unstable tree, and can see
the benefit of having it.
Yea, it has been like that with the Linux/Alpha port for some
time, including other packages then pgsql alone. :( As for the other Alpha
stakeholders, I have yet to hear from any of them at all in this
disscussion and for a while in any discussion concerning pgsql and
Linux/Alpha. Of course, every now and then, some Linux/Alpha user comes
along and asks why we haven't moved anywhere with pgsql in the last so
long, and gets mad with any answer I try and give them. My conclusion
about Linux/Alpha is that lots of people want the power of the alpha
processor, but don't want to help out and get rid of some of the lingering
sharp edges. They want it to work right out of the box! That leaves things
to a few of us die hards to get everything working, and most of them
focus on more fundamental things, like gcc and glibc, and the applications
end up getting the short end of the stick. Ok, I will get off my soap box
here, back to the trenches....
After this discussion and a few tests of my own, I think I had
better change my position on this issue.
First of all, today's snapshot with Uncle G's patches compiles and
runs on Linux/Intel and Solaris/Sparc as well as they do without the
patches on the same snapshot for the most part. Though the patches seem to
break the random regression test on Linux/Intel. Also, today's snapshot
(clean) will not compile on Solaris/Sparc, as there is an extra #endif in
./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
So, this snapshot is in suspect, and it looks like the alpha
patches are as well, at least as far as other platforms go.
My vote would be go back and do a 'alpha' patch off of 6.5.1, and
distribute that to the distribution people to get pgsql running on
Linux/Alpha in the short time. Then, four months or so down the road when
the next release target comes up, we plan to have a version of pgsql that
will run on both Alpha and other platforms. That means Uncle G's patches
need to be checked for what they do to the other platforms.
This would get us a Alpha ready version of pgsql now (there has
been enough delay as it is, we really don't want to wait any more), not
put us out on the limb with a possibly unstable release of pgsql, and
gives us time to get the alpha patches properly tested and integrated into
the main source tree.
As I see it, these are the following things that need to be added
to 6.5.1 to make it alpha ready:

* Uncle G's Alpha patches { which I have }.
* Makefile conditionals for Linux/Alpha { which I can find with
only moderate trouble }.
* Bruce's alignment patches { which I do not have }.

Bruce, if you could get me your alignment patches, then I will try and
apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
ready state. Then we give that patch to debian and RH developers, tell
them to only apply it to thier alpha builds, and that we will have a
universal source tree for all platforms (including alpha) in a few months.
This is simular to what was done (might even still be done) for
the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
got the clean source, a set of alpha patches for the same rev level, and
applied them to the clean source to generate an alpha ready kernel source
tree.
Is this a viable idea, or just another horrible kludge?
Raising the ante here? :) Well, then this was my four cents!

----------------------------------------------------------------------------
----------------------------------------------------------------------------