Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
I think pqsignal should be passing SA_NOCLDSTOP in sa_flags,
With that patch applied, the problem is indeed gone on my system.
However, I would still like to know why 7.4 didn't show the same
misbehavior, when it isn't using this flag.
It
At 02:32 PM 12/08/2004, Philip Warner wrote:
At 01:27 PM 12/08/2004, Bruce Momjian wrote:
Set client_min_messages to WARNING?
Sounds like a plan.
Attached patch sets client_min_messages as above and gives some
context to errors messages, eg:
pg_restore: [archiver (db)] Error from TOC Entry 19;
Hi all,
Jason Godden pointed out some weird savepoint behaviour on IRC and i've
narrowed this down to a simpler case.
We see the following behaviour against HEAD:
template1=# create table foo(i int, j text);
CREATE TABLE
template1=# create unique index foo_idx on foo(i); -- not, creation of idx
Andrew Dunstan said:
Bruce Momjian wrote:
One issue is that pre-8.0, psql files were opened in Win32 text mode,
so we wouldn't have seen this bug on Win32, but we would on Linux.
Because we open them on Win32 now in binary mode so we see control-Z it
will show up on Win32 too.
true, *BUT*
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
However, I don't see any CVS commit that fixed this? What am I missing?
The failure case is where the template database has a conflicting
table. You didn't show us where you created that table, but it
evidently was not in template1.
Philip Warner [EMAIL PROTECTED] writes:
Attached patch sets client_min_messages as above and gives some
context to errors messages, eg:
pg_restore: [archiver (db)] Error from TOC Entry 19; 1255 16438403 FUNCTION foo() pjw
pg_restore: [archiver (db)] could not execute query: ERROR: no schema
Andrew Dunstan [EMAIL PROTECTED] writes:
There's another question this bug raises, though. Why doesn't the server
protest when it sees more copy data passed in after it sees the end marker?
Whether it did or not would make not the slightest bit of difference,
since (without the patch) psql
Gavin Sherry [EMAIL PROTECTED] writes:
Jason Godden pointed out some weird savepoint behaviour on IRC and i've
narrowed this down to a simpler case.
Can't reproduce it here --- I get the expected output, on two different
machines (HPUX and RHL8). What are you testing on? Do you see the same
I wrote:
Can't reproduce it here --- I get the expected output,
Disregard that --- I had managed to omit the create index command while
copying and pasting.
Man, that is bizarre ... the index shouldn't make any difference at all...
regards, tom lane
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
There's another question this bug raises, though. Why doesn't the server
protest when it sees more copy data passed in after it sees the end marker?
Whether it did or not would make not the slightest bit of difference,
since
Andrew Dunstan [EMAIL PROTECTED] writes:
Surely sending
copy data after the end marker is sent should be an error.
I'm unconvinced. For example, this would force a client to parse the
contents of a file it's shipping over, rather than just pushing the file
verbatim and then unconditionally
Gavin Sherry [EMAIL PROTECTED] writes:
Jason Godden pointed out some weird savepoint behaviour on IRC and i've
narrowed this down to a simpler case.
The answer turns out to be that GetSnapshotData is miscomputing snapshot
xmin and RecentGlobalXmin when inside a subtransaction: it omits our own
Eric Kerin wrote:
On Sat, 2004-08-14 at 01:11, Tom Lane wrote:
Eric Kerin [EMAIL PROTECTED] writes:
The issues I've seen are:
1. Knowing when the master has finished the file transfer transfer to
the backup.
The standard solution to this is you write to a temporary file name
(generated off your
On Sun, 2004-08-15 at 16:22, Gaetano Mendola wrote:
Eric Kerin wrote:
On Sat, 2004-08-14 at 01:11, Tom Lane wrote:
Eric Kerin [EMAIL PROTECTED] writes:
The issues I've seen are:
1. Knowing when the master has finished the file transfer transfer to
the backup.
The standard solution
Eric Kerin wrote:
On Sun, 2004-08-15 at 16:22, Gaetano Mendola wrote:
Eric Kerin wrote:
On Sat, 2004-08-14 at 01:11, Tom Lane wrote:
Eric Kerin [EMAIL PROTECTED] writes:
The issues I've seen are:
1. Knowing when the master has finished the file transfer transfer to
the backup.
The standard
At 01:32 AM 16/08/2004, Tom Lane wrote:
It'd be substantially *more* helpful if it reported the failing command.
They are two different problems; the TOC entry is important for any
multiline command or to rerun the command easily later.
Whereas displaying the failed SQL command is a matter of
Daniel Schuchardt [EMAIL PROTECTED] writes:
BEGIN
exception ...
EXCEPTION
WHEN OTHERS THEN ?what to write for do nothing?
END;
in oracle it's
WHEN OTHERS THEN null;
but this syntax doesn't work in postgres.
In Postgres you just write nothing at all:
BEGIN
Tom Lane said:
Daniel Schuchardt [EMAIL PROTECTED] writes:
BEGIN
exception ...
EXCEPTION
WHEN OTHERS THEN ?what to write for do nothing?
END;
in oracle it's
WHEN OTHERS THEN null;
but this syntax doesn't work in postgres.
In Postgres you just write nothing at
18 matches
Mail list logo
