Re: synchronous_commit: Developer's View

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: synchronous_commit: Developer's View
Date: 2007-08-30 22:33:32
Message-ID: 87k5rcirer.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:

> Perhaps it would be possible to do this
>
> ALTER FUNCTION fubar SET synchronous_commit = off;
>
> So that any invocation of the function would automatically set all of
> the appropriate parameters prior to execution.

The problem here is that functions don't do commit. So this wouldn't have any
effect unless the setting stayed in effect after the end of the function call.

> Why do I mention this now? Well, on the 8.3 patch status list is the
> concept of "per function search_path". search_path is a parameter, so
> per function search path would seem to imply setting parameters on a per
> function basis, exactly what I'm suggesting for enhancing async commit.

There's a big difference since search_path affects the semantics of the
function itself. The point of having per-function search_path is to ensure
that the function is correctly interpreted in a consistent fashion. Not to
give extra flexibility to change the search_path later.

> Per function parameters could then also be used for other "Statement
> Behaviour" parameters and other related ones, such as ...
>
> default_tablespace, temp_tablespaces, default_transaction_isolation,
> statement_timeout, gin_fuzzy_search_limit, standard_conforming_strings,
> regex_flavour, xmlbinary and xmloption.

Of those standard_conforming_strings and regex_flavour (and no idea about the
xml ones) seem like good matches for binding per-function based on the
defining context.

The others are more DBA-type things which you would expect to be global. If
you want a specific function to create tables in a specific tablespace then
presumably you would just write it to do so. A DBA would be pretty surprised
to find his setting for default_tablespace doesn't have any effect on
pre-existing functions which didn't specify a tablespace.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2007-08-31 00:35:01 Re: synchronous_commit: Developer's View
Previous Message Decibel! 2007-08-30 22:30:07 Password requirement in windows installer