Horton

Thread

  1. Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Kevin P. Neal <kpneal@pobox.com> — 2000-04-12T02:21:53Z

    Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
release 1.4.1. 

There are lots of problems with the oid handling, and I can't get it
to successfully even begin to do a make runcheck, make runtest, or
make bigtest. 

The results of a maketest are:
=============== Notes...                              =================
postmaster must already be running for the regression tests to succeed.
The time zone is set to PST8PDT for these tests by the client frontend.
Please report any apparent problems to ports@postgresql.org
See regress/README for more information.

=============== dropping old regression database...   =================
ERROR:  typeidTypeRelid: Invalid type - oid = 0
dropdb: database removal failed
=============== creating new regression database...   =================
ERROR:  createdb: database 'regression' already exists
createdb: database creation failed
createdb failed

Minimal patches are attached. They are enough to get 7.0 beta 3 up
and able to do minimal SQL queries. They are also required to get
it to build at all.
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

"You're a slacker if you only give 90% 'cause you are afraid of the \
  other 10%."    -- Ross Smith               Apr 22 1999 2:29am

  2. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-04-12T10:24:41Z

    On Tue, 11 Apr 2000, Kevin P. Neal wrote:

> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> release 1.4.1. 

*** ./old/src/include/storage/s_lock.h  Wed Jan 26 00:58:33 2000
--- ./new/src/include/storage/s_lock.h  Sun Apr  9 23:56:46 2000
***************
*** 260,270 ****
--- 260,275 ----
  #else /* i.e. not __osf__ */
  
  #define TAS(lock) tas(lock)
  #define S_UNLOCK(lock) { __asm__("mb"); *(lock) = 0; }
  
+ #if defined(__GNUC__)
+ static int              /* GCC on the Alpha doesn't appear to handle
+                            inlining of assembly with %0 or %1 properly.
*/
+ #else
  static __inline__ int
+ #endif
  tas(volatile slock_t *lock)
  {
   register slock_t _res;
  
  __asm__("      ldq   $0, %0                      \n\


Any chance you could write a configure test that exposes this deficiency
rather than assuming that every GCC on every Alpha now and in the future
will have it? What does "doesn't appear to handle properly" mean anyway?
Have you notified the GCC maintainers?

Also, whose idea was it to use '__inline__' instead of 'inline'?

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  3. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-04-12T16:26:11Z

    Yes, we can't apply this at this stage of the game.  Just too many
port-specific changes.


[Charset iso-8859-1 unsupported, filtering to ASCII...]
> On Tue, 11 Apr 2000, Kevin P. Neal wrote:
> 
> > Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> > release 1.4.1. 
> 
> *** ./old/src/include/storage/s_lock.h  Wed Jan 26 00:58:33 2000
> --- ./new/src/include/storage/s_lock.h  Sun Apr  9 23:56:46 2000
> ***************
> *** 260,270 ****
> --- 260,275 ----
>   #else /* i.e. not __osf__ */
>   
>   #define TAS(lock) tas(lock)
>   #define S_UNLOCK(lock) { __asm__("mb"); *(lock) = 0; }
>   
> + #if defined(__GNUC__)
> + static int              /* GCC on the Alpha doesn't appear to handle
> +                            inlining of assembly with %0 or %1 properly.
> */
> + #else
>   static __inline__ int
> + #endif
>   tas(volatile slock_t *lock)
>   {
>    register slock_t _res;
>   
>   __asm__("      ldq   $0, %0                      \n\
> 
> 
> Any chance you could write a configure test that exposes this deficiency
> rather than assuming that every GCC on every Alpha now and in the future
> will have it? What does "doesn't appear to handle properly" mean anyway?
> Have you notified the GCC maintainers?
> 
> Also, whose idea was it to use '__inline__' instead of 'inline'?
> 
> -- 
> Peter Eisentraut                  Sernanders v_g 10:115
> peter_e@gmx.net                   75262 Uppsala
> http://yi.org/peter-e/            Sweden
> 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  4. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-04-12T18:35:04Z

    "Kevin P. Neal" <kpneal@pobox.com> wrote:
>>>> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
>>>> release 1.4.1. 

Has anyone compared these to Ryan Kirkpatrick's efforts for Linux/Alpha?

			regards, tom lane

  5. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-04-14T23:48:18Z

    On Wed, 12 Apr 2000, Tom Lane wrote:

> "Kevin P. Neal" <kpneal@pobox.com> wrote:
> >>>> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> >>>> release 1.4.1. 
> 
> Has anyone compared these to Ryan Kirkpatrick's efforts for Linux/Alpha?

	I have not... I would glance over the patches if I could find them
(mailing list archive search turned up nothing or error messages). If some
one could forward them to me, I will give them a quick look over.
	Most of the Linux/Alpha patches have to do with replacing int8,
int16, int32, and absoluteTime (not sure on the spelling of the last) to
Datum when passing to functions. Not 100% what that does, but seems to
solve a number of data corruption problems in passing data through the
utility adt functions. I plan to figure out more specificly what is going
on, but first I need to graduate from college. :)

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

  6. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-06-12T20:56:11Z

    I am unsure how to address this NetBSD/alpha patch.


> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> release 1.4.1. 
> 
> There are lots of problems with the oid handling, and I can't get it
> to successfully even begin to do a make runcheck, make runtest, or
> make bigtest. 
> 
> The results of a maketest are:
> =============== Notes...                              =================
> postmaster must already be running for the regression tests to succeed.
> The time zone is set to PST8PDT for these tests by the client frontend.
> Please report any apparent problems to ports@postgresql.org
> See regress/README for more information.
> 
> =============== dropping old regression database...   =================
> ERROR:  typeidTypeRelid: Invalid type - oid = 0
> dropdb: database removal failed
> =============== creating new regression database...   =================
> ERROR:  createdb: database 'regression' already exists
> createdb: database creation failed
> createdb failed
> 
> Minimal patches are attached. They are enough to get 7.0 beta 3 up
> and able to do minimal SQL queries. They are also required to get
> it to build at all.
> -- 
> Kevin P. Neal                                http://www.pobox.com/~kpn/
> 
> "You're a slacker if you only give 90% 'cause you are afraid of the \
>   other 10%."    -- Ross Smith               Apr 22 1999 2:29am

[ Attachment, skipping... ]


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  7. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-12T21:15:41Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am unsure how to address this NetBSD/alpha patch.

I'd say leave it out for now.  After I finish the fmgr revisions we
ought to have a better shot at porting to Alphas.  I know most of
Ryan K's Linux/Alpha patches will go away with that.

I am only fifty or so functions away from updating everything that
accepts pass-by-value data types.  There are a lot of pass-by-reference
data types not touched yet, but I think that those should work anywhere
that sizeof(Datum) == sizeof(pointer), so the vast majority of the
fmgr-related porting problems should be gone at that point.  I will be
calling for port testers as soon as I commit those changes...

			regards, tom lane

  8. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-06-12T21:25:52Z

    That was my guess, though his changes were s_lock related. Seems that is
an Alpha mess too.


> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I am unsure how to address this NetBSD/alpha patch.
> 
> I'd say leave it out for now.  After I finish the fmgr revisions we
> ought to have a better shot at porting to Alphas.  I know most of
> Ryan K's Linux/Alpha patches will go away with that.
> 
> I am only fifty or so functions away from updating everything that
> accepts pass-by-value data types.  There are a lot of pass-by-reference
> data types not touched yet, but I think that those should work anywhere
> that sizeof(Datum) == sizeof(pointer), so the vast majority of the
> fmgr-related porting problems should be gone at that point.  I will be
> calling for port testers as soon as I commit those changes...
> 
> 			regards, tom lane
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  9. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-12T21:39:55Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:
> That was my guess, though his changes were s_lock related. Seems that is
> an Alpha mess too.

Yes, it sounds like we will need some help from a certified Alpha guru
to make spinlock code that works reliably on multi-CPU Alphas :-(.

Anyone have friends in the right places at DEC?

			regards, tom lane

  10. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Kevin P. Neal <kpneal@pobox.com> — 2000-06-13T03:17:45Z

    On Mon, Jun 12, 2000 at 05:39:55PM -0400, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > That was my guess, though his changes were s_lock related. Seems that is
> > an Alpha mess too.
> 
> Yes, it sounds like we will need some help from a certified Alpha guru
> to make spinlock code that works reliably on multi-CPU Alphas :-(.

If you leave the locking code as it is then PostgreSQL will dump core.

If you do not inline the locking code then the registers will not get
stomped (gcc bug), and PostgreSQL will function properly enough to 
initialize itself and make it through a make install. Simple SQL
queries work ok, but I never tried anything fancy. 

I haven't had the time to write up a test case to send to the GCC people.
Plus, the other (much larger) set of patches that a Linux/Alpha guy
wrote up did the same thing my patches did, but differently (-fno-inline
instead of patching the header file to not be __inline__).

The other change from me was to change the type for locks to be 32 bits
wide instead of 8 bits wide. All Alphas handle 32 bit quantities 
naturally, but only some can handle 8 or 16 bit quantities. The assembly
code tries to do locks with 32 bit quantities, it doesn't make sense to
then try to lock an 8 bit quantity. 


Guys, my patches are not complex. It doesn't take a guru to handle
my changes; otherwise I wouldn't have been able to write them.
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

"You know, I think I can hear the machine screaming from here...  \
'help me! hellpp meeee!'"  - Heather Flanagan, 14:52:23 Wed Jun 10 1998

  11. Re: Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-10-09T19:54:51Z

    I think this had been addressed.


> On Mon, Jun 12, 2000 at 05:39:55PM -0400, Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > That was my guess, though his changes were s_lock related. Seems that is
> > > an Alpha mess too.
> > 
> > Yes, it sounds like we will need some help from a certified Alpha guru
> > to make spinlock code that works reliably on multi-CPU Alphas :-(.
> 
> If you leave the locking code as it is then PostgreSQL will dump core.
> 
> If you do not inline the locking code then the registers will not get
> stomped (gcc bug), and PostgreSQL will function properly enough to 
> initialize itself and make it through a make install. Simple SQL
> queries work ok, but I never tried anything fancy. 
> 
> I haven't had the time to write up a test case to send to the GCC people.
> Plus, the other (much larger) set of patches that a Linux/Alpha guy
> wrote up did the same thing my patches did, but differently (-fno-inline
> instead of patching the header file to not be __inline__).
> 
> The other change from me was to change the type for locks to be 32 bits
> wide instead of 8 bits wide. All Alphas handle 32 bit quantities 
> naturally, but only some can handle 8 or 16 bit quantities. The assembly
> code tries to do locks with 32 bit quantities, it doesn't make sense to
> then try to lock an 8 bit quantity. 
> 
> 
> Guys, my patches are not complex. It doesn't take a guru to handle
> my changes; otherwise I wouldn't have been able to write them.
> -- 
> Kevin P. Neal                                http://www.pobox.com/~kpn/
> 
> "You know, I think I can hear the machine screaming from here...  \
> 'help me! hellpp meeee!'"  - Heather Flanagan, 14:52:23 Wed Jun 10 1998
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026