thread ordering, root last

thread ordering, root last

[Bud Rogers]

I just subscribed to the pgsql-hackers list.  Haven't yet made any changes
to group parameters, etc.  In the summary buffer the messages are arranged
in threads but in every case the root of the thread is listed last.  I have
seen this occasionally with other groups, but never quite so consistently.

Is this a problem with gnus, with the list, or with my setup?

R +[ 43: Adriaan Jouber] Re: [HACKERS] Loading binary data into the database
  +[ 33: Tom Lane      ] Re: [HACKERS] Loading binary data into the database
  +[ 36: Adriaan Jouber] Re: [HACKERS] Loading binary data into the database
  +[ 15: Tom Lane      ] Re: [HACKERS] Loading binary data into the database
  +[ 36: Adriaan Jouber] [HACKERS] Loading binary data into the database
  +[ 15: Hannu Krosing ] Re: [HACKERS] 8Ko limitation
  +[  7: Tom Lane      ] Re: [HACKERS] 8Ko limitation
  +[ 34: "Justin Hickey] Re: [HACKERS] 8Ko limitation
  +[ 14: Karel Zak     ] Re: [HACKERS] 8Ko limitation
  +[ 20: "Xavier ZIMMER] [HACKERS] 8Ko limitation
  +[ 46: Tom Lane      ] Re: [HACKERS] About these IPC parameters
  +[ 12: "Henry B. Hotz] Re: [HACKERS] About these IPC parameters
  +[ 24: The Hermit Hac] Re: [HACKERS] About these IPC parameters
  +[ 29: Peter Eisentra] Re: [HACKERS] About these IPC parameters
  +[ 16: Peter Eisentra] Re: [HACKERS] About these IPC parameters
  +[ 44: Tom Lane      ] Re: [HACKERS] About these IPC parameters
  +[ 36: Peter Eisentra] [HACKERS] About these IPC parameters
  +[ 23: Jan Wieck     ] Re: [HACKERS] About TOAST and indices
  +[  8: Tom Lane      ] Re: [HACKERS] About TOAST and indices
  +[ 33: Jan Wieck     ] [HACKERS] About TOAST and indices
  +[ 12: "Mikheev, Vadi] RE: [HACKERS] btree split logic is fragile in the presence of lar
  +[ 16: "Mikheev, Vadi] RE: [HACKERS] btree split logic is fragile in the presence of lar
  +[ 14: "Mikheev, Vadi] RE: [HACKERS] btree split logic is fragile in the presence of lar
  +[ 19: "Mikheev, Vadi] RE: [HACKERS] btree split logic is fragile in the presence of lar
  +[ 33: Tom Lane      ] Re: [HACKERS] btree split logic is fragile in the presence of lar ge index items
  +[ 22: "Hiroshi Inoue] RE: [HACKERS] btree split logic is fragile in the presence of lar ge index items
  +[ 37: Tom Lane      ] Re: [HACKERS] btree split logic is fragile in the presence of lar ge index items
  +[ 21: "Hiroshi Inoue] RE: [HACKERS] btree split logic is fragile in the presence of lar ge index items
  +[ 28: Tom Lane      ] Re: [HACKERS] btree split logic is fragile in the presence of lar ge index items
  +[ 16: Tom Lane      ] Re: [HACKERS] btree split logic is fragile in the presence of large index items
  +[  9: Thomas Lockhar] Re: [HACKERS] Geometry test broken
  +[ 23: Jan Wieck     ] [HACKERS] Geometry test broken
R +[ 19: The Hermit Hac] Re: [HACKERS] Hello PL/Python
R +[ 14: Tom Lane      ] Re: [HACKERS] Hello PL/Python
R +[ 22: Hannu Krosing ] Re: [HACKERS] Hello PL/Python
R +[ 30: Jan Wieck     ] Re: [HACKERS] Hello PL/Python
R +[ 14: Tom Lane      ] Re: [HACKERS] Hello PL/Python
R +[ 11: Karel Zak     ] Re: [HACKERS] Hello PL/Python
R +[ 31: Hannu Krosing ] Re: [HACKERS] Hello PL/Python
R +[ 21: "Henry B. Hotz] Re: [HACKERS] How PostgreSQL's floating-point hurts everyone
R +[  7: Thomas Lockhar] Re: [HACKERS] How PostgreSQL's floating-point hurts everyone everywhere
R +[ 11: Tom Lane      ] Re: [HACKERS] How PostgreSQL's floating-point hurts everyone everywhere
R +[ 68: Jan Wieck     ] Re: [HACKERS] How PostgreSQL's floating-point hurts everyone everywhere
R +[ 51: Thomas Lockhar] Re: [HACKERS] How PostgreSQL's floating-point hurts everyone everywhere
R +[ 48: Peter Eisentra] [HACKERS] How PostgreSQL's floating-point hurts everyone everywhere
  +[ 14: Larry Rosenman] [HACKERS] INET/CIDR types
  +[ 28: Larry Rosenman] Re: [HACKERS] mac.c
  +[ 14: Thomas Lockhar] Re: [HACKERS] mac.c
  +[ 18: Larry Rosenman] [HACKERS] mac.c
  +[  7: Larry Rosenman] [HACKERS] mac.c
  +[ 35: Larry Rosenman] Re: [HACKERS] my stupidity
  +[ 25: John McKown   ] Re: [HACKERS] my stupidity
  +[ 12: Larry Rosenman] [HACKERS] my stupidity
  +[ 30: Philip Warner ] [HACKERS] pg_dump with BLOBs UPDATED
  +[ 53: Peter Eisentra] Re: [HACKERS] pg_dump, libdump, dump API, & backend again
  +[ 73: Philip Warner ] [HACKERS] pg_dump, libdump, dump API, & backend again
  +[ 21: Jan Wieck     ] [HACKERS] PGLZ memory problems fixed
  +[ 27: Chris Bitmead ] Re: [HACKERS] Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)
  +[ 18: Tom Lane      ] Re: [HACKERS] Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)
  +[ 30: "Stephan Szabo] Re: [HACKERS] Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)
  +[ 31: Chris Bitmead ] Re: [HACKERS] Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)
  +[ 25: "Stephan Szabo] Re: [HACKERS] Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)
  +[ 27: Chris Bitmead ] Re: [HACKERS] Re: [GENERAL] PRIMARY KEY & INHERITANCE (fwd)
  +[ 15: Peter Eisentra] [HACKERS] Re: [PATCHES] locale changes
  +[ 75: Tom Lane      ] [HACKERS] Re: lost records --- problem identified!
  +[ 32: "Oliver Elphic] Re: [HACKERS] Shared library search paths
  +[ 41: Peter Eisentra] Re: [HACKERS] Shared library search paths
  +[ 10: Thomas Lockhar] Re: [HACKERS] State of RPMs
  +[ 23: Trond Eivind G] Re: [HACKERS] State of RPMs
  +[ 11: Thomas Lockhar] Re: [HACKERS] State of RPMs
  +[ 12: Trond Eivind G] Re: [HACKERS] State of RPMs
  +[  9: Thomas Lockhar] [HACKERS] State of RPMs
  +[ 14: Larry Rosenman] [HACKERS] Stupid Me...
  +[ 42: Jan Wieck     ] Re: [HACKERS] TOAST & vacuum
  +[ 25: Tom Lane      ] Re: [HACKERS] TOAST & vacuum
  +[ 23: Jan Wieck     ] [HACKERS] TOAST & vacuum
  +[ 35: Philip Warner ] Re: [HACKERS] TODO updates
  +[ 19: Tom Lane      ] Re: [HACKERS] TODO updates
  +[ 38: Philip Warner ] Re: [HACKERS] TODO updates
  +[ 20: Tom Lane      ] Re: [HACKERS] TODO updates
  +[ 26: Philip Warner ] Re: [HACKERS] TODO updates
  +[ 65: Tom Lane      ] Re: [HACKERS] TODO updates
  +[ 10: Tom Lane      ] Re: [HACKERS] TODO updates
  +[ 25: Philip Warner ] Re: [HACKERS] TODO updates
  +[ 57: Peter Eisentra] [HACKERS] TODO updates
  +[ 40: Mikhail Terekh] Re: [HACKERS] Untrusted PL/Tcl?
  +[ 33: Larry Rosenman] Re: [HACKERS] Update: mac.c update, patch now on ftp
  +[ 18: Thomas Lockhar] Re: [HACKERS] Update: mac.c update, patch now on ftp
  +[ 36: Tom Lane      ] Re: [HACKERS] Vaccuum allows read access?
  +[ 33: Jan Wieck     ] Re: [HACKERS] Vaccuum allows read access?
  +[ 10: Tom Lane      ] Re: [HACKERS] Vaccuum allows read access?
  +[ 13: The Hermit Hac] Re: [HACKERS] Vaccuum allows read access?
  +[ 14: Bruce Momjian ] Re: [HACKERS] Vaccuum allows read access?
  +[ 10: Alfred Perlste] [HACKERS] Vaccuum allows read access?
   [ 29: jtnix@my-deja.] ERROR: Relation 'pg_user' does not exist
   [ 21: Zardoz        ] Importing bool data


-- 
Bud Rogers <budr@sirinet.net>  http://www.sirinet.net/~budr/zamm.html

Re: thread ordering, root last

[Andreas Fuchs]

Today, Bud Rogers <budr@sirinet.net> wrote:
> I just subscribed to the pgsql-hackers list.  Haven't yet made any changes
> to group parameters, etc.  In the summary buffer the messages are arranged
> in threads but in every case the root of the thread is listed last.  I have
> seen this occasionally with other groups, but never quite so consistently.

> Is this a problem with gnus, with the list, or with my setup?

It's your setup, I think. It seems that you do message-ordering by
Subject string. Let's see now:

> R +[ 43: Adriaan Jouber] Re: [HACKERS] Loading binary data into the database
>   +[ 33: Tom Lane      ] Re: [HACKERS] Loading binary data into the database
>   +[ 36: Adriaan Jouber] Re: [HACKERS] Loading binary data into the database
>   +[ 15: Tom Lane      ] Re: [HACKERS] Loading binary data into the database
>   +[ 36: Adriaan Jouber] [HACKERS] Loading binary data into the database

And now:

[0]asf@dahaIM:~% echo "R" | char
82 52 122
[0]asf@dahaIM:~% echo "[" | char
91 5b 133
(char is a little hack I have written myself, which outputs the value
in bin, hex, oct of a character it reads from stdin)

As you can see, [ has a higher value than R, so the replies get sorted
in before the root. The same applies for Subjects that start with an
S, T, U, V, W or a { (-:

I suggest that you activate threading in Summary mode.

regards,
-- 
Andreas Stefan Fuchs                             in Real Life aka
asf@acm.org, asfuchs@gmx.at, asf@ycom.at         in NNTP and SMTP,
antifuchs                                        in IRCNet and
Relf Herbstfresser, Male 1/2 Elf Priest          in AD&D

Re: thread ordering, root last

[Bud Rogers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 831 bytes --]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On 29 Jul 2000, Andreas Fuchs wrote:
> 
> > I suspect that Bud Rogers has turned off threading in the summary
> > buffer, which, in connection with the messages being sorted by
> > Subject line, results in the problem he described. At least it looks
> > like it, right? (-8 
> 
> Quite possible that you're right.  Only Bud can tell...

Ahem.  Andreas is right.  I did have threading turned off in that group at
the time I fired off my hasty query.  Not sure how it happened, gremlins
maybe? 

Nevertheless, even with threading turned on, the root of the thread is
sometimes not listed first in my group summary buffer.  Next time I have a
real example, I'll post it.

-- 
Bud Rogers <budr@sirinet.net>  http://www.sirinet.net/~budr/zamm.html