Christopher Kings-Lynne writes:
Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?
If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case,
Hornyak Laszlo wrote:
I think it is not that simple. How should I explain the company leaders
why I must stop the system. It may risk their bussiness success too. I can
tell them that the new db is more stable, but until the old one does the
job, it is still acceptable for them (it served the
Greg Stark wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
The little pthreads programming I did on linux/freeBSD tells me that it
supports majority of features except TLS(linux2.4/linuxthreads) and per thread
signals.
LinuxThreads is dead. NPTL is the way and the light.
It has ELF TLS
Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?
If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case, you can run initdb --version first
On Fri, 26 Sep 2003 04:51 pm, Christopher Kings-Lynne wrote:
Yes I do, but sometimes as different users you don't know what the path
is. I guess I can just go --version.
Perhaps add
alias initdb='initdb --version; initdb'
to /etc/profile so that all accounts get an alias?
Regards, Philip
On Fri, 26 Sep 2003, Christopher Kings-Lynne wrote:
If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the version number? In any
case, you can run initdb --version first if you're not sure about what is
where.
Yes I
I note there is no pretty printing option for pg_get_triggerdef...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
When the address-of operator is applied to a thread-local variable, it
is evaluated at run-time and returns the address of the current thread's
instance of that variable. An address so obtained may be used by any
thread. When a thread terminates, any pointers to thread-local variables
in
Christopher Kings-Lynne wrote:
I note there is no pretty printing option for pg_get_triggerdef...
Right.
There's no expression tree displayed, which would make the pretty print
option necessary.
As long as we don't have reengineering functions for *all* objects, it
doesn't make sense to
Tom == Tom Lane [EMAIL PROTECTED] writes:
Tom AFAIK, no commercial database does predicate locking either,
True ..
Tom so we all fall short of true serializability. The usual
Tom solution if you need the sort of behavior you're talking
Tom about is to take a non-sharable
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
All TLS variables *must* be static (or implicitly static
through extern, i.e. no 'auto' variables)
I assume you mean static as in not-auto, rather than static as in
not-global. Otherwise we have a problem here.
Yes, you are correct.
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
One thing that can be done is to arrange all globals/statics in a
structure and make that structure thread local.
That's about as far from non-invasive as I can imagine :-(
I know.
I have following half baked solution. Obviously it
On Friday 26 September 2003 02:29, Shridhar Daithankar wrote:
Well, I am sure there are data corruption bugs fixed between 6.2 and
current CVS head which would count as large impact in terms of numbers and
severity.
Indeed there are.
Its not like oracle upgrade where you have to move the OS,
No, I got this job 2 months ago, I don`t know who managed it before, and I
don`t know why didn`t he upgrade. Until this week I didn`t have the chance
to upgrade.
But it runs now on 7.3.4.
On Thu, 25 Sep 2003, Richard Huxton wrote:
On Thursday 25 September 2003 07:36, Hornyak Laszlo wrote:
I
Okay, I'll work out some extension of the APIs to let us propagate the
snapshot request down through SPI and into the Executor, rather than
using a global variable for it. (Unless someone has a better idea...)
Just when you thought it was safe to go back in the water ...
Chris Kratz sent me
On Fri, 26 Sep 2003, Christopher Kings-Lynne wrote:
Is there any chance we could have initdb show the version of postgresql
it is running as when initdb is run?
If you install many different versions in parallel, don't you give your
installation paths some meaning that contain the
On Friday 26 September 2003 19:50, Tom Lane wrote:
Anyway, on to Chris' example. Load the attached script into a database
that has plpgsql already created, and then do
DELETE FROM Activity WHERE ActivityID = 16739;
You'll get
ERROR: attempted to mark4update invisible tuple
(or
Nigel J. Andrews [EMAIL PROTECTED] writes:
Moral of the story, if it's in your path first then it's the default and you
should therefore be happy with the results or be prepared to live with them,
otherwise make sure what you're running.
I would think that having initdb print its version while
Merlin Moncure [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely the addresses can be assumed constant within a thread.
Otherwise we have a problem here too.
Quoting from the MSDN:
The address of a thread local object is not considered constant, and any
expression involving such an address
Shridhar Daithankar [EMAIL PROTECTED] writes:
We really don't need threads to replace existing functionality. That
would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack of fork(), which means there's
no way for
Lamar Owen [EMAIL PROTECTED] writes:
This isn't necessarily true. That old of a version of PostgreSQL is probably
running on a quite out-of-date OS -- for instance, if the OS was Red Hat
Linux, then the point at which 6.2.1 was shipped was RHL 5.0. Can you even
compile PostgreSQL 7.3.x on
On Friday 26 September 2003 20:19, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
We really don't need threads to replace existing functionality. That
would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack
Tim McAuley [EMAIL PROTECTED] writes:
Another question now. I am unable to compile Postgresql 7.4 beta 3 under
cygwin (Windows 2K, using cgyipc 2).
I am getting the error:
creating information schema... ERROR: end-of-copy marker does not match
previous newline style
CONTEXT: COPY
On Fri, 2003-09-26 at 11:01, Tom Lane wrote:
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 thoughts?
Does
Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
Moral of the story, if it's in your path first then it's the default and you
should therefore be happy with the results or be prepared to live with them,
otherwise make sure what you're running.
I would think that having initdb
Shridhar Daithankar [EMAIL PROTECTED] writes:
If the trigger function is precompiled, the error would not be reproducible
and it will work correctly, right?
Only because the trigger in the example doesn't issue any queries of its
own. If it did, it would cause CommandCounterIncrement(s)
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely the addresses can be assumed constant within a thread.
Otherwise we have a problem here too.
Quoting from the MSDN:
The address of a thread local object is not considered constant, and any
expression
On Fri, Sep 26, 2003 at 11:01:34AM -0400, Tom Lane wrote:
I am getting the error:
creating information schema... ERROR: end-of-copy marker does not match
previous newline style
CONTEXT: COPY FROM, line 361
That's interesting. COPY is complaining because the \. terminator in
On Friday 26 September 2003 10:52, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
This isn't necessarily true. That old of a version of PostgreSQL is
probably running on a quite out-of-date OS -- for instance, if the OS was
Red Hat Linux, then the point at which 6.2.1 was shipped was
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
We really don't need threads to replace existing functionality. That
would be dog work.
No, that's not the point at all. The problem we are facing at the
moment with the Windows port is lack of fork(), which means there's
no
This item has been added to the 7.4 open items list:
ftp://momjian.postgresql.org/pub/postgresql/open_items
---
Rod Taylor wrote:
-- Start of PGP signed section.
Below is output from 7.3 pg_dump that is being
Bruce Momjian [EMAIL PROTECTED] writes:
One solution is for me to continue with this in the Win32 CVS version
until I have fork/exec() working on Unix, then test on Win32. I think
that could be done in a few weeks, if not less.
Another solution, already mentioned, is to use threads and TLS.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One solution is for me to continue with this in the Win32 CVS version
until I have fork/exec() working on Unix, then test on Win32. I think
that could be done in a few weeks, if not less.
Another solution, already mentioned, is to
On Fri, 26 Sep 2003, Tom Lane wrote:
Okay, I'll work out some extension of the APIs to let us propagate the
snapshot request down through SPI and into the Executor, rather than
using a global variable for it. (Unless someone has a better idea...)
Just when you thought it was safe to go
Stephan Szabo [EMAIL PROTECTED] writes:
I think theoretically in serializable the cases where the difference
between the snapshot from this statement and the standard snapshot for the
transaction are noticable we probably have a serialization failure
Hmm, that is a good point. It would be
Zeugswetter Andreas SB SD wrote:
From our previous discussion of 2-phase commit, there was concern that
the failure modes of 2-phase commit were not solvable. However, I think
multi-master replication is going to have similar non-solvable failure
modes, yet people still want
Bruce Momjian [EMAIL PROTECTED] writes:
Could we allow slaves to check if the backend is still alive, perhaps by
asking the postmaster, similar to what we do with the cancel signal ---
that way, the slave would never time out and always wait if the master
was alive.
You're not considering the
Alvaro Herrera writes:
Regarding your message cleanup, I wonder about:
#: rewrite/rewriteDefine.c:274
msgid rules on SELECT rule must have action INSTEAD SELECT
Is this really the intended wording?
#: utils/misc/guc.c:1318
msgid log statement generating error at or above this level
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Could we allow slaves to check if the backend is still alive, perhaps by
asking the postmaster, similar to what we do with the cancel signal ---
that way, the slave would never time out and always wait if the master
was alive.
On Fri, 26 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Could we allow slaves to check if the backend is still alive, perhaps by
asking the postmaster, similar to what we do with the cancel signal ---
that way, the slave would never time out and always wait if the
On Fri, 26 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Could we allow slaves to check if the backend is still alive, perhaps by
asking the postmaster, similar to what we do with the cancel signal ---
that way, the slave would never time out and always wait if the
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low ... but if you were talking about two
seperate geographical locations (and yes, I realize you are adding lag to
the mix
Patrick Welche wrote:
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low ... but if you were talking about two
seperate geographical locations (and yes, I realize you
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 thoughts?
There's no clean answer to this on
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're not considering the possibility of a transient communication
failure.
Can't the master re-send the request after a timeout?
Not it can, but it has to. The master *must* keep hold of that
request forever (or until the slave
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 thoughts?
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. Peter, any
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're not considering the possibility of a transient communication
failure.
Can't the master re-send the request after a timeout?
Not it can, but it has to. The master *must* keep hold of that
request forever
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 9:27 AM
To: Bruce Momjian
Cc: Shridhar Daithankar; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Threads vs Processes
Bruce Momjian [EMAIL PROTECTED] writes:
One
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 there's a cleaner
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
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
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 returns in
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 an issue
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 thoughts?
On Fri, 26 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're not considering the possibility of a transient communication
failure.
Can't the master re-send the request after a timeout?
Not it can, but it has to. The master *must* keep hold of
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,
and
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 is
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 warning on many
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 put the \. line into
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
ERROR:
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 the nicer
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?
It would be
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
[EMAIL PROTECTED] (Bruce Momjian) writes:
Patrick Welche wrote:
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low ... but if you were talking about two
seperate
On Fri, 26 Sep 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I think theoretically in serializable the cases where the difference
between the snapshot from this statement and the standard snapshot for the
transaction are noticable we probably have a serialization failure
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 represent newline.
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
Note that
On Fri, Sep 26, 2003 at 01:34:28PM -0400, Tom Lane wrote:
Example:
Master Slave
-- -
commit ready--
--OK
commit done-XX
maybe he didn't. Both sides are forced to keep information about the
open transaction
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.
CONTEXT:
On Fri, Sep 26, 2003 at 02:05:36PM -0400, Tom Lane wrote:
a valid slave anymore. You can make this work, but the resource costs
are steep. For instance, in Postgres, you don't get to truncate the WAL
But people who want 2PC are more than willing to pay all that cost.
A
--
Andrew
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 represent carriage
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 version? OS
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 no
On Fri, 26 Sep 2003, Christopher Browne wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Patrick Welche wrote:
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low
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
big question is where did
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
big question is where did
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
line
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
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 don't
scott.marlowe writes:
but I get basically the same thing if I dump it to a .sql file and do:
psql dbname dbname.sql
Use psql -f dbname.sql instead.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will
--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 are
On Fri, 2003-09-26 at 13:58, Bruce Momjian wrote:
Patrick Welche wrote:
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low ... but if you were talking about two
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 dbname.sql
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
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 dbname.sql
Use psql -f dbname.sql instead.
and the output is:
psql:webport.sql:803: ERROR: function odbc_user already exists with
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 dbname.sql
Use psql -f dbname.sql instead.
This doesn't seem like a good argument not to add more
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 the
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 agree with
The first problem is the restart/rejoin problem. When a 2PC member
goes away, it is supposed to come back with all its former locks and
everything in place, so that it can know what to do. This is also
extremely tricky, but I think the answer is sort of easy. A member
which re-joins
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.
CONTEXT: COPY
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.2.1 was
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 generated
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
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 identify
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 character where
Marc G. Fournier wrote:
On Fri, 26 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're not considering the possibility of a transient communication
failure.
Can't the master re-send the request after a timeout?
Not it can, but it has to. The master
On Fri, 26 Sep 2003, Christopher Browne wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Patrick Welche wrote:
On Fri, Sep 26, 2003 at 02:49:30PM -0300, Marc G. Fournier wrote:
...
if we are talking two computers sitting next to each other on a switch,
you'd expect those to be low
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 thoughts?
Peter Eisentraut [EMAIL PROTECTED] writes:
Peter, do you remember that?
BE_DLLLIBS; see Makefile.cygwin for example. (AIX has a similar
requirement, but handles it differently for bizarre reasons.)
Right, thanks.
Personally, I think the two-level namespace feature is the opposite of
I am documenting this behavior in the CREATE VIEW manual page, diff
attached.
---
Gaetano Mendola wrote:
Bruce Momjian [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Someone
1 - 100 of 119 matches
Mail list logo
