Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Fix mdsync never-ending loop problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: [HACKERS] Fix mdsync never-ending loop problem
Date: 2007-04-12 13:29:52
Message-ID: 19188.1176384592@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Ok. Perhaps we should not use the canceled-flag but just remove the 
> entry from pendingOpsTable like we used to when mdsync_in_progress isn't 
> set.

I'm not thrilled about that; it seems overly intricate, and won't the
LDC patch make it mostly useless anyway (because of time-extended
checkpointing)?

> I think there's one little bug in the patch:

> 1. AbsorbFsyncRequests is called. A FORGET message is received, and an 
> entry in the hash table is marked as canceled
> 2. Another relation with the same relfilenode is created. This can 
> happen after OID wrap-around
> 3. RememberFsyncRequest is called for the new relation. The old entry is 
> still in the hash table, marked with the canceled-flag, so it's not touched.

Good point.  I was wondering what to do with an already-canceled entry,
but didn't think of that scenario.  I think your fix is not quite right:
if we clear a pre-existing cancel flag then we do need to set cycle_ctr,
because this is effectively an all-new request.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bort, PaulDate: 2007-04-12 13:30:07
Subject: Re: Bug about column references within subqueries used in selects
Previous:From: RonDate: 2007-04-12 13:26:24
Subject: Re: Slow Postgresql server

pgsql-patches by date

Next:From: Guido NeitzerDate: 2007-04-12 14:08:03
Subject: Re: Slow Postgresql server
Previous:From: RonDate: 2007-04-12 13:26:24
Subject: Re: Slow Postgresql server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group