Stephan Szabo wrote:
> The case at hand (with *'s on the ri queries) assuming pk already
> has an id=1 row would be.
> T1: begin;
> T1: set transaction isolation level serializable;
> T1 ... (something that does a select, not necessarily on either pk or fk)
> T2: begin;
> T2: insert into fk values
On Fri, 26 Sep 2003, Kevin Brown wrote:
> 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 pro
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> ... You can make this work, but the resource costs
>> are steep.
> So, after 'n' seconds of waiting, we abandon the slave and the slave
> abandons the master.
[itch...] But you surely cannot guarantee that the slave and the master
time out a
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.
> Not "it can", but "it has to". The master *must* keep hold of that
> request forever (or until the slave responds, or until we reconfigure
> the system not to consider that slave valid anymore). Similarly, the
> slave cannot forget the maybe-committed transaction on pain of not being
> a valid
> > 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 separate-subprocess backends to inherit variable
Ah, I was just thinking that you could do a nice multi-line version (same
as how they are dumped from 7.3.x)
But yes, it doesn't really matter.
Chris
On Fri, 26 Sep 2003, Andreas Pflug wrote:
> Christopher Kings-Lynne wrote:
>
> > I note there is no pretty printing option for pg_get_triggerdef.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Actually, the most common THREAD_CFLAGS is -pthread, used by Solaris,
> > OSF, and FreeBSD 4.X. Only Linux uses -D flags for threading.
>
> So is -pthread a compile-time or link-time flag?
>
> If we need both THREAD_CPPFLAGS and THR
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am documenting this behavior in the CREATE VIEW manual page, diff
> attached.
> +
> + While access to tables in the view is controlled entirely by permissions
> + on the view, functions called by the view are checked independently.
> +
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Actually, the most common THREAD_CFLAGS is -pthread, used by Solaris,
> OSF, and FreeBSD 4.X. Only Linux uses -D flags for threading.
So is -pthread a compile-time or link-time flag?
If we need both THREAD_CPPFLAGS and THREAD_CFLAGS then let's go ahead
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I just noticed that libpq/ecpg use $(THREAD_CFLAGS) as part of CPPFLAGS.
> > Is that correct? Should it be added to CFLAGS instead?
>
> I was just noticing that today. THREAD_CFLAGS typically includes -D
> flags, and as such it *mus
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I just noticed that libpq/ecpg use $(THREAD_CFLAGS) as part of CPPFLAGS.
> Is that correct? Should it be added to CFLAGS instead?
I was just noticing that today. THREAD_CFLAGS typically includes -D
flags, and as such it *must* be added to CPPFLAGS ---
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
>
> Hmm, that i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Would it be a good idea to have a separate shared buffer process to
> manage the cache? Could such a process take workload off of the main
> backend and improve their performance?
> Just an idea?
I can't recall if this has been discussed on the list, b
Would it be a good idea to have a separate shared buffer process to
manage the cache? Could such a process take workload off of the main
backend and improve their performance?
Just an idea?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] |
I just noticed that libpq/ecpg use $(THREAD_CFLAGS) as part of CPPFLAGS.
(I added that code.)
Is that correct? Should it be added to CFLAGS instead?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a ha
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
On Fri, 26 Sep 2003, 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 fo
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:
> > >
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
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Where are we on this --- we all decided on #4. Does this just require
> an announcment in the release notes.
I haven't done anything about it --- been busy with other stuff, and I
wasn't sure we'd agreed to change it for 7.4 anyway. I'm willing to
make
Where are we on this --- we all decided on #4. Does this just require
an announcment in the release notes.
(I need to complete the release notes soon.)
---
Tom Lane wrote:
> Following up this gripe
> http://archives.postgr
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
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 th
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"
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
> 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 wi
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 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
--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, 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
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
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 Sull
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.
> >
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 trans
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
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 fa
[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
>> > se
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
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 *
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
> -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:
Saw that these guys had raised some more VC money, and made an acquisition. Anyone
from the company on the lists? (Probably best to reply only to -advocacy, but wanted
to cast the net wide).
From their website (www.metapa.com):
--
Metapa CDB is an enterprise Java software application running
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 tha
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 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
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
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
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
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
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 i
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 i
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 ali
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
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 considerin
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
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
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 sa
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 menti
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
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 load
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 the
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 shi
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 \. t
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
express
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) an
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
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?
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:
1 - 100 of 118 matches
Mail list logo
