From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RAM-only temporary tables |
Date: | 2008-11-11 20:38:47 |
Message-ID: | 4919ED57.7010409@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Try several thousand temp tables within one transaction.
>
> I ran into an interesting problem while doing that. I created a SQL
> script with 10000 CREATE TEMPORARY TABLE statements. After testing with
> that a few times, I got this:
>
> WARNING: out of shared memory
> ERROR: out of shared memory
> HINT: You might need to increase max_locks_per_transaction.
>
> Not that surprising, but when I then just tried to run a single CREATE
> TEMPORARY TABLE in a new psql session, I got the same error. I then
> stopped and started postmaster, and I still get the same error! Testing
> with trace_locks=on, looks like the table creation takes a lock on all
> the temp tables that are already gone, and runs out of memory doing that.
What's happening is that there is simply so many temporary tables in
pg_class that when the new backend tries to clear them with
RemoveTempRelations, it runs out of lock space.
One idea would be to modify RemoveTempRelations to not acquire locks on
the temp objects, but that's pretty ugly and I'm not sure how it would
interact with concurrent DROP TYPE CASCADE or similar. Any better ideas?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-11-11 20:41:37 | Re: RAM-only temporary tables |
Previous Message | Greg Stark | 2008-11-11 20:37:42 | Re: failed test float8 on mingw |