| From: | Sean Chittenden <chitt(at)speakeasy(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, PGBugs List <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Denial of service via VACUUM, all backends exit and restart... |
| Date: | 2004-10-04 23:57:20 |
| Message-ID: | 2119D47A-1661-11D9-B1D0-000A95C705DC@speakeasy.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
>> There exists a crash that could easily be used as a denial of service
>> against PostgreSQL by any user who can call a trusted stored procedure
>> that makes use of temp tables.
>
> What this is actually exposing is a case where CurrentResourceOwner is
> left pointing at garbage. PortalRun saves and restores the caller's
> value of CurrentResourceOwner, which is normally fine and dandy.
> When doing a top-level command such as the VACUUM, CurrentResourceOwner
> is TopTransactionResourceOwner. However, VACUUM does internal
> CommitTransaction and StartTransaction commands, which destroy and
> recreate the whole transaction including TopTransactionResourceOwner.
> In many situations TopTransactionResourceOwner ends up getting
> recreated
> at the same address it was at before, but this is obviously not
> guaranteeable in the general case; Sean's test case simply exposes one
> path in which it isn't at the same address.
FYI, I can confirm that your commit fixes this issue. Thank you very
much! -sc
--
Sean Chittenden
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sean Chittenden | 2004-10-05 00:13:37 | Re: BUG #1276: Backend panics on SETVAL('..', 0)... |
| Previous Message | Sean Chittenden | 2004-10-04 23:17:38 | Re: bgwriter interfering with consistent view of system tables? |