Important 7.0.* fix to ensure buffers are released

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-patches(at)postgreSQL(dot)org
Subject: Important 7.0.* fix to ensure buffers are released
Date: 2000-08-30 21:29:51
Message-ID: 28223.967670991@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Hiroshi Inoue pointed out that Postgres neglects to do an explicit
transaction abort during backend shutdown. For example, in psql
begin;
declare myc cursor for select * from ..;
fetch in myc;
\q
would cause the backend to exit without having released the resources
acquired for the open transaction. This is OK from the point of view
of data integrity (other transactions will believe that the transaction
was aborted) but not OK if shared resources are left locked up. In
particular, this oversight probably accounts for the sporadic reports
we've seen of errors like

NOTICE: FlushRelationBuffers(all_flows, 500237): block 171439 is
referenced (private 0, global 1)
FATAL 1: VACUUM (vc_repair_frag): FlushRelationBuffers returned -2

since shared buffer reference counts would not be released by an
exiting backend, leading to a complaint (perhaps much later) when
VACUUM checks that there are no references to the relation it's
trying to vacuum.

I have fixed this problem in current sources and back-patched the
fix into the 7.0.* branch. But I do not know when or if we'll have
a 7.0.3 release, so for anyone who's been annoyed by this problem
and doesn't want to wait, the patch for 7.0.* is attached.

regards, tom lane

*** src/backend/tcop/postgres.c.orig Sat May 20 22:23:30 2000
--- src/backend/tcop/postgres.c Wed Aug 30 16:47:51 2000
***************
*** 1459,1465 ****
* Initialize the deferred trigger manager
*/
if (DeferredTriggerInit() != 0)
! proc_exit(0);

SetProcessingMode(NormalProcessing);

--- 1459,1465 ----
* Initialize the deferred trigger manager
*/
if (DeferredTriggerInit() != 0)
! goto normalexit;

SetProcessingMode(NormalProcessing);

***************
*** 1479,1490 ****
TPRINTF(TRACE_VERBOSE, "AbortCurrentTransaction");

AbortCurrentTransaction();
! InError = false;
if (ExitAfterAbort)
! {
! ProcReleaseLocks(); /* Just to be sure... */
! proc_exit(0);
! }
}

Warn_restart_ready = true; /* we can now handle elog(ERROR) */
--- 1479,1489 ----
TPRINTF(TRACE_VERBOSE, "AbortCurrentTransaction");

AbortCurrentTransaction();
!
if (ExitAfterAbort)
! goto errorexit;
!
! InError = false;
}

Warn_restart_ready = true; /* we can now handle elog(ERROR) */
***************
*** 1553,1560 ****
if (HandleFunctionRequest() == EOF)
{
/* lost frontend connection during F message input */
! pq_close();
! proc_exit(0);
}
break;

--- 1552,1558 ----
if (HandleFunctionRequest() == EOF)
{
/* lost frontend connection during F message input */
! goto normalexit;
}
break;

***************
*** 1608,1618 ****
*/
case 'X':
case EOF:
! if (!IsUnderPostmaster)
! ShutdownXLOG();
! pq_close();
! proc_exit(0);
! break;

default:
elog(ERROR, "unknown frontend message was received");
--- 1606,1612 ----
*/
case 'X':
case EOF:
! goto normalexit;

default:
elog(ERROR, "unknown frontend message was received");
***************
*** 1642,1651 ****
if (IsUnderPostmaster)
NullCommand(Remote);
}
! } /* infinite for-loop */

! proc_exit(0); /* shouldn't get here... */
! return 1;
}

#ifndef HAVE_GETRUSAGE
--- 1636,1655 ----
if (IsUnderPostmaster)
NullCommand(Remote);
}
! } /* end of main loop */
!
! normalexit:
! ExitAfterAbort = true; /* ensure we will exit if elog during abort */
! AbortOutOfAnyTransaction();
! if (!IsUnderPostmaster)
! ShutdownXLOG();
!
! errorexit:
! pq_close();
! ProcReleaseLocks(); /* Just to be sure... */
! proc_exit(0);

! return 1; /* keep compiler quiet */
}

#ifndef HAVE_GETRUSAGE

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2000-08-30 22:26:52 Re: Patch for TNS services
Previous Message Tom Lane 2000-08-30 20:28:12 Re: Backend-internal SPI operations

Browse pgsql-patches by date

  From Date Subject
Next Message Dominic J. Eidson 2000-08-31 04:27:34 Small SSL-related patch...
Previous Message Tom Lane 2000-08-30 20:28:12 Re: Backend-internal SPI operations