From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Denis Perchine <dyp(at)perchine(dot)com> |
Cc: | PostgreSQL-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Re: [ANNOUNCE] PostgreSQL 7.0 a success |
Date: | 2000-05-25 04:54:04 |
Message-ID: | 21264.959230444@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-announce pgsql-general |
Denis Perchine <dyp(at)perchine(dot)com> writes:
>> example? some way to recreate for debugging?
> 1. When you have created temp table and just killed frontend. Backend
> realize that connection is broken and somehow did not remove the table
> from pg_class. Then it will exists on the disk and in pg_class.
Hmm. I said to myself "no way", and did "create temp table foo ..."
followed by killing psql from another window. By golly, the pg_temp
file was still there, and it was still listed in pg_class, just as you
said. But then I haven't been able to repeat it in quite a few tries.
So there's a bug there, but it's not too easy to reproduce. Do you
have any idea what contributing conditions might be involved?
> 2. When you do operations with large objects (they are treated as
> relations also) and you do rollback or again connect broken. Or you do
> lots of lo_unlink and rollback or just broke connection.
lo_unlink is not safe to rollback, any more than a plain drop table is.
This is a known deficiency and probably will be for a while. In the
meantime the standard advice is "don't do that".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Denis Perchine | 2000-05-25 05:26:58 | Re: Re: [ANNOUNCE] PostgreSQL 7.0 a success |
Previous Message | Jan Wieck | 2000-05-25 04:21:10 | Re: [GENERAL] Re: PostgreSQL 7.0 a success |
From | Date | Subject | |
---|---|---|---|
Next Message | Denis Perchine | 2000-05-25 05:26:58 | Re: Re: [ANNOUNCE] PostgreSQL 7.0 a success |
Previous Message | harshavardhan | 2000-05-25 04:28:15 | query...urgent |