Thread: BUG #1917: autovaccuum crashes
The following bug has been logged online: Bug reference: 1917 Logged by: Theo Schlossnagle Email address: jesus@omniti.com PostgreSQL version: 8.1devel Operating system: CentOS 4.1 (Linux 2.6.12.3) Description: autovaccuum crashes Details: We're running an otherwise idle instance. Doing large data loads via the COPY command into a set of schema-identical tables table1, table2, table3 all of which inherrit table. (simulating Oracle's partitioning). Periodically, we get: LOG: autovacuum process (PID 9685) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2005-09-27 09:12:49 PDT ... LOG: autovacuum process (PID 10116) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2005-09-27 10:39:19 PDT ... LOG: autovacuum process (PID 10626) was terminated by signal 11 LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. The process doesn't seem to dump core.
On Wed, Sep 28, 2005 at 04:21:16AM +0100, Theo Schlossnagle wrote: > Doing large data loads via the COPY command into a set of schema-identical > tables table1, table2, table3 all of which inherrit table. (simulating > Oracle's partitioning). Periodically, we get: > > > LOG: autovacuum process (PID 9685) was terminated by signal 11 > LOG: terminating any other active server processes > LOG: all server processes terminated; reinitializing > LOG: database system was interrupted at 2005-09-27 09:12:49 PDT > The process doesn't seem to dump core. Please run "ulimit -c unlimited" and restart the postmaster, to try to get a core dump. (It should be in the data/ directory, not in the data/base/<oid>/ directory as it used to be in previous versions.) If it doesn't work, please provide more details on your schema. I'm going to try to reproduce your problem here. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC Tulio: oh, para qué servirá este boton, Juan Carlos? Policarpo: No, aléjense, no toquen la consola! Juan Carlos: Lo apretaré una y otra vez.
I wrote > On Wed, Sep 28, 2005 at 04:21:16AM +0100, Theo Schlossnagle wrote: > > > Doing large data loads via the COPY command into a set of schema-identical > > tables table1, table2, table3 all of which inherrit table. (simulating > > Oracle's partitioning). Periodically, we get: > > > > > > LOG: autovacuum process (PID 9685) was terminated by signal 11 > > LOG: terminating any other active server processes > > LOG: all server processes terminated; reinitializing > > LOG: database system was interrupted at 2005-09-27 09:12:49 PDT > > > The process doesn't seem to dump core. > > Please run "ulimit -c unlimited" and restart the postmaster, to try to > get a core dump. (It should be in the data/ directory, not in the > data/base/<oid>/ directory as it used to be in previous versions.) > > If it doesn't work, please provide more details on your schema. I'm > going to try to reproduce your problem here. I tried and failed. Please post more details, and the exact version you are using (for example the date you pulled the CVS or nightly snapshot, or specify if this is a released beta.) A sample schema may be useful too, though I don't see a problem with inheritance by itself. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34 Si no sabes adonde vas, es muy probable que acabes en otra parte.