synchronous_commit: Developer's View - Mailing list pgsql-hackers

From Simon Riggs
Subject synchronous_commit: Developer's View
Date
Msg-id 1188509682.4173.42.camel@ebony.site
Whole thread Raw
Responses Re: synchronous_commit: Developer's View  (Gregory Stark <stark@enterprisedb.com>)
Re: synchronous_commit: Developer's View  ("Florian G. Pflug" <fgp@phlo.org>)
Re: synchronous_commit: Developer's View  (David Fetter <david@fetter.org>)
List pgsql-hackers
Async Commit is a useful feature, yet it requires some additional
application code to be added to appropriate transactions. That code is
then clearly version dependent, which may not always be desirable.

It would be good if there was a way to make that a DBA-controllable
setting, much the same as we might execute the following command:
ALTER USER jimbob SET work_mem = ...

The above commmand allows application SQL to be tuned without changes to
the application code itself.

So I'm thinking, is there a way to decorate a transaction in such a way
that only that transaction knows to do SET LOCAL synchronous_commit = off 

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.

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.

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.

To do this, we would need to add a column to pg_proc named and defined:procconfig    text[]
named similarly to the rolconfig column of pg_authid

This would then give us the flexibility to implement per function
search_path as well as the above mentioned uses.

Thoughts?

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment
Next
From: Andrew Dunstan
Date:
Subject: Re: enum types and binary queries