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

Re: Hot Standby: Relation-specific deferred conflict resolution

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby: Relation-specific deferred conflict resolution
Date: 2010-02-02 18:27:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Simon Riggs wrote:
> On Fri, 2010-01-29 at 15:01 +0000, Simon Riggs wrote:
>> Putting it back takes time and
>> given enough of that rare cloth, it will eventually be put back.
> Looks like I'll have time to add the starts-at-shutdown-checkpoint item
> back in after all.

Great! Thank you, much appreciated.

> I'd appreciate it if you could review the relation-specific conflict
> patch, 'cos it's still important.

One fundamental gripe I have about that approach is that it's hard to
predict when you will be saved by the cache and when your query will be
canceled. For example, the patch stores only one "latestRemovedXid"
value per lock partition. So if you have two tables that hash to
different lock partitions, and are never both accessed in a single
transaction, the cache will save your query every time. So far so good,
but then you do a dump/restore, and the tables happen to be assigned to
the same lock partition. Oops, a system that used to work fine starts to
get "snapshot too old" errors.

It's often better to be consistent and predictable, even if it means
cancelling more queries. I think wë́'d need to have a much more
fine-grained system before it's worthwhile to do deferred resolution.
There's just too much "false sharing" otherwise.

  Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Andres FreundDate: 2010-02-02 18:34:07
Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Previous:From: Peter EisentrautDate: 2010-02-02 18:25:21
Subject: Re: Using the new libpq connection functions in PostgreSQL binaries

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