Similarly to a normal PostgreSQL child process, a custom background worker should be running using a loop that can be interrupted with signals to update a given status or simply exit the process. Two types of signals are handled by custom background workers in the PostgreSQL architecture: SIGHUP and SIGTERM.

When such signals are received by a bgworker, you should be aware that processing similar to what is done for a normal backend process might be needed. For example, if your custom bgworker uses some GUC parameters, the process needs to take proper action to reload configuration parameters. Even if there are already good examples in the PostgreSQL source code for bgworkers, I noticed that there are no examples focusing only on certain fundamentals of bgworker. As someone who likes simple things, I think that this is essential to get the essence of what this feature can do piece by piece.

So here is in this post an example of bgworker that I wrote for beginners in order to understand only the fundamentals of signal handling. First you need to know that it is necessary to store a static variable to store the status of representing if signal has been activated or not in a way similar to that:
static bool got_sigterm = false;
static bool got_sighup = false;

You also need dedicated functions to set those flags to true if a signal is received by the worker.
static void
hello_sigterm(SIGNAL_ARGS)
{
 got_sigterm = true;
}
 
static void
hello_sighup(SIGNAL_ARGS)
{
 got_sighup = true;
}

A dedicated function that is used as a main loop for processing is essential as well.
static void
hello_main(void *main_arg)
{
 /* We're now ready to receive signals */
 BackgroundWorkerUnblockSignals();
 while (true)
 {
  /* Process signals */
  if (got_sighup)
  {
   got_sighup = false;
   ereport(LOG, (errmsg("hello signal: processed SIGHUP")));
  }
 
  if (got_sigterm)
  {
   /* Simply exit */
   ereport(LOG, (errmsg("hello signal: processed SIGTERM")));
   proc_exit(0);
  }
 }
 proc_exit(0)
}

Note the call to BackgroundWorkerUnblockSignals. This is extremely important in order to allow the reception of signals by the background worker.

Once you have this basic infrastructure in place, you need to register this worker process correctly with something like that:
void
_PG_init(void)
{
 BackgroundWorker worker;
 worker.bgw_flags = 0;
 worker.bgw_start_time = BgWorkerStart_PostmasterStart;
 worker.bgw_main = hello_main;
 worker.bgw_sigterm = hello_sigterm;
 worker.bgw_sighup = hello_sighup;
 worker.bgw_name = "hello_signal";
 /* Wait 10 seconds for restart before crash */
 worker.bgw_restart_time = 10;
 worker.bgw_main_arg = NULL;
 RegisterBackgroundWorker(&worker);
}

Also don’t forget that you need a header similar to that to have this code working properly.
/* Some general headers for custom bgworker facility */
#include "postgres.h"
#include "fmgr.h"
#include "postmaster/bgworker.h"
#include "storage/ipc.h"
 
/* Allow load of this module in shared libs */
PG_MODULE_MAGIC;
 
/* Entry point of library loading */
void _PG_init(void);

Also, be sure that when you create a custom background worker, signal handling is similar to what is done for normal backend process. For example, the configuration file reload should be processed if SIGHUP is received. You can do that properly by calling ProcessConfigFile in a manner similar to that in the main loop.
if (got_sighup)
{
 /* Process config file */
 ProcessConfigFile(PGC_SIGHUP);
 got_sighup = false;
 ereport(LOG, (errmsg("hello signal: processed SIGHUP")));
}

In order to bring more fluidity to you custom worker and not have it use all the CPU of your server by running continuously, don’t forget to define a latch to control some sleep period of your worker. It can be defined with that:
/* The latch used for this worker to manage sleep correctly */
static Latch signalLatch;

Then when entering in the main loop process, initialize the latch with that:
InitializeLatchSupport();
InitLatch(&signalLatch);

Finally you need to set up your main loop to use the latch
while (true)
{
 int rc;
 
 /* Wait 1s */
 rc = WaitLatch(&signalLatch,
   WL_LATCH_SET | WL_TIMEOUT | WL_POSTMASTER_DEATH,
   1000L);
 ResetLatch(&signalLatch);
 
 /* Emergency bailout if postmaster has died */
 if (rc & WL_POSTMASTER_DEATH)
  proc_exit(1);
 
 [... code for signal handling ...]
}

You can also set up the latch such as the sleep will stop immediately if a signal is received. Simply add the following call in hello_sighup and hello_sigterm to do that.
SetLatch(&signalLatch);

This code can be found on Github as repository pg_workers. I created it to group all the bgworker examples I wrote using the facility of PostgreSQL 9.3 and above. You can find the example presented in this post in the folder hello_signal.

This article is made using Eclipse 3.7 and its famous plug-in dedicated to GIT called Egit.

When working on a java project, eclipse is a nice way to implement, code and debug. It is even nicer when it can be used with a version controller like GIT. Since Eclipse 3.5, GIT has its own plug-in called EGit. Let’s be honest. It rocks. The interface is well-thought, and you can manage easily your GIT repository through friendly interface. In case you get crazy with some error messages, you can still easily fallback to the good-old command terminal, and everything made will still be visible in Eclipse. That is really a nice tool

However, when starting a new Java project from an existing GIT repository, you can easily import your project by doing Files -> Import. Then in the import window, select Git -> Projects from GIT.
And in a couple of clicks, you are able to clone existing repositories, and add new projects. The problem is that you generally need to import the code as a general project, and under Eclipse it will be recognized as a Java project.

There is a workaround for this problem after importing a GIT code as a general project. You first need to modify the .project file in the project repository and modify it as below to make it a Java project.
<projectDescription>
 <name>my_project</name>
 <comment></comment>
 <projects>
 </projects>
 <buildSpec>
  <buildCommand>
   <name>org.eclipse.jdt.core.javabuilder</name>
   <arguments>
   </arguments>
  </buildCommand>
   </buildSpec>
   <natures>
    <nature>org.eclipse.jdt.core.javanature</nature>
   </natures>
</projectDescription>

Then, restart eclipse. So now the project became a Java project, but there are still no JRE libraries.
In order to do that, modify .classpath as follows:
<classpath>
  <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
</classpath>

What remains to do, depending on the project is to add at least a source folder. This can be done by right-clicking on the project, then New -> Source Folder.
And you are done.

Developers are sometimes looking for cheap solutions to have their own private repositories. There are multiple solutions for open source software such as source forge or GitHub that can provide wide and secured functionalities. However, in the case of the 1st solution it is not possible to create private repositories, and in the second case private repositories are possible but this solution is not worth the money for independant programmers.

The cheapest solution remains in having its own hosting service (buying a domain, creating a free domain, etc). Google that will for sure lead you to free services with dedicated domain names for example.

Most of the time such hosting services are shared-hosting based. This means that multiple users are using the same server for their websites. In this case normal users do not have root rights (well, normal!), so it is impossible to make fine settings of the configuration files of apache, like httpd.conf.

GIT supports http protocol for its repositories for a long time, but the original protocol uses WebDAV and is really heavy and slow. Roughly, you needed to send to remote server entire files and not diffs. However, since version 1.6.6, GIT supports smart HTTP protocol, this has speed up http repositories and you do not even need WebDAV. An important point, WebDAV can be activated in httpd.conf of your apache server with the keywords “DAV On” but this creates an error, that’s why the solution presented here only uses smart http.

So, to set your GIT repositories, what is needed first is GIT installed on your server.
git --version
git version 1.7.0.4

The important point is to have support of the command git-http-backend.

This done, you also need the apache modules mod_cgi, mod_alias, and mod_env to be activated.

Now, let’s go through the whole setting process. In the case of this tutorial, our goal is to create a private repository for a project called foo-project. The private repositories that will be set are protected in read and write by apache group management.

From the root repository of your domain http://www.example.com/, if you have a connection through ssh, go to the root repository that should be called public_html. Then type the following command:
htpasswd -c .htpasswd user-name
You can also do that in another folder or in a subdomain of course.

You will be requested to write a password. This command will create a file called .htpasswd containing data like this:
user-name: $encrypted-passwd
“user-name” can be the name you want. It is an apache-level security group, so if you want you don’t need to use the same user name as your Linux session. This file contains user and password data for the access to private repositories.

It is possible to add new users to this file with commands like:
htpasswd .htpasswd new-user-name

Then create a file called .htgroup. It contains the following data:
foo_write: user-name new-user-name
This file will be used to control the group data of apache. You can create for each private repository a group with a list of users. One line has to be used for each group. Keep in mind that it is easier to maintain the group list in a common file. However you can set group file in different files if you wish. Just don’t forget to list those files in appropriate .htaccess files.

Then it is time to create the access control to private repositories. Create a folder called git in the root folder public_html and move in it:
mkdir git
cd git

There you need to create a new CGI script that will be used to rewrite requested URL for private GIT repositories. With an editor, create a file called git-http-backend.cgi with the following data in it.
#!/bin/sh
#first we export the GIT_PROJECT_ROOT
export GIT_PROJECT_ROOT=/to/site/folder/public_html/git/
 
if [ -z "$REMOTE_USER" ]
then
 export REMOTE_USER=$REDIRECT_REMOTE_USER
fi
 
#and run your git-http-backend
/usr/bin/git-http-backend

GIT_PROJECT_ROOT is an environment variable pointing to the root folder of your GIT repositories. A mistake here may lead to an error 500…

Depending on the server of your shared hosting service, git-http-backend may not be in /usr/bin/ but in /usr/lib/git-core/ or whatever. Be sure to check where it is with the command:
which git-http-backend

Then create an .htaccess file in git to control URL rewrite. It contains the data:
Options +ExecCgi
 
#This is used for group/user access control
AuthName "Private Git Access"
AuthType Basic
AuthUserFile /to/site/folder/public_html/.htpasswd
AuthGroupFile /to/site/folder/public_html/.htgroup
Require valid-user
 
#This is the rewrite algorithm
RewriteEngine on
RewriteBase /git
SetHandler cgi-script
RewriteRule ^([a-zA-Z0-9._]*\.git/(HEAD|info/refs|objects/(info/[^/]+|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))|git-(upload|receive)-pack))$ /git/git-http-backend.cgi/$1

Then it is time to create the GIT repository of foo-project and move in it.
mkdir foo-project.git
cd foo-project.git

Now you should be in folder /to/site/folder/public_html/git/foo-project.git.

Then initialize your GIT repository with the following commands.
git --bare init
git --bare update-server-info
cp hooks/post-update.sample hooks/post-update
chmod a+x hooks/post-update
touch git-daemon-export-ok

This basically makes all the necessary settings to allow your folder to use smart http mode. If you don’t care about GIT details, just copy/paste that!

What finally remains is to create an .htaccess file in public_html/git/foo-project.git to control access to this repository.
Allow from all
Order allow,deny
#foo_write is the group is .htgroup. All the users of this group will be authorized to access this repository at will.
Require group foo_write

The setting on remote side is done. So now, here is how to access to the remote from your local machine.
You may either clone the new git repository.
git clone http://www.example.com/git/foo-project.git

Or add a remote URL.
mkdir myproject
cd myproject
git init
git remote add myproj http://www.example.com/git/foo-project.git
git fetch myproj

It may be necessary to install the library curl and set the file called .netrc in your home repository (accessible with $HOME/.netrc) like this:
machine www.example.com
login user-name
password $mypasswd

If you don’t want to use .netrc file you can directly add you user name in the remote URL.
http://www.example.com/git/foo-project.git
Becomes
http://user-name@example.com/git/foo-project.git
In this case you will be requested a password each time you interact with the remote folder. This is annoying so you should stick with curl.

Then, manage your folder as you always do. First begin by pushing your first commits to your newly-made repository. Here is an example:
echo "My first commit" > README
git add README
git commit -a
git push origin master

When pushing to your repository, you may find upload package errors. A common message is:
error: unpack failed: unpack-objects abnormal exit
Don’t panic. You made it well. It should not occur normally but it may happen in certain environments. This is a write permission issue. Be sure to have the repository “objects” set with correct write permissions to allow a push to be written correctly in remote repository.

An additional tip…
There are also a nice pure php solution to allow you to have a gitweb-like service in pure PHP.
GitPHP is a web frontend for git repositories. This is extremely handy in a shared hosting environment as you do not need to set httpd.conf and you don’t need root rights on your server.

©2010-2013 Michael Paquier All content is ©Copyright of Otacoo.com 2010-2013. Privacy Policy - Terms of Use