Re: backslashes in 8.3.3 - Mailing list pgsql-general

From Brandon Metcalf
Subject Re: backslashes in 8.3.3
Date
Msg-id Pine.LNX.4.58L.0806241200050.9186@cash.us.nortel.com
Whole thread Raw
In response to Re: backslashes in 8.3.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: backslashes in 8.3.3
List pgsql-general
t == tgl@sss.pgh.pa.us writes:

 t> "Brandon Metcalf" <bmetcalf@nortel.com> writes:
 t> > t == tgl@sss.pgh.pa.us writes:
 t> >  t> Well, if your intent is to replicate 8.1's behavior, you should instead
 t> >  t> frob the other switch.

 t> > I now have
 t> >   escape_string_warning = off
 t> > and
 t> >   standard_conforming_strings = on
 t> > in postgresql.conf and things are back to how they were.  That is no
 t> > warnings and backslashes treated literally.

 t> Uh, no, that is certainly *not* the behavior you were getting in 8.1;
 t> 8.1's behavior corresponds to both switches off.

OK.  I'm confused.  With 8.1.5 we never had to do anything special
with backslashes.  When we upgraded to 8.3.3, backslashes in our
INSERTs caused problems until we turn _on_
standard_conforming_strings.

 t> > A related question, is it in any way possible that a control sequence
 t> > could have been sent from a client that caused a fast shutdown?  Our
 t> > server log shows a fast shutdown request last night, but nobody
 t> > manually issued such a request.

 t> Fast shutdown means something sent SIGINT to the postmaster.
 t> The only way I've heard for that to happen "accidentally" is
 t> if you normally launch the postmaster by hand in a way that
 t> leaves it attached to your terminal session --- then control-C
 t> in that session would SIGINT the postmaster.

That could have been it.


--
Brandon

pgsql-general by date:

Previous
From: Karsten Hilbert
Date:
Subject: Re: String Encoding Conversion Problem
Next
From: Jorge Godoy
Date:
Subject: Re: Probably been asked a hundred times before.