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
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.
>>
>>
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 te
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 s
"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 sam
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 (wit
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 o
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, 15 Aug 2004, Tom Lane wrote:
> 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 RecentGlobal
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.
>
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" so
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 fi
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:
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 jus
On Mon, 16 Aug 2004, Tom Lane wrote:
> > in oracle it's
> > WHEN OTHERS THEN null;
> > but this syntax doesn't work in postgres.
>
> It looks like about five minutes' work to add such a thing ... anyone
> have any objections?
Is NULL above an empty statement in oracle or is it a normal expressio
19 matches
Mail list logo
