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 (
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
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
> 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:
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
> >> 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
> > 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
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
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
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
> > 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
> > #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
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
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
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
> > 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
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
> [ 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
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
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... ]
> > 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
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
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
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
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
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
^
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
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
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-
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
30 matches
Mail list logo
