date:20090602

Re: [HACKERS] pg_standby -l might destory the archived file

2009-06-02 Thread Heikki Linnakangas


Fujii Masao wrote:

On Tue, Jun 2, 2009 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:

Fujii Masao masao.fu...@gmail.com writes:

Yes, the old xlog itself is not used again. But, the *old file* might
be recycled and used later. The case that I'm looking at is that the
symlink to a temporary area is recycled. Am I missing something?

Actually, I think the right fix for that would be to add defenses to
xlog.c to not try to recycle a file that is a symlink.


OK, I tweaked Aidan's patch. Thanks Aidan!
http://archives.postgresql.org/message-id/20090601152736.gl15...@yugib.highrise.ca

Changes are:
- use lstat instead of stat
- add #if HAVE_WORKING_LINK and #endif code


Committed. I left out the #ifdef HAVE_WORKING_LINK and used S_ISREG() 
instead of S_ISLNK. We use lstat + S_ISREG elsewhere too, so there 
should be no portability issues.


I backpatched to 8.3, since that's when pg_standby was added. Arguably 
earlier versions should've been changed too, as pg_standby works with 
earlier versions, but I decided to not rock the boat as this only 
affects the pg_standby -l mode.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

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

Re: [HACKERS] PostgreSQL Developer meeting minutes up

2009-06-02 Thread Marko Kreen

On 6/1/09, Markus Wanner mar...@bluegap.ch wrote:
  a newish conversion with cvs2git is available to check here:

   git://www.bluegap.ch/

  (it's not incremental and will only stay for a few days)

+1 for the idea of replacing CVS usernames with full names.

The knowledge about CVS usernames will be increasingly obscure.

Also worth mentioning is that there is no need to assign absolutely
up-to-date email addresses, it's enough if they uniquely identify
person.

  Aidan Van Dyk wrote:
   Yes, but the point is you want an exact replica of CVS right?  You're
   git repo should have $PostgreSQL$ and the cvs export/checkout (you do
   use -kk right) should also have $PostgreSQL$.


 No, I'm testing against cvs checkout, as that's what everybody is used to.


   But it's important, because on *some* files you *do* want expanded
   keywords (like the $OpenBSD ... Exp $.  One of the reasons pg CVS went
   to the $PostgreSQL$ keyword (I'm guessing) was so they could explictly
   de-couple them from other keywords that they didn't want munging on.


 I don't care half as much about the keyword expansion stuff - that's
  doomed to disappear anyway.

But this is one aspect we need to get right for the conversion.

So preferably we test it sooner not later.

I think Aidan got it right - expand $PostgreSQL$ and others that are
actually expanded on current repo, but not $OpenBSD$ and others
coming from external sources.

  What I'm much more interested in is correctness WRT historic contents,
  i.e. that git log, git blame, etc.. deliver correct results. That's
  certainly harder to check.

  In my experience, cvs2svn (or cvs2git) does a pretty decent job at that,
  even in case of some corruptions. Plus it offers lots of options to fine
  tune the conversion, see the attached configuration I've used.


   So, I wouldn't consider any conversion good unless it had all these:
  

  As well as stuff like:
 parsecvs-master:src/backend/access/index/genam.c: *   
 $PostgreSQL$


 I disagree here and find it more convenient for the git repository to
  keep the old RCS versions - as in the source tarballs that got (and
  still get) shipped. Just before switching over to git one can (and
  should, IMO) remove these tags to avoid confusion.

I'd prefer we immediately test full conversion and not leave some
steps to last moment.

-- 
marko

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

Re: [HACKERS] pg_standby -l might destory the archived file

2009-06-02 Thread Fujii Masao

Hi,

On Tue, Jun 2, 2009 at 3:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
 Fujii Masao wrote:

 On Tue, Jun 2, 2009 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:

 Fujii Masao masao.fu...@gmail.com writes:

 Yes, the old xlog itself is not used again. But, the *old file* might
 be recycled and used later. The case that I'm looking at is that the
 symlink to a temporary area is recycled. Am I missing something?

 Actually, I think the right fix for that would be to add defenses to
 xlog.c to not try to recycle a file that is a symlink.

 OK, I tweaked Aidan's patch. Thanks Aidan!

 http://archives.postgresql.org/message-id/20090601152736.gl15...@yugib.highrise.ca

 Changes are:
 - use lstat instead of stat
 - add #if HAVE_WORKING_LINK and #endif code

 Committed. I left out the #ifdef HAVE_WORKING_LINK and used S_ISREG()
 instead of S_ISLNK. We use lstat + S_ISREG elsewhere too, so there should be
 no portability issues.

Thanks a lot!

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

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

[HACKERS] 8.4b2 tsearch2 strange error

2009-06-02 Thread Tatsuo Ishii

Hi,

I have encountered strange errors while testing PostgreSQL 8.4 beta2.

SELECT msg_sid FROM msginfo WHERE plainto_tsquery(E'test') @@
body_index;
or
SELECT msg_sid FROM msginfo WHERE to_tsquery(E'test') @@ body_index;

produces following errors:

ERROR:  tuple offset out of range: 0
(occasionally ERROR:  tuple offset out of range: 459)

Here is the table definition:

CREATE TABLE msginfo (
msg_sid BIGSERIAL PRIMARY KEY,
file_size INTEGER,
file_mtime TIMESTAMP,
msg_date TIMESTAMP,
flags INTEGER,
hdr_from TEXT,
hdr_to TEXT,
hdr_cc TEXT,
hdr_newsgroups TEXT,
hdr_subject TEXT,
hdr_msgid TEXT UNIQUE NOT NULL,
hdr_inreplyto TEXT,
hdr_references TEXT,
body_text TEXT,
body_index TSVECTOR
);
CREATE INDEX msginfo_msg_date_index ON msginfo (msg_date);
CREATE INDEX msginfo_body_index ON msginfo USING gin (body_index);

and other info:

Ubuntu 8.04
./configure --prefix=/usr/local/pgsql84
initdb -E UTF-8 --no-locale /path/to/database

sylph=# EXPLAIN SELECT msg_sid FROM msginfo WHERE to_tsquery('test') @@ 
body_index;
   QUERY PLAN   
 

-
 Bitmap Heap Scan on msginfo  (cost=4.59..8.61 rows=1 width=8)
   Recheck Cond: (to_tsquery('test'::text) @@ body_index)
   -  Bitmap Index Scan on msginfo_body_index  (cost=0.00..4.59 rows=1 width=0)
 Index Cond: (to_tsquery('test'::text) @@ body_index)
(4 rows)
--
Tatsuo Ishii
SRA OSS, Inc. Japan

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

Re: [HACKERS] PostgreSQL Developer meeting minutes up

2009-06-02 Thread Marko Kreen

On 6/2/09, Marko Kreen mark...@gmail.com wrote:
 On 6/1/09, Markus Wanner mar...@bluegap.ch wrote:
a newish conversion with cvs2git is available to check here:
  
 git://www.bluegap.ch/
  
(it's not incremental and will only stay for a few days)

Btw this conversion seems broken as it contains random merge commits.

parsecvs managed to do it without them.

-- 
marko

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

Re: [HACKERS] User-facing aspects of serializable transactions

2009-06-02 Thread Markus Wanner


Hi,

Quoting Greg Stark st...@enterprisedb.com:

No, I'm not. I'm questioning whether a serializable transaction
isolation level that makes no guarantee that it won't fire spuriously
is useful.


It would certainly be an improvement compared to our status quo, where  
truly serializable transactions aren't supported at all. And it seems  
more promising than heading for a perfect *and* scalable implementation.



Heikki proposed a list of requirements which included a requirement
that you not get spurious serialization failures


That requirement is questionable. If we get truly serializable  
transactions (i.e. no false negatives) with reasonably good  
performance, that's more than enough and a good step ahead.


Why care about a few false positives (which don't seem to matter  
performance wise)? We can probably reduce or eliminate them later on.  
But eliminating false negatives is certainly more important to start  
with.


What I'm more concerned is the requirement of the proposed algorithm  
to keep track of the set of tuples read by any transaction and keep  
that set until sometime well after the transaction committed (as  
questioned by Neil [1]). That doesn't sound like a negligible overhead.


Maybe the proposed algorithm has to be applied to pages instead of  
tuples, as they did it in the paper for Berkeley DB. Just to keep that  
overhead reasonably low.


Regards

Markus Wanner

[1]: Neil Conway's blog, Serializable Snapshot Isolation:
http://everythingisdata.wordpress.com/2009/02/25/february-25-2009/

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

Re: [HACKERS] Suggested TODO: allow ALTERing of typemods without heap/index rebuild

2009-06-02 Thread Dimitri Fontaine

Hi,

Josh Berkus j...@agliodbs.com writes:
The stumbling block has been to identify a reasonably clean way
of determining which datatype changes don't require a scan.

Yep. One possibility I'm thinking is supplying a function for each type
which takes two typemods (old and new) and returns a value (none, check,
rebuild) which defines what we need to do: nothing, check but not rebuild,
or rebuild. Default would be rebuild. Then the logic is simple for each
data type.

That seems like a good idea, I don't see how the current infrastructure
could provide enough information to skip this here. Add in there whether
a reindex is needed, too, in the accepted return values (maybe a mask is
needed, such as NOREWRITE|REINDEX).

Note that this doesn't deal with the special case of VARCHAR--TEXT, but
just with changing typemods. Are there other cases of data *type*
conversions where no check or rebuild is required? Otherwise we might just
special case VARCHAR--TEXT.

It seems there's some new stuff for this in 8.4, around the notions of
binary coercibility and type categories, which allow user defined types
to be declared IO compatible with built-in types, e.g. citext/text.

Maybe the case is not so special anymore?

http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=22ff6d46991447bffaff343f4e333dcee188094d

http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=4a3be7e52d7e87d2c05ecc59bc4e7d20f0bc9b17

Oh, here's a general case: changing DOMAINs on the same base type should
only be a check, and changing from a DOMAIN to its own base type should be a
none.

DOMAINs and CASTs are still on the todo list IIRC, so I'm not sure the
current infrastructure around DOMAINs would be flexible (or complete)
enough for the system to determine when the domain A to domain B type
change is binary coercible. It has no CAST information to begin with, I
guess.

As far as reindexing is concerned, talking with RhodiumToad (Andrew
Gierth) on IRC gave insights, as usual. Standard PostgreSQL supports two
data type change without reindex needs: varchar to text and cidr to
inet. In both cases, the types share the indexing infrastructure: same
PROCEDUREs are in use in the OPERATORs that the index is using.

Could it be that we already have the information we need in order to
dynamically decide whether a heap rewrite and a reindex are necessary,
even in case of user defined type conversions?

Regards,
--
dim

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

Re: [HACKERS] PostgreSQL Developer meeting minutes up

2009-06-02 Thread Markus Wanner


Hi,

Quoting Marko Kreen mark...@gmail.com:

I don't care half as much about the keyword expansion stuff - that's
 doomed to disappear anyway.


But this is one aspect we need to get right for the conversion.


What's your definition of right? I personally prefer the keyword  
expansion to match a cvs checkout as closely as possible.



So preferably we test it sooner not later.


I actually *am* testing against that. As mentioned, the only  
differences are insignificant, IMO. For example having 1.1.1.1  
instead of 1.1 (or vice versa, I don't remember).



I think Aidan got it right - expand $PostgreSQL$ and others that are
actually expanded on current repo, but not $OpenBSD$ and others
coming from external sources.


AFAIU Aidan proposed the exact opposite.

I'm proposing to leave both expanded, as in a CVS checkout and as  
shipped in the source release tarballs.



I'd prefer we immediately test full conversion and not leave some
steps to last moment.


IMO that would equal to changing history, so that a checkout from git  
doesn't match a released tarball as good as possible.


What you call leave(ing) some steps to last moment is IMO not part  
of the conversion. It's rather a conscious decision to drop these  
keywords as soon as we switch to git. This step should be represented  
in history as a separate commit, IMO.


What do others think?

Regards

Markus Wanner


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

Re: [HACKERS] User-facing aspects of serializable transactions

2009-06-02 Thread Greg Stark

On Tue, Jun 2, 2009 at 1:13 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
 Greg Stark st...@enterprisedb.com wrote:

 Just as carefully written SQL code can be written to avoid deadlocks
 I would expect to be able to look at SQL code and know it's safe
 from serialization failures, or at least know where they might
 occur.

 This is the crux of our disagreement, I guess.  I consider existing
 techniques fine for situations where that's possible.

a) When is that possible? Afaict it's always possible, you can never
know and when it might happen could change any time.

b) What existing techniques, explicit locking?

 But, could you
 give me an estimate of how much time it would take you, up front and
 ongoing, to do that review in our environment?  About 8,700 queries
 undergoing frequent modification, by 21 programmers, for enhancements
 in our three-month release cycle.  Plus various ad hoc queries.  We
 have one full-time person to run ad hoc data fixes and reports
 requested by the legislature and various outside agencies, like
 universities doing research.

Even in your environment I could easily imagine, say, a monthly job to
delete all records older than 3 months. That job could take hours or
even days. It would be pretty awful for it to end up needing to be
retried. All I'm saying is that if you establish a policy -- perhaps
enforced using views -- that no queries are allowed to access records
older than 3 months you shouldn't have to worry that you'll get a
spurious serialization failure working with those records.


-- 
greg

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

Re: [HACKERS] PostgreSQL Developer meeting minutes up

2009-06-02 Thread Marko Kreen

On 6/2/09, Markus Wanner mar...@bluegap.ch wrote:
  Quoting Marko Kreen mark...@gmail.com:
   I don't care half as much about the keyword expansion stuff - that's
doomed to disappear anyway.
  
 
  But this is one aspect we need to get right for the conversion.
 

  What's your definition of right? I personally prefer the keyword
 expansion to match a cvs checkout as closely as possible.

This is Definitely Wrong (tm).  You seem to be thinking that comparing
GIT checkout to random parallel CVS checkout (eg. from .tgz.) is the
main use-case.  It is not.  Browsing history and looking and diffs
between versions is.  And expanded CVS keywords would be total PITA
for that.

  So preferably we test it sooner not later.
 

  I actually *am* testing against that. As mentioned, the only differences
 are insignificant, IMO. For example having 1.1.1.1 instead of 1.1 (or
 vice versa, I don't remember).

Why have those at all...

  I think Aidan got it right - expand $PostgreSQL$ and others that are
  actually expanded on current repo, but not $OpenBSD$ and others
  coming from external sources.
 

  AFAIU Aidan proposed the exact opposite.

Ah, sorry, my thinko.  s/expanded/stripped/.  Take Aidan's description
as authoritative.. :)

  I'm proposing to leave both expanded, as in a CVS checkout and as shipped
 in the source release tarballs.

No, the noise they add to history would seriously hurt usability.

  I'd prefer we immediately test full conversion and not leave some
  steps to last moment.
 

  IMO that would equal to changing history, so that a checkout from git
 doesn't match a released tarball as good as possible.

We need to compare against tarballs only when checking the conversion.
And only then.  Writing few scripts for that should not be a problem.

  What you call leave(ing) some steps to last moment is IMO not part of the
 conversion. It's rather a conscious decision to drop these keywords as soon
 as we switch to git. This step should be represented in history as a
 separate commit, IMO.

The question is how they should appear in historical commits.

I have no strong opinion whether to edit them out or not in the future.
Doing it during the periodic reindent would be good moment tho'.

-- 
marko

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

Re: [HACKERS] PostgreSQL Developer meeting minutes up

2009-06-02 Thread Markus Wanner


Hi,

Quoting Marko Kreen mark...@gmail.com:

Btw this conversion seems broken as it contains random merge commits.


Well, that's a feature, not a bug ;-)

When a commit adds a file to the master *and* then to the branch as  
well, cvs2git prefers to represent this as a merge from the master  
branch, instead of adding the file twice, once on the master and once  
on the branch.


This way the target VCS knows it's the *same* file, originating from  
one single commit. This may be important for later merges - otherwise  
you may suddenly end up with duplicated files after a merge, because  
the VCS doesn't know they are in fact the same.


(Okay, git assumes two files to have the same origin/history as long  
as they have the same filename. But just rename one of the two, and  
you are have the same troubles, again).


Also note that these situations occur rather frequently in the  
Postgres CVS repository. Every back-patch which adds files ends up as  
a merge. (One could even argue that in the perfect conversion *all*  
back-patches should be represented as merges, rather than as separate  
commits).



parsecvs managed to do it without them.


Now, I'm not calling it broken, but cvs2git's output is arguably  
better in that regard.


As you certainly see by now, conversion from CVS is neither simple nor  
unambiguous.


Regards

Markus Wanner

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

Re: [HACKERS] PostgreSQL Developer meeting minutes up

2009-06-02 Thread Markus Wanner


Hi,

Quoting Marko Kreen mark...@gmail.com:

This is Definitely Wrong (tm).  You seem to be thinking that comparing
GIT checkout to random parallel CVS checkout (eg. from .tgz.) is the
main use-case.  It is not.  Browsing history and looking and diffs
between versions is.  And expanded CVS keywords would be total PITA
for that.


That's an agrument. Point taken. I'll check if cvs2git supports that as well.

Regards

Markus Wanner



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

Re: [HACKERS] PostgreSQL Developer meeting minutes up

2009-06-02 Thread Marko Kreen

On 6/2/09, Markus Wanner mar...@bluegap.ch wrote:
  Quoting Marko Kreen mark...@gmail.com:
  Btw this conversion seems broken as it contains random merge commits.
 

  Well, that's a feature, not a bug ;-)

  When a commit adds a file to the master *and* then to the branch as well,
 cvs2git prefers to represent this as a merge from the master branch, instead
 of adding the file twice, once on the master and once on the branch.

  This way the target VCS knows it's the *same* file, originating from one
 single commit. This may be important for later merges - otherwise you may
 suddenly end up with duplicated files after a merge, because the VCS doesn't
 know they are in fact the same.

  (Okay, git assumes two files to have the same origin/history as long as
 they have the same filename. But just rename one of the two, and you are
 have the same troubles, again).

Not a problem for git I think - it assumes they are same if they have
same contents...

  Also note that these situations occur rather frequently in the Postgres CVS
 repository. Every back-patch which adds files ends up as a merge. (One could
 even argue that in the perfect conversion *all* back-patches should be
 represented as merges, rather than as separate commits).

Well, such behaviour may be a feature for some repo with complex CVS
usage, but currently we should aim for simple and clear conversion.

The question is - do such merges make any sense to human looking at
history - and the answer is no, as no VCS level merge was happening,
just some copying around (if your description is correct).  And
we don't need to add noise for the benefit of GIT as it works fine
without any fake merges.

Our target should be each branch having simple linear history,
without any fake merges.  This will result in minimal confusion
to both humans looking history and also GIT itself.

So please turn the merge logic off.  If this cannot be turned off,
cvs2git is not usable for conversion.

  parsecvs managed to do it without them.
 

  Now, I'm not calling it broken, but cvs2git's output is arguably better in
 that regard.

Seems it contains more complex logic to handle more complex CVS usage
cases, but seems like overkill for us if it creates a mess of history.

  As you certainly see by now, conversion from CVS is neither simple nor
 unambiguous.

I know, thats why I'm discussing the tradeoffs.  Simple+clear vs.
complex+messy. :)

-- 
marko

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

Re: [HACKERS] dot to be considered as a word delimiter?

2009-06-02 Thread Kenneth Marshall

On Mon, Jun 01, 2009 at 08:22:23PM -0500, Kevin Grittner wrote:
 Sushant Sinha sushant...@gmail.com wrote: 
  
  I think that dot should be considered by as a word delimiter because
  when dot is not followed by a space, most of the time it is an error
  in typing. Beside they are not many valid english words that have
  dot in between.
  
 It's not treating it as an English word, but as a host name.
  
 select ts_debug('english', 'Mr.J.Sai Deepak');
  ts_debug
 ---
  (host,Host,Mr.J.Sai,{simple},simple,{mr.j.sai})
  (blank,Space symbols, ,{},,)
  (asciiword,Word, all
 ASCII,Deepak,{english_stem},english_stem,{deepak})
 (3 rows)
  
 You could run it through a dictionary which would deal with host
 tokens differently.  Just be aware of what you'll be doing to
 www.google.com if you run into it.
  
 I hope this helps.
  
 -Kevin
 

In our uses for full text indexing, it is much more important to
be able to find host name and URLs than to find mistyped names.
My two cents.

Cheers,
Ken

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

Re: [HACKERS] PostgreSQL Developer meeting minutes up

2009-06-02 Thread Aidan Van Dyk

* Markus Wanner mar...@bluegap.ch [090602 07:08]:
 Hi,

 Quoting Marko Kreen mark...@gmail.com:
 I don't care half as much about the keyword expansion stuff - that's
  doomed to disappear anyway.

 But this is one aspect we need to get right for the conversion.

 What's your definition of right? I personally prefer the keyword  
 expansion to match a cvs checkout as closely as possible.

 AFAIU Aidan proposed the exact opposite.

 I'm proposing to leave both expanded, as in a CVS checkout and as  
 shipped in the source release tarballs.

Well, since I have -kk set in my .cvsrc, mine matches exactly the CVS
checkout l-)

Basically, I want the git to be identical to the cvs checkout.  If you
use -kk, that means the PostgreSQL CVS repository keywords *aren't*
expanded.  If you like -kv, that means they are.

Pick your poison (after all, it's CVS), either way, I think the 2 of
*us* are going to disagree which is best here ;-)

But, which ever way (exact to -kk or exact to -kv), the conversion
should be exact, and there should be no reason to filter out
keyword-like stuff in the diffs.

 What you call leave(ing) some steps to last moment is IMO not part of 
 the conversion. It's rather a conscious decision to drop these keywords 
 as soon as we switch to git. This step should be represented in history 
 as a separate commit, IMO.

 What do others think?

I'm assuming they will get removed from the source eventually too - but
that step is *outside* the conversion.  Somebody could do it now in CVS
before the conversion, or afterwards, but it's still outside the
conversion.


-- 
Aidan Van Dyk Create like a god,
ai...@highrise.ca   command like a king,
http://www.highrise.ca/   work like a slave.


signature.asc
Description: Digital signature

Re: [HACKERS] User-facing aspects of serializable transactions

2009-06-02 Thread Kevin Grittner

Markus Wanner mar...@bluegap.ch wrote: 
 
 What I'm more concerned is the requirement of the proposed algorithm
 to keep track of the set of tuples read by any transaction and keep
 that set until sometime well after the transaction committed (as
 questioned by Neil). That doesn't sound like a negligible overhead.
 
Quick summary for those who haven't read the paper: with this
non-blocking technique, every serializable transaction which
successfully commits must have its read locks tracked until all
serializable transactions which are active at the commit also
complete.
 
In the prototype implementation, I think they periodically scanned to
drop old transactions, and also did a final check right before
deciding there is a conflict which requires rollback, cleaning up the
transaction if it had terminated after the last scan but in time to
prevent a problem.
 
-Kevin

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

1 2 >

1 - 100 of 160 matches

Mail list logo