On Thu, Dec 02, 2004 at 05:11:22PM +1100, Neil Conway wrote:
> I checked in a fix for this to HEAD; the patch is attached. I also
> noticed various other brokenness in oid2name (access to uninitialized
> variables, malloc() + sscanf() rather than strdup(), etc.), which I
> fixed.
I think they wer
Apologies for raising this - I've found a message in the
archives from about a month ago; but...
I can't find the relevant sections in the SQL spec; nevertheless, the
docs for the SELECT command lead me to believe that this should work,
since:
http://developer.postgresql.org/docs/postgres/sql-
L.S.
Situation:
- PostgreSQL v8.0.0beta5 running on x86 hardware
- a database schema that uses before/after/deferred triggers to do additional
processing on stuff like orders and invoices based on the order- and
invoice--lines; the deferred triggers are basically of the format 'update
order s
Frank van Vugt <[EMAIL PROTECTED]> writes:
> ERROR: invalid memory alloc request size 3248857576
> Obviously, since the backend keeps running, it won't be easy to get my hands
> on the backtrace from when this error occurs and I'm wondering about the best
> way to proceed in order to produce som
Jan Grant <[EMAIL PROTECTED]> writes:
> http://developer.postgresql.org/docs/postgres/sql-select.html
>> ... PostgreSQL also allows both clauses to specify
>> arbitrary expressions. Note that names appearing in an expression will
^
On Wed, 1 Dec 2004, Stephan Szabo wrote:
On Wed, 1 Dec 2004, postgresbugs wrote:
> Foreign keys referencing parent table fails on insert if the key is in
> the table that inherits the parent table.
Unfortunately, primary keys, unique constraints and foreign keys do not
in
OK, I updated the error message to be:
return "dynamic load error";
and added a TODO item for Win32:
o Improve dlerror() reporting string
---
Tom Lane wrote:
> "Luciano - UNILOG SA" <[EMAIL PR
The getopt specification string for pg_autovacuum in 8.0.0beta5
has:
while ((c = getopt(argc, argv, "s:S:v:V:a:A:d:U:P:H:L:p:hD:c:C:m:n:l:"))
This has the '-D' demonize option need an argument. So to get it
to run in the background as a daemon, you need to give it a dummy
argument on the
Thanks. Fixed.
---
Kenneth Marshall wrote:
> The getopt specification string for pg_autovacuum in 8.0.0beta5
> has:
>
> while ((c = getopt(argc, argv,
> "s:S:v:V:a:A:d:U:P:H:L:p:hD:c:C:m:n:l:"))
>
> This has the
> > I'm wondering
> > about the best way to proceed in order to produce some helpfull input to
> > the developers.
>
> Provide a reproducible test case maybe?
Sorry, won't be that easy. I didn't encounter the problem with earlier
(smaller) data-sets and even if I would put in the hours needed in
Frank van Vugt <[EMAIL PROTECTED]> writes:
> Ok, using --enable-cassert might not be such a good idea for now, since it
> triggers a trap very early on in the conversion:
> TRAP: FailedAssertion("!(((ntp)->t_data)->t_infomask & 0x0010)", File:
> "catcache.c", Line: 1729)
[ raised eyebrow... ]
Hi,
Magnus, thanks for replying. We believe that we have followed the given
instructions all the way.
I have taken snapshots of entire installation and compiled into a document
(zipped ~ 500kb)which I wish to send across. These contain the snapshots of the
"postgres" user created and it's prop
> [ raised eyebrow... ] That should definitely not be happening either.
> In fact, I find that considerably more surprising than your original
> report. I'd suggest chasing this first.
It was already well on its way, so
Here's what's going on when the memory alloc problem occurs:
(gdb) b
Frank van Vugt <[EMAIL PROTECTED]> writes:
> Here's what's going on when the memory alloc problem occurs:
AFAICS this can only be explained as a memory stomp on the static data
structures SerializableSnapshotData or LatestSnapshotData. That seems a
tad improbable. I wonder if what you have is a
> > Here's what's going on when the memory alloc problem occurs:
> AFAICS this can only be explained as a memory stomp on the static data
> structures SerializableSnapshotData or LatestSnapshotData. That seems a
> tad improbable. I wonder if what you have is a build problem. Have you
> tried a
On Fri, Dec 03, 2004 at 01:03:43AM +0100, Frank van Vugt wrote:
> As far as the other problem is concerned, I just finished the first half of
> the conversion on a different machine that was build with assertions enabled
> and saw a number of reports like the ones below. What's causing these?
T
Frank van Vugt <[EMAIL PROTECTED]> writes:
> I could reproduce this case tomorrow and inspect some variables or call
> abort() if you think that could be of any help?
Do you have hardware watchpoints on that machine? What I'd be inclined
to try is tracing through the transaction to see where
Ser
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Dec 03, 2004 at 01:03:43AM +0100, Frank van Vugt wrote:
>> As far as the other problem is concerned, I just finished the first half of
>> the conversion on a different machine that was build with assertions enabled
>> and saw a number of reports
> > #1 0x0818e9e1 in SendPostmasterSignal (reason=PMSIGNAL_PASSWORD_CHANGE)
> > at pmsignal.c:69
> >
> > As far as the other problem is concerned, I just finished the first half
> > of the conversion on a different machine that was build with assertions
> > enabled and saw a number of reports li
> > I could reproduce this case tomorrow and inspect some variables or call
> > abort() if you think that could be of any help?
>
> Do you have hardware watchpoints on that machine?
Mmm, don't know for sure, will have a look tomorrow.
> What I'd be inclined
> to try is tracing through the transac
Ok, here are the results of the assertion TRAP (mind you, same error on the
same line, but a different machine than the original)
database log:
TRAP: FailedAssertion("!(((ntp)->t_data)->t_infomask & 0x0010)", File:
"catcache.c", Line: 1729)
gdb:
Program received signal SIGABRT, Aborted.
0x4
Frank van Vugt <[EMAIL PROTECTED]> writes:
>> What I'd be inclined
>> to try is tracing through the transaction to see where
>> SerializableSnapshotData.xcnt or LatestSnapshotData.xcnt gets clobbered
>> from. It'd be mighty tedious if you have to fall back on a software
>> watchpoint though.
> A
Frank van Vugt <[EMAIL PROTECTED]> writes:
>> Does anything happen before the SAVEPOINT?
> Actually, the SQL involved is v7.4.6,
Not with that backtrace, it isn't.
regards, tom lane
---(end of broadcast)---
TIP 7: don't for
> > A hint on the expression(s) to use would be appreciated !
> (gdb) watch SerializableSnapshotData.xcnt
I could have thought of that ;)
(I misinterpreted what you meant by SerializableSnapshotData.xcnt, wouldn't
have asked otherwise)
Anyway, I just confirmed that hardware watchpoints are avai
> >> Does anything happen before the SAVEPOINT?
> >
> > Actually, the SQL involved is v7.4.6,
>
> Not with that backtrace, it isn't.
Excuse me?
I'm running v8.0.0beta5, but the sql-statements that are in my source-tree are
all still 'based on v7.4.6', i.e. there is no occurence of the word
'sav
Frank van Vugt <[EMAIL PROTECTED]> writes:
Does anything happen before the SAVEPOINT?
>
Actually, the SQL involved is v7.4.6,
>>
>> Not with that backtrace, it isn't.
> Excuse me?
> I'm running v8.0.0beta5,
Oh, I thought you meant the backend was 7.4.6.
> but the sql-statements that
> Hmm. The line number referenced for CommitTransactionCommand() is
> definitely in code that is only entered after a savepoint, but I see
> it is an identical code path to some other arms of the switch()
> command. Probably the compiler decided to merge those arms. You might
> want to back off
Frank van Vugt <[EMAIL PROTECTED]> writes:
> Ok, here are the results of the assertion TRAP (mind you, same error on the
> same line, but a different machine than the original)
That's another can't-happen problem. As best I can tell, this suggests
that the tuple descriptor associated with the RE
On Thu, 2 Dec 2004, postgresbugs wrote:
>
> On Wed, 1 Dec 2004, Stephan Szabo wrote:
>
> On Wed, 1 Dec 2004, postgresbugs wrote:
>
> > Foreign keys referencing parent table fails on insert if the key is in
> > the table that inherits the parent table.
>
>
> Unfortunately, primary keys, unique
I am using postgresql 8.0 beta 4 on win2000.
psql operates strangely within a cmd.exe window. It is somewhat like if
you backgrounded the command in unix. with psql in interactive mode (no
-f switch) whatever line you type is alternately processed by cmd.exe and
psql.
So you get the following (
30 matches
Mail list logo
