https://wiki.postgresql.org/api.php?action=feedcontributions&user=Timbunce&feedformat=atomPostgreSQL wiki - User contributions [en]2024-03-29T09:36:26ZUser contributionsMediaWiki 1.35.13https://wiki.postgresql.org/index.php?title=User:Timbunce&diff=12744User:Timbunce2010-12-07T15:31:41Z<p>Timbunce: New page: [http://www.linkedin.com/in/timbunce Tim Bunce] is best known as the author and maintainer of the Perl DBI module, the standard database interface for Perl since 1994. He has contributed t...</p>
<hr />
<div>[http://www.linkedin.com/in/timbunce Tim Bunce] is best known as the author and maintainer of the Perl DBI module, the standard database interface for Perl since 1994. He has contributed to the development of the Perl language and many of its core modules since 1994, and was responsible for the Perl 5.4.x series of maintenance releases.<br />
<br />
[http://blog.timbunce.org/ Blog]</div>Timbuncehttps://wiki.postgresql.org/index.php?title=PGDay_Europe_2010_Talks&diff=12743PGDay Europe 2010 Talks2010-12-07T15:29:08Z<p>Timbunce: /* Glasgow */</p>
<hr />
<div>PGDay.EU 2010 was held in Stuttgart, Germany on December 6th - 8th.<br />
<br />
== Monday, December 6, 2010 ==<br />
<br />
=== Berlin 1+2 ===<br />
<br />
==== 9:45 - 10:45 [[Keynote: Back To The Future of Open Source (Simon Phipps)]]====<br />
==== 11:10 - 12:00 [[Play chess against PostgreSQL (and get beaten) (Gianni Ciolli)]] ====<br />
==== 12:10 - 13:00 [[Rapid Upgrades With Pg_Upgrade (Bruce Momjian)]] ====<br />
==== 14:00 - 14:50 [[PostGIS 1.5 and beyond: a technical perspective (Mark Cave-Ayland, Olivier Courtin)]] ====<br />
==== 15:20 - 16:10 [[Managing PostgreSQL Replication (Simon Riggs)]] ====<br />
<br />
=== Berlin 3 ===<br />
<br />
==== 11:10 - 12:00 [[Media:Postgis_das_wo_in_der_datenbank_pgday_eu_2010.pdf|PostGIS - Das Wo? in der Datenbank (Stefan Keller, Andreas Neumann)]]====<br />
<br />
==== 12:10 - 13:00 [[PostgreSQL als Basis für Detailhandels-Anwendungen (Marc Balmer)]]====<br />
<br />
==== 14:00 - 14:50 [[Media:Pg-community.pdf|Die PostgreSQL Community (Bernd Helmle)]]====<br />
<br />
==== 16:20 - 17:10 [[Media:Pgday-2010-ose-print.pdf|Open Source Entscheidungen]] ([[User:Ads|Andreas Scherbaum]]) ====<br />
<br />
=== Glasgow ===<br />
<br />
=== Tara ===<br />
<br />
<br />
<br />
<br />
== Tuesday, December 7, 2010 ==<br />
<br />
=== Berlin 1+2 ===<br />
<br />
=== Berlin 3 ===<br />
<br />
==== 10:25 - 11:10 [[Media:Pgday_eu_2010_benchmarking.pdf|Benchmarking und Performancetesting von und mit PostgreSQL]] ([[User:mastermind|Stefan Kaltenbrunner]]) ====<br />
<br />
==== 11:35 - 12:20 [[Media:Pgday-2010-mysql-to-pg-print.pdf|Datenbanken von MySQL zu PostgreSQL portieren]] ([[User:Ads|Andreas Scherbaum]]) ====<br />
<br />
=== Glasgow ===<br />
==== 10:25 - 11:10 [http://www.slideshare.net/Tim.Bunce/pl-perl90-201012 PL/Perl new features in 9.0] ([[User:timbunce|Tim Bunce]]) ====<br />
<br />
=== Tara ===</div>Timbuncehttps://wiki.postgresql.org/index.php?title=Working_with_Git&diff=8857Working with Git2009-11-25T15:31:16Z<p>Timbunce: added some detail re formatpatch utility and a link to the later 'Context diffs with Git' section</p>
<hr />
<div>This page collects various wisdom on working with the [http://git.postgresql.org/ PostgreSQL Git repository]. There are also [[Other Git Repositories]] you might work with.<br />
<br />
First off, I'd suggest printing out a copy of the [[Working with CVS]] wiki page, and ''not'' read it. Burn it, it's a great symbolic gesture.<br />
<br />
==Getting Started==<br />
<br />
A simple way to get started might look like this:<br />
<br />
git clone git://git.postgresql.org/git/postgresql.git<br />
cd postgresql<br />
git checkout -b my-cool-feature<br />
$EDITOR<br />
git commit -a<br />
git diff master my-cool-feature | filterdiff --format=context > ../my-cool-feature.patch<br />
<br />
Note that <code>git checkout -b my-cool-feature</code> creates a new branch and checks it out at the same time. Typically, you would develop each feature in a separate branch.<br />
<br />
See the documentation and tutorials at http://git.or.cz/ for a more detailed Git introduction. For a more detailed lesson, check out http://progit.org and maybe get a hardcopy to help support the site.<br />
<br />
You may wish to put the following in your .git/info/exclude [[GitExclude]]<br />
<br />
PostgreSQL developers have traditionally preferred context diffs (<code>diff -c</code>) over unified diffs (<code>diff -u</code>). At least some major committers who you will probably have to run your patch by heavily prefer context diffs. Bizarrely, Git doesn't easily produce context diffs. So there is some need for fiddling around, either using the <code>filterdiff</code> utility as above (from the [http://freshmeat.net/projects/patchutils/ patchutils] distribution) or using the method described in [[#Context diffs with Git|Context diffs with Git]] below.<br />
<br />
=== Keeping your master branch local synchronized ===<br />
<br />
First, add the origin as a remote. You only need to do this once:<br />
<br />
git remote add origin git://git.postgresql.org/git/postgresql.git<br />
<br />
Next, fetch from your public git repository:<br />
<br />
git fetch origin master<br />
<br />
Merge any new patches from your public repository:<br />
<br />
git merge FETCH_HEAD<br />
<br />
Merge in any changes from the main branch:<br />
<br />
git fetch origin master<br />
git merge FETCH_HEAD<br />
<br />
Now check that it still compiles, passes regression, etc. Make sure you've<br />
invoked ./configure, and then:<br />
<br />
make check<br />
make maintainer-clean<br />
<br />
Assuming all that's good, do a dry run.<br />
<br />
git push --dry-run origin master<br />
<br />
If that's happy, push it out to your public repository.<br />
<br />
git push origin master<br />
<br />
If not, fix any merge failures, do an other dry run, and push.<br />
<br />
=== Tracking Other Branches ===<br />
<br />
Lets say you're happy tracking master, but you'd really like to track any one of the other potential branches at git.postgresql.org<br />
<br />
git remote add <super-fun-branch> git://git.postgresql.org/super-fun-branch.git<br />
git fetch super-fun-branch<br />
git checkout super-fun-branch #this will stage your remote branch for a local checkout<br />
git checkout -b super-fun-branch-name #the name can be wahtever you choose<br />
<br />
Now you have a local branch within your local git repo tracking a different branches history. Most importantly, you can now push to that repo if you have to without making an explicit clone to track the history. It's pretty much impossible to not share some common history with the master branch.<br />
<br />
=== Testing a patch ===<br />
<br />
This is a typical setup to review a patch text file, as typically sent by e-mail:<br />
<br />
git checkout -b feature-to-review<br />
git apply --reject --whitespace=fix feature.patch<br />
<br />
If the patch fails to apply, there will be file.rej files left behind showing the part that didn't apply. If your directory tree is clean of build information, you can easily find these later using:<br />
<br />
git status<br />
<br />
=== Context diffs with Git ===<br />
<br />
Copy [http://anarazel.de/pg/git-external-diff git-external-diff] into libexec/git-core/ of your git installation and configure git to use that wrapper with:<br />
<br />
git config [--global] diff.external git-external-diff<br />
<br />
''--global'' makes the configuration global for your user - otherwise it is just configured for the current repository.<br />
<br />
For every command which displays diffs in some way you can use the parameter "--[no-]-ext-diff" to enable respectively disable using the external diff command.<br />
<br />
For the ''git diff'' command ''--ext-diff'' is enabled by default - for any other command like ''git log -p'' or ''git format-patch'' it is not!<br />
<br />
This method should work on all platforms supported by git.<br />
<br />
<br />
If you don't want to configure the external wrapper permanently or you want to overwrite it you can also git like:<br />
<br />
GIT_EXTERNAL_DIFF=git-external-diff git diff --[no-]ext-diff<br />
<br />
<br />
==== Options to diff ====<br />
When using the above wrapper you can overide the options for `diff` by specifying the environment variable ''DIFF_OPTS'' - it defaults to ''-pcd''.<br />
<br />
==Publishing Your Work==<br />
<br />
If you develop a feature over a longer period of time, you want to allow for intermediate review. The traditional approach to that has been emailing huge patches around. The more advanced approach that we want to try (see also Peter Eisentraut's [http://petereisentraut.blogspot.com/2008/02/on-patch-review.html blog entry]) is that you push your Git branches to a private area on <code>git.postgresql.org</code>, where others can pull your work, operate on it using the familiar Git tools, and perhaps even send you improvements as Git-formatted patches. See [http://git.postgresql.org/adm/help the git.postgresql.org site] for instructions on how to sign up, and how to use the repository. You may need to eventually create a patch via e-mail as part of officially [[Submitting a Patch]].<br />
<br />
==Removing a Branch==<br />
<br />
Once your feature has been committed to the PostgreSQL CVS, you can usually remove your local feature branch. This works as follows:<br />
<br />
# switch to a different branch<br />
git checkout master<br />
git branch -D my-cool-feature<br />
<br />
==Using the Web Interface==<br />
<br />
Try the web interface at http://git.postgresql.org/. It offers browsing, "blame" functionality, snapshots, and other advanced features, and it is much faster than CVSweb. Even if you don't care for Git or version control systems, you will probably enjoy the web interface.<br />
<br />
==RSS Feeds==<br />
<br />
The Git service provides RSS feeds that report about commits to the repositories. Some people may find this to be an alternative to subscribing to the pgsql-committers mailing list. The URL for the RSS feed from the PostgreSQL repository is http://git.postgresql.org/?p=postgresql.git;a=rss. Other options are available; they can be found via the [http://git.postgresql.org/ home page] of the web interface.<br />
<br />
==PostgreSQL Style==<br />
<br />
The PostgreSQL source uses 4-character tabs, making the output from <code>git diff</code> look odd. You can fix that by putting this into your.<code>git/config</code> file:<br />
<br />
[core]<br />
pager = less -x4</div>Timbuncehttps://wiki.postgresql.org/index.php?title=Lock_dependency_information&diff=8163Lock dependency information2009-09-25T11:04:14Z<p>Timbunce: Added suggestion re timing and using a CTE. Tweaked the SQL layout to consistently put ON on a new line.</p>
<hr />
<div>{{SnippetInfo|Lock dependency info|lang=sql}}<br />
At times it is very usefull to see which locks depend uppon each other.<br />
<br />
All columns prefixed with ''waiting_'' hold information about the not granted lock, while the colums prefixed with ''other_'' hold information about other locks on the same relation respectively transactionid <br />
<source lang="SQL">SELECT <br />
waiting.locktype AS waiting_locktype,<br />
waiting.relation::regclass AS waiting_table,<br />
waiting_stm.current_query AS waiting_query,<br />
waiting.mode AS waiting_mode,<br />
waiting.pid AS waiting_pid,<br />
other.locktype AS other_locktype,<br />
other.relation::regclass AS other_table,<br />
other_stm.current_query AS other_query,<br />
other.mode AS other_mode,<br />
other.pid AS other_pid,<br />
other.granted AS other_granted<br />
FROM<br />
pg_catalog.pg_locks AS waiting<br />
JOIN<br />
pg_catalog.pg_stat_activity AS waiting_stm<br />
ON (<br />
waiting_stm.procpid = waiting.pid<br />
)<br />
JOIN<br />
pg_catalog.pg_locks AS other<br />
ON (<br />
(<br />
waiting."database" = other."database"<br />
AND waiting.relation = other.relation<br />
)<br />
OR waiting.transactionid = other.transactionid<br />
)<br />
JOIN<br />
pg_catalog.pg_stat_activity AS other_stm<br />
ON (<br />
other_stm.procpid = other.pid<br />
)<br />
WHERE<br />
NOT waiting.granted<br />
AND<br />
waiting.pid <> other.pid<br />
</source><br />
<br />
It would be useful to add extra columns indicating how long the waiting statement has been blocked.<br />
<br />
It should be possible to rewrite this using a CTE ([http://www.postgresql.org/docs/8.4/interactive/queries-with.html WITH RECURSIVE]) query to produce a graph. Contributions welcome! Ideally the graph would include a depth indicator, timing information, and have at the 'top' (lowest depth) those statements causing others to block but which are not blocked themselves.</div>Timbunce