Re: Tom Lane 2017-08-13 <14677.1502638...@sss.pgh.pa.us>
> Christoph Berg writes:
> > Seems to be a gcc-7 problem affecting several packages on mips64el:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514
>
> Hm, unless there is a use of sigsetjmp earlier in that clamav
> routine, I wou
Re: Tom Lane 2017-08-13 <14517.1502638...@sss.pgh.pa.us>
> I suspect you could work around this with
>
> boolisCompleteQuery = (context <= PROCESS_UTILITY_QUERY);
> - boolneedCleanup;
> + volatile bool needCleanup;
> boolcommandCollected =
Christoph Berg writes:
> Seems to be a gcc-7 problem affecting several packages on mips64el:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514
Hm, unless there is a use of sigsetjmp earlier in that clamav
routine, I would not assume that that's the same issue. The bug
I suspect we are l
Christoph Berg writes:
> 10beta3 and 9.6.4 are both failing during initdb on mips64el on
> Debian/sid (unstable):
> All other architectures have succeeded, as well as the 9.6.4 build for
> Debian/stretch (stable) on mips64el. The difference might be the
> compiler version (6.3.0 vs 7.1.0).
It's h
Re: To PostgreSQL Hackers 2017-08-13
<20170813130127.g3tcyzzvuvlpz...@msg.df7cb.de>
> 10beta3 and 9.6.4 are both failing during initdb on mips64el on
> Debian/sid (unstable):
>
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0
> https
10beta3 and 9.6.4 are both failing during initdb on mips64el on
Debian/sid (unstable):
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0
https://buildd.debian.org/status/fetch.php?pkg=postgresql-10&arch=mips64el&ver=10%7Ebeta3-1&stamp=15
BRUSSER Michael writes:
> initdb failed
> FATAL: unexpected data beyond EOF in block 19 of relation base/1/2609
> HINT: This has been seen to occur with buggy kernels; consider updating your
> system.
> STATEMENT: COMMENT ON FUNCTION euc_jis_2004_to_shift_jis_2004
> (INTEGER, INTEGER, C
Hi,
One of our sites ran into a problem with database installation:
initdb failed
FATAL: unexpected data beyond EOF in block 19 of relation base/1/2609
HINT: This has been seen to occur with buggy kernels; consider updating your
system.
STATEMENT: COMMENT ON FUNCTION euc_jis_2004_to_shift_jis_20
Andrew Dunstan writes:
> On 12/13/2010 12:16 PM, BRUSSER Michael wrote:
>> Would it be a completely crazy idea if I try to modify Postgres to look at
>> some env. var
>> (similar to PGDATA) and if exists and path is valid look there for the
>> timezone files?
> Yes, that's only the first probl
On 12/13/2010 12:16 PM, BRUSSER Michael wrote:
Here is what you should do:
1. Build Postgres with --prefix set to some empty directory.
2. Run install.
3. Bundle up the resulting install tree as part of your tarball. Do not
editorialize upon the relative locations of its contents.
4. Drop the
Here is what you should do:
1. Build Postgres with --prefix set to some empty directory.
2. Run install.
3. Bundle up the resulting install tree as part of your tarball. Do not
editorialize upon the relative locations of its contents.
4. Drop the install tree wherever you want on the target machi
"BRUSSER Michael" writes:
> I'm not sure if our current approach would work with v8.4. This is what we do
> in the nutshell:
> - build Postgres
> - do not run install
> - collect all generated libraries, executables and input files and pack them
> along with other app
> - distribute the tar-ball
Excerpts from BRUSSER Michael's message of lun dic 13 12:34:49 -0300 2010:
> I'm not sure if our current approach would work with v8.4. This is what we do
> in the nutshell:
> - build Postgres
> - do not run install
> - collect all generated libraries, executables and input files and pack them
>
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan wrote:
> Here's my understanding.
>
> It's not initdb that's really complaining. The timezone files are not inputs
> to initdb. It's the postgres that initdb invokes that's complaining.
>> Postges will look for the share file in two places: the con
On 12/10/2010 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> So in theory we could have a GUC under "file locations" to override
>> this, similarly to data_directory or hba_file or ident_file. But
>> since it's been like this for a really long time (I think), I wouldn't
>> be inclined to go m
On 12/10/2010 11:19 AM, Tom Lane wrote:
Robert Haas writes:
So in theory we could have a GUC under "file locations" to override
this, similarly to data_directory or hba_file or ident_file. But
since it's been like this for a really long time (I think), I wouldn't
be inclined to go monkeying
Robert Haas writes:
> So in theory we could have a GUC under "file locations" to override
> this, similarly to data_directory or hba_file or ident_file. But
> since it's been like this for a really long time (I think), I wouldn't
> be inclined to go monkeying with it unless more than one person
>
On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan wrote:
> Here's my understanding.
>
> It's not initdb that's really complaining. The timezone files are not inputs
> to initdb. It's the postgres that initdb invokes that's complaining.
That was my impression, too, from the log that was sent.
> Po
On 12/10/2010 10:25 AM, Andrew Dunstan wrote:
Not claiming any knowledge in this area - would it be
reasonable to expect that if -L option works for other input files
it should
also work for timezones?
...this seems reasonable.
OK, this has nothing at all to do with the abs
Well, why are you configuring the prefix to be inside your build tree?
This is an odd thing to do. The prefix should be set to where you
expect to install the files, not where you're building them.
CONFIGURE = '--prefix=/home//build/Linux/qe_x86_64'
'--without-readline' '--without-zlib'
Still:
On 12/10/2010 09:55 AM, Robert Haas wrote:
On Fri, Dec 10, 2010 at 9:00 AM, BRUSSER Michael
wrote:
1) The pathnames referenced in the log do not have any dots, I just truncated
them -
they are absolute pathnames to where the timezone files are locates in the
source or build tree
On Fri, Dec 10, 2010 at 9:00 AM, BRUSSER Michael
wrote:
> 1) The pathnames referenced in the log do not have any dots, I just truncated
> them -
> they are absolute pathnames to where the timezone files are locates in
> the source or build tree
> I'll post the entire log if it is still n
>>
>> In log2 I got the same errors as I mentioned earlier:
>> LOG: could not open directory "/home//.../share/timezone": No
>> such file or directory
>> ... ...
> Does it really have a pathname with three dots here?
>
> I'd have more confidence we knew what we were looking at if you sent
> the
On 12/10/2010 07:32 AM, Robert Haas wrote:
On Fri, Dec 10, 2010 at 4:08 AM, BRUSSER Michael
wrote:
- initdb:
initdb -D /home//pgdata -L /home//share -E UTF8
--locale=C \
-d 2> log2> log1
log1 ends with line
creating template1 database in /home//pgdata/base/1 ...
In log2 I go
On Fri, Dec 10, 2010 at 4:08 AM, BRUSSER Michael
wrote:
> - initdb:
> initdb -D /home//pgdata -L /home//share -E UTF8
> --locale=C \
> -d 2> log2 > log1
>
> log1 ends with line
> creating template1 database in /home//pgdata/base/1 ...
>
> In log2 I got the same errors as I mentioned ea
On 12/09/2010 03:36 PM, BRUSSER Michael wrote:
> No, we do not use --with-system-tzdata option.
> I looked at the makefile and at the output of pg_config. We may need to do
> some cleanup there, but I did not pick any clues.
> The problem occurs on all our UNIX platforms.
> Is there anything I co
On 12/09/2010 03:36 PM, BRUSSER Michael wrote:
No, we do not use --with-system-tzdata option.
I looked at the makefile and at the output of pg_config. We may need to do some
cleanup there, but I did not pick any clues.
The problem occurs on all our UNIX platforms.
Is there anything I could d
of pg_config if it helps, or try to run initdb with truss
or strace.
Thanks,
Michael.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, December 09, 2010 2:56 PM
To: BRUSSER Michael
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] initdb failure with
"BRUSSER Michael" writes:
> Initdb fails for me when host machine has no access to the Postgres build
> location.
> LOG: could not open directory .../install/share/timezone": No such file or
> directory
Moving the install tree works for me. Did you do something odd with the
--with-system-tzd
Initdb fails for me when host machine has no access to the Postgres build
location.
LOG: could not open directory .../install/share/timezone": No such file or
directory
LOG: could not open directory .../install/share/timezone": No such file or
directory
WARNING: could not open directory .../
Magnus Hagander wrote:
> > > There is a fixed buffer of 1024 bytes. I have a feeling
> > ythat one has
> > > to be changed to dynamic.
> > >
> > You're quite right. The 'InfoBufferSize' denotes 1122 bytes
> > after this call.
> >
> > if(!GetTokenInformation(AccessToken,TokenGroups,InfoBuffer,1
> > There is a fixed buffer of 1024 bytes. I have a feeling
> ythat one has
> > to be changed to dynamic.
> >
> You're quite right. The 'InfoBufferSize' denotes 1122 bytes
> after this call.
>
> if(!GetTokenInformation(AccessToken,TokenGroups,InfoBuffer,102
> 4,&InfoBufferSize))
Ah.
Your st
Magnus,
There is a fixed buffer of 1024 bytes. I have a feeling ythat one has to
be changed to dynamic.
You're quite right. The 'InfoBufferSize' denotes 1122 bytes after this call.
if(!GetTokenInformation(AccessToken,TokenGroups,InfoBuffer,1024,&InfoBufferSize))
Regards,
Thomas Hallgren
-
t: den 17 augusti 2004 20:27
>To: [EMAIL PROTECTED]
>Subject: [HACKERS] initdb failure on win32
>
>
>I'm trying to run initdb on win32, freshly compiled from CVS
>HEAD, but I
>get the following error:
>
>creating template1 database in data/base/1 ... failed to
I'm trying to run initdb on win32, freshly compiled from CVS HEAD, but I
get the following error:
creating template1 database in data/base/1 ... failed to get token
information: 122
Any ideas?
Regards,
Thomas Hallgren
---(end of broadcast)---
TIP
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> OTOH, I wonder if maybe what we previously did w.r.t. TZ didn't work, but
> the timezone libs were smart enough to disregard an empty TZ value.
The code in variable.c clearly does *not* work on machines where
putenv() copies what you hand it :-(. I s
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Did we actually find a current system where it broke with a straight
>> putenv("LC_ALL")?
>
> Well, the Single Unix Spec does not say that that works, and neither
> does the HPUX man page for putenv, so you're going to have a hard time
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Did we actually find a current system where it broke with a straight
> putenv("LC_ALL")?
Well, the Single Unix Spec does not say that that works, and neither
does the HPUX man page for putenv, so you're going to have a hard time
convincing me that it's
Thanks, works.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am seeing the following failure of initdb in CVS:
>
> Okay, I did some more work on handling unsetenv cleanly ... give it
> another try.
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following failure of initdb in CVS:
Okay, I did some more work on handling unsetenv cleanly ... give it
another try.
regards, tom lane
---(end of broadcast)---
TIP
Bruce Momjian wrote:
I am seeing the following failure of initdb in CVS:
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
On Wed, 2004-05-05 at 13:48, Bruce Momjian wrote:
> I am seeing the following failure of initdb in CVS:
>
> FATAL: invalid value for parameter "client_encoding": ""
I get the same thing.
---(end of broadcast)---
TIP 5: Have you checked o
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following failure of initdb in CVS:
> FATAL: invalid value for parameter "client_encoding": ""
Hmm. Apparently the pg_unsetenv routine I put into initdb.c doesn't
work on your platform. Which is odd, because we've used exactly
I am seeing the following failure of initdb in CVS:
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
creating d
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Peter Eisentraut wrote:
>> Bruce Momjian writes:
>>
>> > The argument that you want a warning because you might have mixed
>> > newlines in the file seems less likely than this case where they are
>> > using a literal carriage return as a data value at t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> Maybe instead we can change the COPY command to read the file directly and
> >> not via stdin? Then we don't need the \. marker.
>
> I like that idea too.
>
> > Yes, we need a temp table then. The singl
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Jon Jensen writes:
>> I hate to mention it, but would it be useful/non-overkill to make either
>> of those things (context message maximum length and funny character
>> escaping) configurable somehow?
> I'm thinking the same. We have conflicting need
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Maybe instead we can change the COPY command to read the file directly and
>> not via stdin? Then we don't need the \. marker.
I like that idea too.
> Yes, we need a temp table then. The single-line fix seemed easier.
Why a
On Sat, Sep 27, 2003 at 01:08:37PM -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > That is all besides the point. If adding -f to the command line is for
> > some reason prohibitive, then the same applies to -e. That is all.
>
> Seems we should recommend -f rather than "<" for restore
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, I have applied a patch to make initdb create a COPY file with
> > consistent end-of-line termination, so it passes the COPY EOL checking.
>
> Maybe instead we can change the COPY command to read the file directly and
> not via stdin? Then
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > You are assuming it is easy to find what is on a specific line of the
> > dump file. I am not sure that is always easy for people with limited
> > Unix skills, or MSWin folks. I am not sure I would have thought to add
> > the file offset to f
Bruce Momjian writes:
> OK, I have applied a patch to make initdb create a COPY file with
> consistent end-of-line termination, so it passes the COPY EOL checking.
Maybe instead we can change the COPY command to read the file directly and
not via stdin? Then we don't need the \. marker.
--
Pet
Bruce Momjian writes:
> You are assuming it is easy to find what is on a specific line of the
> dump file. I am not sure that is always easy for people with limited
> Unix skills, or MSWin folks. I am not sure I would have thought to add
> the file offset to find the problem COPY line. I guess
Peter Eisentraut wrote:
> Oliver Elphick writes:
>
> > +
> > + With a large dump, it may be difficult to identify where any errors are
> > + occurring. You may use the -e option to psql to print the SQL commands
> > + as they are run, so that it is easy to see precisely which comm
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > so it appears that cygwin's "echo" generates a different newline style
> > > than what got put into sql_features.txt. A possible way to fix this is
> > > to put the "\." line into sql_features.txt, but maybe there's a c
Oliver Elphick writes:
> +
> + With a large dump, it may be difficult to identify where any errors are
> + occurring. You may use the -e option to psql to print the SQL commands
> + as they are run, so that it is easy to see precisely which commands are
> + causing errors.
>
Jon Jensen writes:
> I hate to mention it, but would it be useful/non-overkill to make either
> of those things (context message maximum length and funny character
> escaping) configurable somehow?
I'm thinking the same. We have conflicting needs of different groups:
Users on "real" Unix platfor
On Fri, 2003-09-26 at 23:18, Bruce Momjian wrote:
> If you are loading from pg_dump, you have lots of copy commands, so how
> do you know which COPY command caused the failure. You just have the
> line number of _a_ copy.
I would recommend using
psql -e
so that the sql commands are output too.
Jon Jensen wrote:
> On Fri, 26 Sep 2003, Tom Lane wrote:
>
> > I was chewing this over with Bruce on the phone just now, and we refined
> > the idea a little. Some errors (primarily those detected inside the
> > datatype input procedures) can be clearly traced to a specific column,
> > whereas ot
On Fri, 26 Sep 2003, Tom Lane wrote:
> I was chewing this over with Bruce on the phone just now, and we refined
> the idea a little. Some errors (primarily those detected inside the
> datatype input procedures) can be clearly traced to a specific column,
> whereas others (such as too many fields
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > so it appears that cygwin's "echo" generates a different newline style
> > than what got put into sql_features.txt. A possible way to fix this is
> > to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > answer. Peter, any th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Minimalism isn't really a virtue in error reports anyway.
>> I'm thinking maybe:
>> CONTEXT: COPY tablename, line 41: "data ..."
>> would serve the purpose nicely.
> The only thing that would really help in the general case is the number of
> the ch
Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > table name too, like Bruce said. The bothersome bit is that in pg_dump,
> > it says the line, relative to just this part of the copy command, so you
> > don't even know which table is giving the error.
>
> I don't see the problem. Can't you
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The argument that you want a warning because you might have mixed
> > newlines in the file seems less likely than this case where they are
> > using a literal carriage return as a data value at the end of the line.
>
> I don't agree with that
Tom Lane writes:
> This doesn't seem like a good argument not to add more information to
> the CONTEXT line for COPY errors. Sure, in theory the existing info
> should be sufficient, but what if the information is not coming in
> through psql? (For instance, maybe the COPY data is being generate
I said:
> The question isn't so much "who has CRs in their data" as "who is trying
> to import data files in which CRs aren't correctly represented as \r" ?
> Not anyone upgrading from a recent PG release ... though 7.1 or before
> would have an issue.
Actually, checking the CVS logs shows that 7.
scott.marlowe writes:
> psql:webport.sql:803: ERROR: function "odbc_user" already exists with
> same argument types
> REVOKE
> REVOKE
> GRANT
> You are now connected as new user "ayousuff".
> psql:webport.sql:869: ERROR: literal newline found in data
> HINT: Use "\n" to represent newline.
> CON
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> The argument that you want a warning because you might have mixed
>> newlines in the file seems less likely than this case where they are
>> using a literal carriage return as a data value at the end of the line.
> I don't agr
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > table name too, like Bruce said. The bothersome bit is that in pg_dump,
> > it says the line, relative to just this part of the copy command, so you
> > don't even know which table is giving the error.
>
> I don't see th
On Fri, 26 Sep 2003, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > scott.marlowe writes:
> >> but I get basically the same thing if I dump it to a .sql file and do:
> >> psql dbname
> > Use psql -f dbname.sql instead.
>
> This doesn't seem like a good argument not to add mo
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> scott.marlowe writes:
>
> > but I get basically the same thing if I dump it to a .sql file and do:
> >
> > psql dbname
> Use psql -f dbname.sql instead.
and the output is:
psql:webport.sql:803: ERROR: function "odbc_user" already exists with
sa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> scott.marlowe writes:
>> but I get basically the same thing if I dump it to a .sql file and do:
>> psql dbname Use psql -f dbname.sql instead.
This doesn't seem like a good argument not to add more information to
the CONTEXT line for COPY errors. Su
--On Friday, September 26, 2003 14:36:08 -0600 "scott.marlowe"
<[EMAIL PROTECTED]> wrote:
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
Bruce Momjian writes:
> The argument that you want a warning because you might have mixed
> newlines in the file seems less likely than this case where they a
scott.marlowe writes:
> but I get basically the same thing if I dump it to a .sql file and do:
>
> psql dbname
On Fri, 26 Sep 2003, Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The argument that you want a warning because you might have mixed
> > newlines in the file seems less likely than this case where they are
> > using a literal carriage return as a data value at the end of the line.
>
> I
Bruce Momjian writes:
> The argument that you want a warning because you might have mixed
> newlines in the file seems less likely than this case where they are
> using a literal carriage return as a data value at the end of the line.
I don't agree with that assessment. Who actually has CRs in t
scott.marlowe writes:
> table name too, like Bruce said. The bothersome bit is that in pg_dump,
> it says the line, relative to just this part of the copy command, so you
> don't even know which table is giving the error.
I don't see the problem. Can't you identify the failing command by the
li
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > > OK, 'vi' shows it as:
> > >
> > > COPY people2 (id, persons) FROM stdin;
> > > 59 Chance Terry--S
> > > 60 ^M
> > > \.
> > >
> > > which is _exactly the case the error was supposed to catch. Now, the
> >
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > > OK, 'vi' shows it as:
> > >
> > > COPY people2 (id, persons) FROM stdin;
> > > 59 Chance Terry--S
> > > 60 ^M
> > > \.
> > >
> > > which is _exactly the case the error was supposed to catch. Now, the
> >
On Fri, Sep 26, 2003 at 03:05:58PM -0400, Tom Lane wrote:
> Not sure if we should make the behavior Windows-specific though. And
> didn't Michael report seeing the same initdb failure on Debian? That
> confuses me a bit --- why would there be a newline discrepancy on Debian?
I take it there are
scott.marlowe wrote:
> > OK, 'vi' shows it as:
> >
> > COPY people2 (id, persons) FROM stdin;
> > 59 Chance Terry--S
> > 60 ^M
> > \.
> >
> > which is _exactly the case the error was supposed to catch. Now, the
> > big question is where did this dump come from? Pg
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> scott.marlowe wrote:
> > The attached file produces this problem. Note it's a blank trailing field
> > that looks to be causing it. The error for this .sql file is:
> >
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represen
Bruce Momjian wrote:
> scott.marlowe wrote:
> > The attached file produces this problem. Note it's a blank trailing field
> > that looks to be causing it. The error for this .sql file is:
> >
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represent carriage return.
> >
scott.marlowe wrote:
> The attached file produces this problem. Note it's a blank trailing field
> that looks to be causing it. The error for this .sql file is:
>
> ERROR: literal carriage return found in data
> HINT: Use "\r" to represent carriage return.
> CONTEXT: COPY FROM, line 2
>
> N
On Fri, 26 Sep 2003, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database
> > to a 7.4beta3 database is producing some errors like this:
>
> > ERROR: literal newline found in data
> > HINT: Use "\n" to repr
Tom Lane wrote:
I don't mind if we keep it on pure-POSIX platforms. But one of the nicer
developments on Windows in recent(?) times is that you can actually use
any kind of line separator and most programs still work correctly (with
the notable exception of Notepad).
Not sure if we should ma
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Yeah, I was wondering whether you wouldn't propose dropping the newline
>> consistency check. I'm not very comfortable with that, but maybe we
>> should. Bruce?
> I don't mind if we keep it on pure-POSIX platforms. But one of th
Tom Lane wrote:
> > ERROR: literal carriage return found in data
> > HINT: Use "\r" to represent carriage return.
> > CONTEXT: COPY FROM, line 41
>
> Really? 7.2 should dump data \r or \n as the backslash versions ...
> and does in my tests. Can you make a reproducible test case?
>
>
>
> >
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> I'm running into issues where 7.4's pg_dump/pg_dumpall from a 7.2 database
> to a 7.4beta3 database is producing some errors like this:
> ERROR: literal newline found in data
> HINT: Use "\n" to represent newline.
> CONTEXT: COPY FROM, line 59
> E
On Fri, 26 Sep 2003, Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Tom Lane writes:
> > >> so it appears that cygwin's "echo" generates a different newline style
> > >> than what got put into sql_features.txt. A possible way to fix this is
> > >> to
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... we could add code to throw the WARNING
> > only once per COPY command --- that would probably make sense.
>
> Seems like a bit of a kluge, but perhaps the best compromise. It would
> be quite likely that you'd get the same warnin
Tom Lane writes:
> Yeah, I was wondering whether you wouldn't propose dropping the newline
> consistency check. I'm not very comfortable with that, but maybe we
> should. Bruce?
I don't mind if we keep it on pure-POSIX platforms. But one of the nicer
developments on Windows in recent(?) times
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... we could add code to throw the WARNING
> only once per COPY command --- that would probably make sense.
Seems like a bit of a kluge, but perhaps the best compromise. It would
be quite likely that you'd get the same warning on many lines of a COPY,
a
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > so it appears that cygwin's "echo" generates a different newline style
> > than what got put into sql_features.txt. A possible way to fix this is
> > to put the "\." line into sql_features.txt, but maybe there's a cleaner
> > answer. Peter, any th
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Perhaps we can throw a warning rather than an error, and adjust initdb
> > to be consistent.
>
> I like the idea of reducing the newline consistency check to a warning.
> There is one thing we'd have to watch for though (it's already
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >I posted on that a few minutes ago. Yea, we can drop it, but we risk
> >eating carraige returns as data values. I am not sure how consistently
> >we output literal carriage returns in old dumps, nor how many apps
> >produce on literal carriage re
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Perhaps we can throw a warning rather than an error, and adjust initdb
> to be consistent.
I like the idea of reducing the newline consistency check to a warning.
There is one thing we'd have to watch for though (it's already an issue
but would become a
Bruce Momjian wrote:
I posted on that a few minutes ago. Yea, we can drop it, but we risk
eating carraige returns as data values. I am not sure how consistently
we output literal carriage returns in old dumps, nor how many apps
produce on literal carriage returns in COPY. If we conditionally eat
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> so it appears that cygwin's "echo" generates a different newline style
> >> than what got put into sql_features.txt. A possible way to fix this is
> >> to put the "\." line into sql_features.txt, but maybe the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> so it appears that cygwin's "echo" generates a different newline style
>> than what got put into sql_features.txt. A possible way to fix this is
>> to put the "\." line into sql_features.txt, but maybe there's a cleaner
>> answer.
1 - 100 of 109 matches
Mail list logo
