pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Erik Rijkers <er@xs4all.nl>
Cc: Kevin Grittner <kgrittn@mail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: foreign key locks
Date: Fri, 18 Jan 2013 21:46:43 +0100
Message-ID: <20130118204643.GA4359@awork2.anarazel.de> (raw)
In-Reply-To: <28623.1358541467@sss.pgh.pa.us>
References: <20121129152326.69330@gmx.com>
	<20121129160220.GA4942@alvh.no-ip.org>
	<20121129161654.GB4942@alvh.no-ip.org>
	<b1a78c715f9195e6f96546c8e723afd8.squirrel@webmail.xs4all.nl>
	<20121228204847.GD4150@alvh.no-ip.org>
	<20130110210040.GB4110@alvh.no-ip.org>
	<20130118200204.GH4063@alvh.no-ip.org>
	<28623.1358541467@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 2013-01-18 15:37:47 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > The reason is that there is an (unknown to me) rule that there must be
> > some data not associated with a buffer:
> 
> > 	/*
> > 	 * NOTE: We disallow len == 0 because it provides a useful bit of extra
> > 	 * error checking in ReadRecord.  This means that all callers of
> > 	 * XLogInsert must supply at least some not-in-a-buffer data. [...]
> > 	 */
> 
> > This seems pretty strange to me.  And having the rule be spelled out
> > only in a comment within XLogInsert and not at its top, and not nearby
> > the XLogRecData struct definition either, seems pretty strange to me.
> > I wonder how come every PG hacker except me knows this.
> 
> I doubt it ever came up before.  What use is logging only the content of
> a buffer page?  Surely you'd need to know, for example, which relation
> and page number it is from.

It only got to be a length of 0 because the the data got removed due to
a logged full page write. And the backup block contains the data about
which blocks it is logging in itself.
I wonder if the check shouldn't just check write_len instead, directly
below the loop that ads backup blocks.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (74+ messages)  latest in thread

Message-ID: <20130118204643.GA4359@awork2.anarazel.de>
Permalink:  ../20130118204643.GA4359@awork2.anarazel.de/
Also on:    postgresql.org/message-id/20130118204643.GA4359@awork2.anarazel.de

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: andres@2ndquadrant.com, tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, er@xs4all.nl, kgrittn@mail.com
  Subject: Re: foreign key locks
  In-Reply-To: <20130118204643.GA4359@awork2.anarazel.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox