From: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |
Date: | 2004-12-03 00:27:19 |
Message-ID: | 200412030127.19906.ftm.van.vugt@foxi.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> > #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 like the ones below. What's causing
> > these?
>
> This happens when a transaction finishes that creates, drops, or
> modifies a user. If it happens at a different time, something is wrong.
The code for the first part of the conversion does not contain any statements
for create/alter/drop user, it doesn't even fire triggers. Basically it's
just looping over the following set of statements for a number of textfiles:
- read, validate and post-process the contents of a text file
- write the result into another text file
- (try to) drop the table
- create the table
- grant select on this table to public
- copy table from a textfile
That's it, so there is no explicit user-handling at all.
Anything particular I can take a look at?
--
Best,
Frank.
From | Date | Subject | |
---|---|---|---|
Next Message | Frank van Vugt | 2004-12-03 00:50:35 | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |
Previous Message | Tom Lane | 2004-12-03 00:20:11 | Re: "invalid memory alloc request size <n>" in deferred trigger causes transaction to fail, but the backend keeps running |