Обсуждение: FW: PGBuildfarm member snake Branch HEAD Status changed from OK to ContribCheck failure

Something broke snake again :-(. Looks like tsearch2 through the haze of
my Lemsip... I hate winter :-(

/D



> -----Original Message-----
> From: PG Build Farm
> [mailto:pgbuildfarm-web@hosting-two.commandprompt.com]
> Sent: 10 February 2006 02:20
> To: pgbuildfarm-status-chngs@pgfoundry.org;
> pgbuildfarm-status-green@pgfoundry.org
> Subject: PGBuildfarm member snake Branch HEAD Status changed
> from OK to ContribCheck failure
>
>
> The PGBuildfarm member snake had the following event on branch HEAD:
>
> Status changed from OK to ContribCheck failure
>
> The snapshot timestamp for the build that triggered this
> notification is: 2006-02-10 02:00:00
>
> The specs of this machine are:
> OS:  Windows / Server 2003 SP1
> Arch: i686
> Comp: gcc / 3.4.2
>
> For more information, see
> http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=snake&br=HEAD
>
>
>

On Feb 10, 2006, at 17:24 , Dave Page wrote:

> Something broke snake again :-(. Looks like tsearch2 through the  
> haze of
> my Lemsip... I hate winter :-(

Hope you feel better soon! I've been taking 1500 to 2000mg of vitamin  
C daily to try to stay healthy.

As for snake, I can't offer much.

Michael Glaesemann
grzm myrealbox com

***************
*** 2463,2469 ****  <a href="http://www.google.com/foo.bar.html" target="_blank">YES  </a>   ff-bg  <script>
!       document.write(15);  </script>  </body>  </html>
--- 2463,2469 ----   <a href="http://www.google.com/foo.bar.html" target="_blank">YES  </a>    ff-bg   <script>
!  \x09document.write(15);   </script>   </body>   </html>


\x09 is a '\t'.  Is it now prohibited(non-printable) symbol?



-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 

On 2/10/06, Dave Page <dpage@vale-housing.co.uk> wrote:
> Something broke snake again :-(. Looks like tsearch2 through the haze of
> my Lemsip... I hate winter :-(

AFAIR the reason for different length of psql's  '----' header lines
was database encoding being UNICODE not SQL_ASCII.  Can this be the case
there?

--
marko

On 2/10/06, Marko Kreen <markokr@gmail.com> wrote:
> On 2/10/06, Dave Page <dpage@vale-housing.co.uk> wrote:
> > Something broke snake again :-(. Looks like tsearch2 through the haze of
> > my Lemsip... I hate winter :-(
>
> AFAIR the reason for different length of psql's  '----' header lines
> was database encoding being UNICODE not SQL_ASCII.  Can this be the case
> there?

Oh, now I see it's everywhere.  Probably intentional change then.

--
marko

> -----Original Message-----
> From: Marko Kreen [mailto:markokr@gmail.com]
> Sent: 10 February 2006 15:07
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] FW: PGBuildfarm member snake Branch
> HEAD Status changed from OK to ContribCheck failure
>
> On 2/10/06, Dave Page <dpage@vale-housing.co.uk> wrote:
> > Something broke snake again :-(. Looks like tsearch2
> through the haze of
> > my Lemsip... I hate winter :-(
>
> AFAIR the reason for different length of psql's  '----' header lines
> was database encoding being UNICODE not SQL_ASCII.  Can this
> be the case
> there?

Oh, didn't spot those (barely functioning at all today though!).

No-one has even logged into Snake for a week or more though, so I would
still suspect a source change as the culprit.

Regards, Dave.

The failure, I think, it because of the newline patch we got for psql
yesterday.  I am seeking a diff from pgcrypto to fix it.  My openssl is
too old.

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

Dave Page wrote:
>  
> 
> > -----Original Message-----
> > From: Marko Kreen [mailto:markokr@gmail.com] 
> > Sent: 10 February 2006 15:07
> > To: Dave Page
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] FW: PGBuildfarm member snake Branch 
> > HEAD Status changed from OK to ContribCheck failure
> > 
> > On 2/10/06, Dave Page <dpage@vale-housing.co.uk> wrote:
> > > Something broke snake again :-(. Looks like tsearch2 
> > through the haze of
> > > my Lemsip... I hate winter :-(
> > 
> > AFAIR the reason for different length of psql's  '----' header lines
> > was database encoding being UNICODE not SQL_ASCII.  Can this 
> > be the case
> > there?
> 
> Oh, didn't spot those (barely functioning at all today though!). 
> 
> No-one has even logged into Snake for a week or more though, so I would
> still suspect a source change as the culprit.
> 
> Regards, Dave.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Bruce Momjian wrote:


>
> The failure, I think, it because of the newline patch we got for psql
> yesterday.  I am seeking a diff from pgcrypto to fix it.  My openssl is
> too old.

A side affect of this newline patch is that all fields are now filled with 
white space up to the displayed column width, even for the last (or only 
column). I guess this is somehow required for consistent display. Otherwise, 
it makes copy&paste from a psql session more painful, because of all the 
added white-space. I hope that psql output intended for script output using 
the available flags (i.e. not the "nice display" output) is unaffected?

Best Regards,
Michael Paesold 

On Fri, Feb 10, 2006 at 08:06:53PM +0100, Michael Paesold wrote:
> A side affect of this newline patch is that all fields are now filled with
> white space up to the displayed column width, even for the last (or only
> column). I guess this is somehow required for consistent display.
> Otherwise, it makes copy&paste from a psql session more painful, because of
> all the added white-space. I hope that psql output intended for script
> output using the available flags (i.e. not the "nice display" output) is
> unaffected?

My intention was to only change formatted output. Unformatted should be
unchanged from previous.

The extra spaces is an interesting side-effect. In the past it would
only have worked for the last column anyway, right?

Anyway, it is a fixable issue and I'd consider doing it if people think
it's worth it.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout wrote:

> On Fri, Feb 10, 2006 at 08:06:53PM +0100, Michael Paesold wrote:
> > A side affect of this newline patch is that all fields are now filled 
> > with
> > white space up to the displayed column width, even for the last (or only
> > column).
>
> My intention was to only change formatted output. Unformatted should be
> unchanged from previous.
>
> The extra spaces is an interesting side-effect. In the past it would
> only have worked for the last column anyway, right?

Right, my explanation was not correct. It should have been "the last column 
is now also filled with spaces". Of course all but the last column were 
always filled with spaces.

> Anyway, it is a fixable issue and I'd consider doing it if people think
> it's worth it.

I personally don't like the added spaces (feels inefficient), but that is 
only a matter of taste, so you can rather ignore it.
I am not sure about people who perhaps rely on the output format in scripts 
(even if it's bad to rely on that specific output format, because the output 
of psql can be changed to be more suitable for scripts). For multi-column 
output things have not really changed anyway.

Best Regards,
Michael Paesold 

Martijn van Oosterhout <kleptog@svana.org> writes:
> The extra spaces is an interesting side-effect. In the past it would
> only have worked for the last column anyway, right?

Of course.

> Anyway, it is a fixable issue and I'd consider doing it if people think
> it's worth it.

I think it would be a good idea to expect this patch to cause zero
change in psql output except in the cases where there are actually
control characters in the data.  Otherwise there are likely to be
complaints.  (I'm already unhappy at the prospect that this means
every single regression test's output has changed, even if diff
--ignore-space is hiding them.)

I'd settle for stripping trailing blanks on the last line of a multiline
field value, if that'd be any easier than stripping them for all lines.
        regards, tom lane

How do people feel about having tabs displayed as 0x09?  Should they be
a literal tab?

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

Teodor Sigaev wrote:
> ***************
> *** 2463,2469 ****
>    <a href="http://www.google.com/foo.bar.html" target="_blank">YES  </a>
>     ff-bg
>    <script>
> !       document.write(15);
>    </script>
>    </body>
>    </html>
> --- 2463,2469 ----
>     <a href="http://www.google.com/foo.bar.html" target="_blank">YES  </a>
>      ff-bg
>     <script>
> !  \x09document.write(15);
>     </script>
>     </body>
>     </html>
> 
> 
> \x09 is a '\t'.  Is it now prohibited(non-printable) symbol?
> 
> 
> 
> -- 
> Teodor Sigaev                                   E-mail: teodor@sigaev.ru
>                                                     WWW: http://www.sigaev.ru/
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> How do people feel about having tabs displayed as 0x09?  Should they be
> a literal tab?

If they're a literal tab they'll mess up the formatting that we just so
painstakingly put in.  I'd personally vote for \t rather than \x09, but
other than that I agree with doing something like this in formatted
psql output.

OTOH ... there's a rather nasty problem with this whole concept, which
is that you can't readily tell whether the data was a tab or the actual
string "\x09".  The only way to make it unambiguous would be to start
doubling backslashes, which I think is a complete nonstarter on
backwards compatibility grounds :-(
        regards, tom lane