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

Re: Visibility map, partial vacuums

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Visibility map, partial vacuums
Date: 2008-10-28 17:59:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Yes, but there's a problem with recently inserted tuples:

> 1. A query begins in the slave, taking a snapshot with xmax = 100. So 
> the effects of anything more recent should not be seen.
> 2. Transaction 100 inserts a tuple in the master, and commits
> 3. A vacuum comes along. There's no other transactions running in the 
> master. Vacuum sees that all tuples on the page, including the one just 
> inserted, are visible to everyone, and sets PD_ALL_VISIBLE flag.
> 4. The change is replicated to the slave.
> 5. The query in the slave that began at step 1 looks at the page, sees 
> that the PD_ALL_VISIBLE flag is set. Therefore it skips the visibility 
> checks, and erroneously returns the inserted tuple.

But this is exactly equivalent to the problem with recently deleted
tuples: vacuum on the master might take actions that are premature with
respect to the status on the slave.  Whatever solution we adopt for that
will work for this too.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Joshua DrakeDate: 2008-10-28 18:01:04
Subject: Re: PostgreSQL + Replicator developer meeting 10/28
Previous:From: Tom LaneDate: 2008-10-28 17:58:12
Subject: Re: Visibility map, partial vacuums

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