serverless postgresql

[Chris Ochs]

Re: embedded/"serverles s" (Re: serverless postgresql)


Personally, I would use something like berkelydb for an embedded database
engine. As a general rule, if it needs to be embedded, you don't need sql.
I'm sure you could think of areas where you could use a full blown sql
server, but in practice that generally isn't the case. And like others
have already mentioned, if you are embedding a database in software that a
user has control of, you want it as SIMPLE as possible.

Chris



----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa .us>
To: "Rick Gigger" <rick@alpinenet working.com>
Cc: "Chris Travers" <chris@travelam ericas.com>; "David Garamond"
<lists@zara.6.i sreserved.com>; "Jeff Bowden" <jlb@houseofdis traction.com>;
"pgsql-general" <pgsql-general@postgre sql.org>
Sent: Friday, January 16, 2004 1:14 PM
Subject: Re: embedded/"serverless " (Re: [GENERAL] serverless postgresql)

[color=blue]
> "Rick Gigger" <rick@alpinenet working.com> writes:[color=green][color=darkred]
> >> ... just adds potential for mucking things up. I can see the bug
> >> reports now: "I decided I'd make the shutdown routine 'kill -9' the
> >> postmaster because I didn't like the multi-second delay for a normal
> >> shutdown. Now my database is corrupt."[/color][/color]
>[color=green]
> > I recall a discussion a while back where people were complaining that[/color][/color]
some[color=blue][color=green]
> > os (I think it was mac os x) would just kill all proccesses after[/color][/color]
something[color=blue][color=green]
> > like 30 seconds on system shutdown if they didn't quit fast enough on[/color][/color]
their[color=blue][color=green]
> > own. The response was that because of how postgres uses wal files to
> > prevent db corruption this was not an issue. Why does this not apply in
> > this situation?[/color]
>
> Because a system shutdown doesn't leave anything else running. kill -9
> on the postmaster leaves orphaned backends still running, and orphaned
> shared memory segments still in existence. The latter could prevent you
> from starting a fresh postmaster (because two shmem segments could
> exceed the kernel's SHMMAX) until you do manual cleanup, which most
> people don't know how to do. If you do succeed in starting another
> postmaster with a fresh shared memory segment, you will have two
> independent sets of backends modifying the database files with no
> interlocking, which is a sure recipe for data corruption.
>
> There is an interlock that is supposed to prevent this catastrophic
> scenario, but I do not trust it unreservedly (and not at all on
> non-Unix-derived platforms, because it depends on some rather arcane
> features of the SysV shared memory API, which might not be implemented
> fully on other platforms).
>
> This is why the "don't kill -9 the postmaster" TIP is still around, BTW.
> It has nothing to do with crash safety.
>[color=green]
> > By saying "the client can scribble on the database anyway" do you do you
> > mean the client app actually writing over the db files on disk? It[/color][/color]
seems[color=blue][color=green]
> > like this would only be a problem with an exceptionally stupid[/color][/color]
programmer.[color=blue][color=green]
> > How could that happen on accident?[/color]
>
> Scribbling on memory that doesn't belong to you isn't something one does
> intentionally, either --- but it happens. However, my real concern here
> is not so much with program bugs as clueless users. We see enough cases
> already of people removing lock files or "unnecessar y" log files; I fear
> it'd be a lot worse if those files were sitting in the user's home
> directory.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org
>[/color]


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Jonathan Bartlett]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

> Personally, I would use something like berkelydb for an embedded database[color=blue]
> engine. As a general rule, if it needs to be embedded, you don't need sql.
> I'm sure you could think of areas where you could use a full blown sql
> server, but in practice that generally isn't the case. And like others
> have already mentioned, if you are embedding a database in software that a
> user has control of, you want it as SIMPLE as possible.[/color]

But the user isn't the one accessing the database directly. Have you ever
used a program like Delphi to create applications? Using a relational
database, you can create applications using nothing but drag-and-drop and
SQL. No real code. If your application is a simple end-user app (like a
wedding planner, for example), embedded databases are your dream come
true. Linux has no real embedded database. PG would be an excellent
embedded database. I have already proposed some functions that would help
PG as an embedded database, and, if I hve time, I will implement them
(can't right now because I'm finishing a book).

Anyway, I get the feeling that those people who don't like the idea of
having PG as an embedded database have never used one. I think Tom, for
example, has been focusing on enterprise-level applications too much to
think about the personal applications, and Chris, I'm going to guess
you've never built an application w/ an embedded DB.

Anyway, this thread is going nowhere, I'll come back if/when I have some
code. Perhaps with something concrete we can all see better where this is
going.

Jon
[color=blue]
>
> Chris
>
>
>
> ----- Original Message -----
> From: "Tom Lane" <tgl@sss.pgh.pa .us>
> To: "Rick Gigger" <rick@alpinenet working.com>
> Cc: "Chris Travers" <chris@travelam ericas.com>; "David Garamond"
> <lists@zara.6.i sreserved.com>; "Jeff Bowden" <jlb@houseofdis traction.com>;
> "pgsql-general" <pgsql-general@postgre sql.org>
> Sent: Friday, January 16, 2004 1:14 PM
> Subject: Re: embedded/"serverless " (Re: [GENERAL] serverless postgresql)
>
>[color=green]
> > "Rick Gigger" <rick@alpinenet working.com> writes:[color=darkred]
> > >> ... just adds potential for mucking things up. I can see the bug
> > >> reports now: "I decided I'd make the shutdown routine 'kill -9' the
> > >> postmaster because I didn't like the multi-second delay for a normal
> > >> shutdown. Now my database is corrupt."[/color]
> >[color=darkred]
> > > I recall a discussion a while back where people were complaining that[/color][/color]
> some[color=green][color=darkred]
> > > os (I think it was mac os x) would just kill all proccesses after[/color][/color]
> something[color=green][color=darkred]
> > > like 30 seconds on system shutdown if they didn't quit fast enough on[/color][/color]
> their[color=green][color=darkred]
> > > own. The response was that because of how postgres uses wal files to
> > > prevent db corruption this was not an issue. Why does this not apply in
> > > this situation?[/color]
> >
> > Because a system shutdown doesn't leave anything else running. kill -9
> > on the postmaster leaves orphaned backends still running, and orphaned
> > shared memory segments still in existence. The latter could prevent you
> > from starting a fresh postmaster (because two shmem segments could
> > exceed the kernel's SHMMAX) until you do manual cleanup, which most
> > people don't know how to do. If you do succeed in starting another
> > postmaster with a fresh shared memory segment, you will have two
> > independent sets of backends modifying the database files with no
> > interlocking, which is a sure recipe for data corruption.
> >
> > There is an interlock that is supposed to prevent this catastrophic
> > scenario, but I do not trust it unreservedly (and not at all on
> > non-Unix-derived platforms, because it depends on some rather arcane
> > features of the SysV shared memory API, which might not be implemented
> > fully on other platforms).
> >
> > This is why the "don't kill -9 the postmaster" TIP is still around, BTW.
> > It has nothing to do with crash safety.
> >[color=darkred]
> > > By saying "the client can scribble on the database anyway" do you do you
> > > mean the client app actually writing over the db files on disk? It[/color][/color]
> seems[color=green][color=darkred]
> > > like this would only be a problem with an exceptionally stupid[/color][/color]
> programmer.[color=green][color=darkred]
> > > How could that happen on accident?[/color]
> >
> > Scribbling on memory that doesn't belong to you isn't something one does
> > intentionally, either --- but it happens. However, my real concern here
> > is not so much with program bugs as clueless users. We see enough cases
> > already of people removing lock files or "unnecessar y" log files; I fear
> > it'd be a lot worse if those files were sitting in the user's home
> > directory.
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org
> >[/color]
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>[/color]


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

Jeff Bowden <jlb@houseofdis traction.com> writes:[color=blue]
> Still, the main problem I, and I suspect others, would like to solve is
> installation/configuration. For my app I don't want the user to have to
> understand anything about how keeping data in a shared
> system-administered database is different from keeping data in local
> files. Everything should "just work".[/color]

Sure, but most of the existing packagings of PG already try to make this
automatic (at least Lamar's RPMs and Oliver's Debian package do). No
doubt further work could be invested to make it even smoother, but that
doesn't mean we need a client-started database.
[color=blue]
> So kill -9 on postmaster can lead to database corruption? What happens
> in a power failure?[/color]

See my last response to Rick Gigger. kill -9 is a lot different from a
power failure.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Andrew Sullivan]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

On Fri, Jan 16, 2004 at 02:00:35PM -0800, Jonathan Bartlett wrote:
[color=blue]
> having PG as an embedded database have never used one. I think Tom, for
> example, has been focusing on enterprise-level applications too much to
> think about the personal applications, and Chris, I'm going to guess[/color]

This seems to suggest that Postgres should focus on something other
than enterprise-level applications, and (presumably) on something
else.

Frankly, I am _mighty glad_ that the developers are focussed on
enterprise-level applications. That's what makes Postgres eligible
to back enterprise-level software. Applications that try to do
everything for everyone tend to end up doing nothing very well. I
don't think one needs to look too hard to discover examples of that
phenomenon.

A

--
Andrew Sullivan | ajs@crankycanuc k.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[Jeff Bowden]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

Tom Lane wrote:
[color=blue]
>Jeff Bowden <jlb@houseofdis traction.com> writes:
>
>[color=green]
>>Still, the main problem I, and I suspect others, would like to solve is
>>installatio n/configuration. For my app I don't want the user to have to
>>understand anything about how keeping data in a shared
>>system-administered database is different from keeping data in local
>>files. Everything should "just work".
>>
>>[/color]
>
>Sure, but most of the existing packagings of PG already try to make this
>automatic (at least Lamar's RPMs and Oliver's Debian package do). No
>doubt further work could be invested to make it even smoother, but that
>doesn't mean we need a client-started database.
>[/color]

So maybe this is a packaging issue. On Debian when I install postgres
it is necessary to do root shit in order to enable non-priveledged users
to create and destroy databases. My understanding has alwasy been that
these operations are restricted because it can allow users to
accidentally or intentionally interefere with each other's use of the
server. If there is some way for this to be set up sanely by default to
allow users to successfully use createdb and dropdb on only their own
data, then I will file a wishlist bug against the Debian packages to add
this. Or is this all a pipe dream?



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Jonathan Bartlett]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

> This seems to suggest that Postgres should focus on something other[color=blue]
> than enterprise-level applications, and (presumably) on something
> else.[/color]

Nope.
[color=blue]
>
> Frankly, I am _mighty glad_ that the developers are focussed on
> enterprise-level applications.[/color]

Me too. But I think we can get it for small-scale stuff with no impact on
the rest. Just an additional function or 6 to make embedded developer's
lives easier.

Jon



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Nigel J. Andrews]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

On Fri, 16 Jan 2004, Jeff Bowden wrote:
[color=blue]
> Tom Lane wrote:
>[color=green]
> >Jeff Bowden <jlb@houseofdis traction.com> writes:
> >
> >[color=darkred]
> >>Still, the main problem I, and I suspect others, would like to solve is
> >>installatio n/configuration. For my app I don't want the user to have to
> >>understand anything about how keeping data in a shared
> >>system-administered database is different from keeping data in local
> >>files. Everything should "just work".
> >>
> >>[/color]
> >
> >Sure, but most of the existing packagings of PG already try to make this
> >automatic (at least Lamar's RPMs and Oliver's Debian package do). No
> >doubt further work could be invested to make it even smoother, but that
> >doesn't mean we need a client-started database.
> >[/color]
>
> So maybe this is a packaging issue. On Debian when I install postgres
> it is necessary to do root shit in order to enable non-priveledged users
> to create and destroy databases. My understanding has alwasy been that
> these operations are restricted because it can allow users to
> accidentally or intentionally interefere with each other's use of the
> server. If there is some way for this to be set up sanely by default to
> allow users to successfully use createdb and dropdb on only their own
> data, then I will file a wishlist bug against the Debian packages to add
> this. Or is this all a pipe dream?[/color]

I don't see what the problem is. PostgreSQL is perfectly able to be installed
and run as any old user. Even if one is distributing via a package system, such
as RPM perhaps, which has problems installing as non-root user if one sees the
package already installed then there's no need to try to install it
again. Even with the package installations there's bugger all stopping any old
user doing an initdb -D myownplace.

The standard postgres user on a system is only special in that it is generally
the user the postmaster is run as. If you have other non-priviledged users and
there's no need for them to share a cluster why try to make them?


--
Nigel Andrews



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Jeff Bowden]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

Nigel J. Andrews wrote:
[color=blue]
>On Fri, 16 Jan 2004, Jeff Bowden wrote:
>
>[color=green]
>>So maybe this is a packaging issue. On Debian when I install postgres
>>it is necessary to do root shit in order to enable non-priveledged users
>>to create and destroy databases. My understanding has alwasy been that
>>these operations are restricted because it can allow users to
>>accidentall y or intentionally interefere with each other's use of the
>>server. If there is some way for this to be set up sanely by default to
>>allow users to successfully use createdb and dropdb on only their own
>>data, then I will file a wishlist bug against the Debian packages to add
>>this. Or is this all a pipe dream?
>>
>>[/color]
>
>I don't see what the problem is. PostgreSQL is perfectly able to be installed
>and run as any old user. Even if one is distributing via a package system, such
>as RPM perhaps, which has problems installing as non-root user if one sees the
>package already installed then there's no need to try to install it
>again. Even with the package installations there's bugger all stopping any old
>user doing an initdb -D myownplace.
>
>The standard postgres user on a system is only special in that it is generally
>the user the postmaster is run as. If you have other non-priviledged users and
>there's no need for them to share a cluster why try to make them?
>
>[/color]

I'm sorry, maybe I didn't state my ideas clearly enough. I was
following on to Tom Lane's suggestion that the Debian and RPM packages
make configuration "automatic" . I was trying to explain that even after
installation, some administrator configuration is required to make the
server usable for non-privelidged users. Either in the form of creating
and dropping databases or in giving the users rights to do it themselves.

The way I'd like to make it work for my app is to run a seperate
postmaster as the user to avoid involving the machine administrator or
interfering with other users. If a shared install can be made to work
in an equivalent way, then I would rather go with that. I'm not clear
on whether that's possible though. My current understanding is that it
is not and that my original notion is the only way for my app.




---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Chris Ochs]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

I still have to respectfully disagree. Postgresql is IMO just the wrong
software for the job, and given that there are still a number of really
important things that postgresql lacks, it should concentrate on those. I
am not against it however for technical reasons, because those things can
always be overcome. I just wouldn't want postgresql to start branching out
in different directions at this point, it makes no sense if the project
wants to keep focused and one day become comparable side by side to oracle.
IMO that should be it's main goal, and embedded functionality would be a
detour that has more chances of doing harm then good.

Chris





[color=blue][color=green]
> >
> > Frankly, I am _mighty glad_ that the developers are focussed on
> > enterprise-level applications.[/color]
>
> Me too. But I think we can get it for small-scale stuff with no impact on
> the rest. Just an additional function or 6 to make embedded developer's
> lives easier.
>
> Jon
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>[/color]


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[David Garamond]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

Chris Ochs wrote:[color=blue]
> I still have to respectfully disagree. Postgresql is IMO just the wrong
> software for the job, and given that there are still a number of really
> important things that postgresql lacks, it should concentrate on those. I
> am not against it however for technical reasons, because those things can
> always be overcome. I just wouldn't want postgresql to start branching out
> in different directions at this point, it makes no sense if the project
> wants to keep focused and one day become comparable side by side to oracle.
> IMO that should be it's main goal, and embedded functionality would be a
> detour that has more chances of doing harm then good.[/color]

I believe the basic mission of Postgres will stay the same [for a long
time]: providing a 1) reliable database; 2) with advanced; 3) and
standard compliant features.

However, venturing into win32 world _will_ generate demands like
embedded and other desktop app-oriented features since I expect that's
what many people will using Postgres for in win32 (currently people are
using IB/FB for this and not MySQL/Postgre; MySQL's embedded version is
GPL/commercial). And we all know it's all a matter of what itches the
developers the most. If enough people are bugging them about something,
they will do it... :-)

--
dave


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Chris Travers]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

Hi Rick;

I have been looking for a few years at a similar situation with my CRM
software and soon (once I have the SOAP interfaces done, I will start on a
stand-alone client. I have eventually decided on a very different structure
than you have, though the result is more or less the same.

Rather than using PostgreSQL as an embedded database manager, I have decided
that it makes more sense for my app to "cache objects" in XML documents and
then use those on trips to customers' sites. The XML documents can then be
checked and the objects re-sync'd when the app goes online again. The
cacheing would be automatic and cached objects would expire unless
explicitly saved.

Why not use XML for this sort of problem? Or berkeley DB? Is there any
reason that PostgreSQL would be better? I am not aware of any functional
replication systems which would work in this way, so I am guessing your app
will have to handle all the logic for the syncronization anyway.

Best Wishes,
Chris Travers


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Chris Travers]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

Hi Tom and others;

I agree with your reasoning insofar as it pertains to dedicating core
PostgreSQL time into developing such a library. I also agree insofar as it
pertains to the PostgreSQL core distribution.

I do think, however, that given the current demand for a serverless solution
to PostgreSQL (whether or not it is the right tool for the job), I would
suggest that those who are interested and have the necessary skills set up a
gborg project. Perhaps at some point if PostgreSQL distributions become
more commonplace, we will see it used, and this will open up new
oportunities for PostgreSQL. It should be remembered that more options in
critical areas (such as Win32) may mean more community, and hopefully in the
long run, more developers.

Best Wishes,
Chris Travers


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Nigel J. Andrews]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)


On Fri, 16 Jan 2004, Jeff Bowden wrote:
[color=blue]
> Nigel J. Andrews wrote:[color=green]
> >I don't see what the problem is. PostgreSQL is perfectly able to be installed
> >and run as any old user. Even if one is distributing via a package system, such
> >as RPM perhaps, which has problems installing as non-root user if one sees the
> >package already installed then there's no need to try to install it
> >again. Even with the package installations there's bugger all stopping any old
> >user doing an initdb -D myownplace.
> >
> >The standard postgres user on a system is only special in that it is generally
> >the user the postmaster is run as. If you have other non-priviledged users and
> >there's no need for them to share a cluster why try to make them?
> >
> >[/color]
>
> I'm sorry, maybe I didn't state my ideas clearly enough. I was
> following on to Tom Lane's suggestion that the Debian and RPM packages
> make configuration "automatic" . I was trying to explain that even after
> installation, some administrator configuration is required to make the
> server usable for non-privelidged users. Either in the form of creating
> and dropping databases or in giving the users rights to do it themselves.
>
> The way I'd like to make it work for my app is to run a seperate
> postmaster as the user to avoid involving the machine administrator or
> interfering with other users. If a shared install can be made to work
> in an equivalent way, then I would rather go with that. I'm not clear
> on whether that's possible though. My current understanding is that it
> is not and that my original notion is the only way for my app.[/color]

I think I probably didn't do the explanation clearly enough. This does depend
on what you mean by shared install. I was assuming you just wanted to manage
data independently only using the shared binaries installed from the
package. If that's not the case then obviously this isn't what you want. If
that is the case then you could run the following as any old user, provided the
environment has been set appropiately of course:

initdb -D $HOME/pgdata
sed -e 's/^#port = 5432/port = 12345/' $HOME/pgdata/postgresql.conf > /tmp/p
mv /tmp/p $HOME/pgdata/postgresql.conf
pg_ctl -D $HOME/pgdata start

then access the cluster using:

pgsql -P 12345 template1

That's it. That's access as the db superuser for that cluster. Sure if the
system admin upgrades the shared software then you could have problems.

My apologies if I've got the wrong end of things again, I've got a lot of
unread email and I keep reading things in a very haphazard order.


--
Nigel J. Andrews


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Bill Gribble]

Re: embedded/&quot;serverles s&quot; (Re: serverless postgresql)

On Fri, 2004-01-16 at 16:00, Jonathan Bartlett wrote:[color=blue]
> Linux has no real embedded database. PG would be an excellent
> embedded database.[/color]

SQLite works great for these kinds of applications, FWIW.

b.g.



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Jeff Bowden]

Re: serverless postgresql

Christopher Browne wrote:
[color=blue]
>jlb@houseofdis traction.com (Jeff Bowden) wrote:
>
>[color=green]
>>Oh yeah, that brings me to another question. I was looking at the
>>postmaster command-line switches and I couldn't find any that would
>>allow me to point it at an arbitrary config file but then I had a
>>look around and it seems that the .conf files are already used by
>>the various startup scripts. Does postmaster itself ever read the
>>.conf files or is it controlled strictly by switches?
>>
>>[/color]
>
>All of the .conf files are in one directory, and that directory is
>controlled by either the value of environment variable PGDATA or the
>"-D" command parameter.
>
>It seems not-overly-valuable to have the .conf files be able to be
>specified in random other locations.
>
>Is there some particular reason you have in mind why you would want to
>_ignore_ the configuration in $HOME/DBDIR and instead use
>configuratio n in some other random location? I would think that
>collecting the config into one directory, as is done right now, is a
>_good_ thing.
>
>[/color]


If the existing user configuration could be reliably determined to be
sane and have sufficient permissions or could be made so, that would be
fine.

I am writing an app for users who are not necessarily knowledgeable
about databases. If they don't have an existing useable postgres
configuration, I would like for my app to be able to create one without
forcing the user to have to be root or learn about postgres
configuration. The data for this app should remain private to the user
who created it and there is no need for concurrent access.




---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)