Review: Fix snapshot taking inconsistencies

From: Steve Singer <ssinger_pg(at)sympatico(dot)ca>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Subject: Review: Fix snapshot taking inconsistencies
Date: 2010-10-03 02:08:40
Message-ID: BLU0-SMTP8623EFA6FD99D1F4BA416AAC6B0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


This is my review on the "Fix snapshot taking inconsistencies patch".

The patch applies against master (a13f12b3a18da0a61571cb134fdecea03a10d6f)

However initdb fails with:

FATAL: return type mismatch in function declared to return record
DETAIL: Function's final statement must be SELECT or INSERT/UPDATE/DELETE
RETURNING.
CONTEXT: SQL function "ts_debug"

If I run initdb without the patch applied then apply the patch I can test
the patch. However the regression tests won't run with the patch applied
because they call initdb.

Submission:
============
The patch does not include any documentation updates. I don't feel they
are required. I can't find anywhere in the documentation where it says
to expect the current behavior.

The patch does not include any regression tests. I don't think we have other
tests that (can?) test concurrency patterns like this.

Usability review:
=================
The original thread on hackers debated between changing the behavior of
explain vs changing how rules get executed (so they get a new snapshot). The
consensus seemed to be to leave explain analyze alone and change the current
behavior for rules. This is the route this patch took.

Are there any dangers: Per Marko's comments on the most recent patch:
"This patch still silently breaks pg_parse_and_rewrite()..." this still
seems unresolved. Marko proposed replacing this with something new for SQL
functions. Unfortunately I don't see this as having been followed up on.

I also don't have enough understanding of the code to see exactly how/why it
was broken or what would be involved in fixing it. I don't know if this is
why initdb is failing.

With the patch applied SQL functions still can see changes made by other
transactions after the function starts (ie a function select
$$ pg_sleep(5);insert into bar select * FROM baz;$$ inserts the row into
bar both with and without the patch applied. This is how I would expect a
function (in SQL or any pl) to work.

Does this patch effect anything outside of rules execution? Not that I've
been able to find but I'm probably not qualified to answer that and the
regression tests don't work.

Performance Review
------------------
I don't see this patch impacting performance

Coding Review
------------------
Coding guidelines: no issues that I can find
Portability: no issues
Windows: not tested but I don't see anything that looks suspicious
Comments: no obvious places that require more comments. I don't feel I have
a good enough handle on the code to judge the accuracy of the comments.
Does it do what it says: yes
compiler warnings: no
can I make it crash: initdb issue.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-10-03 03:49:19 Re: is sync rep stalled?
Previous Message Tom Lane 2010-10-02 21:36:55 Re: configure gaps