Database "xxxx", OID yyyyy, has disappeared from pg_database

I receive the following error when trying to connect to ALL postgres
databases on my system.

Database 'xxxx', OID yyyyy, has disappeared from pg_database

The various archives have other users that had this problem and the
solution is to vacuum the pg_database, however;

bash$ vacuumdb pg_database
psql: FATAL 1: Database "pg_database" does not exist in the system catalog.
vacuumdb: vacuum failed

I also cannot connect to any database precluding me from running vacuum
pg_database from the psql command line. I cannot create a database and
attempt this as,

bash$ createdb tester
psql: FATAL 1: Database 'template1', OID 17216, has disappeared from
pg_database
createdb: database creation failed

Any suggestions?

RedHat
Linux Kernel 2.2.14-5
PostgreSQL 7.0.0 - yeah, I know I should have upgraded. SOL?

Thanks in advance.

--
Michael Glenn
http://www.mglenn.com
416.544.9904




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

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Michael Glenn writes:
> I receive the following error when trying to connect to ALL postgres
> databases on my system.

> Database 'xxxx', OID yyyyy, has disappeared from pg_database

Hmm. The only thing I can think of that might cause that for all DBs
at once is transaction ID wraparound. How large is your pg_log file
($PGDATA/pg_log, in 7.0)? If it's 1GB then that's what happened to you.

> The various archives have other users that had this problem and the
> solution is to vacuum the pg_database, however;

> bash$ vacuumdb pg_database
> psql: FATAL 1: Database "pg_database" does not exist in the system catalog.

There are problems that can cause this error message for individual
databases, and the solution is to connect to another database and vacuum
the pg_database table (not the pg_database database; there isn't one).
But that won't help if you can't get into anything to begin with.

> PostgreSQL 7.0.0 - yeah, I know I should have upgraded. SOL?

Could be :-(. If your pg_log is not 1GB in size then you didn't have a
wraparound and maybe we can still help you. Otherwise, I hope you made
a backup recently.

regards, tom lane

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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Tom,

The log is only 98K.
-rw-rw-r-- 1 postgres postgres 98304 Apr 24 15:00 pg_log

So it's not a wraparound problem.

Recent backups unfortunately are not available for all the databases.
Any suggestions?

Thanks

Tom Lane wrote:

>Michael Glenn writes:
>
>
>>> I receive the following error when trying to connect to ALL postgres
>>> databases on my system.
>>
>>
>
>
>
>>> Database 'xxxx', OID yyyyy, has disappeared from pg_database
>>
>>
>
>Hmm. The only thing I can think of that might cause that for all DBs
>at once is transaction ID wraparound. How large is your pg_log file
>($PGDATA/pg_log, in 7.0)? If it's 1GB then that's what happened to you.
>
>
>
>>> The various archives have other users that had this problem and the
>>> solution is to vacuum the pg_database, however;
>>
>>
>
>
>
>>> bash$ vacuumdb pg_database
>>> psql: FATAL 1: Database "pg_database" does not exist in the system catalog.
>>
>>
>
>There are problems that can cause this error message for individual
>databases, and the solution is to connect to another database and vacuum
>the pg_database table (not the pg_database database; there isn't one).
>But that won't help if you can't get into anything to begin with.
>
>
>
>>> PostgreSQL 7.0.0 - yeah, I know I should have upgraded. SOL?
>>
>>
>
>Could be :-(. If your pg_log is not 1GB in size then you didn't have a
>wraparound and maybe we can still help you. Otherwise, I hope you made
>a backup recently.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html
>
>
>
>

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

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Michael Glenn writes:
> The log is only 98K.

Okay, then you haven't executed four billion transactions...

Probably the next thing is to look at pg_database and try to understand
why all the rows are showing as dead. There are a couple of tools
around that can dump out the contents of tuple headers. I'd suggest
pg_filedump (http://sources.redhat.com/rhdb/tools.html), but it is
intended for 7.1/7.2 and you'd need to do a little surgery to make it
work on 7.0 files. (I think ripping out the code that expects an LSN
field to be present in the page header would be enough.) If you check
the PG list archives you will find references to one or two older
programs in the same vein; there might still be something available
that will work on 7.0 files without modification.

regards, tom lane

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

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

I downloaded pg_dumpfile (thank you) then eventually found out I need to
download, configure, and point to 7.2.1 source to compile, which makes
sense now.

I compiled and attempted a dump with the references and without the
references to LSN from the function FormatHeader. In both cases I
received the dump output below indicating "Invalid header
information.". Now, is each block header corrupted OR is the dump
utility not able to read older pg_database files? If switched both
blockOptions and BLOCK_FORMAT to true (1 and 0x00000001 respectively) to
print the raw data anyway. The first part is below. I have no idea how
to interpret the information, perhaps somone else does. If you would
like the entire dump please let me know.

Thanks.

************************************************************ *****
* PostgreSQL File/Block Formatted Dump Utility
*
* File: /var/lib/pgsql/pg_database
* Options used: None
*
* Dump created on: Thu Apr 25 13:37:24 2002
************************************************************ *****

Block 0 ******************************************************

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Michael Glenn writes:
> I downloaded pg_dumpfile (thank you) then eventually found out I need to
> download, configure, and point to 7.2.1 source to compile, which makes
> sense now.
> I compiled and attempted a dump with the references and without the
> references to LSN from the function FormatHeader. In both cases I
> received the dump output below indicating "Invalid header
> information.". Now, is each block header corrupted OR is the dump
> utility not able to read older pg_database files?

If you compiled the pg_dumpfile sources using 7.2 header files, then
they'd be using the 7.2 page header struct, which is the wrong thing.
You need to use the 7.0 version of the PageHeaderData struct
(see src/include/storage/bufpage.h).

My inclination would be to try to compile pg_dumpfile against the 7.0
headers not 7.2. You might have to rip out references to pg_control and
CRC checking to make that work, but there are no CRCs in 7.0 files
anyway so you won't lose any functionality. Once it does compile you
could be pretty sure that it would actually work.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Hi Tom,

It's been quite a while since I've actually programmed in C but it
appears to have worked. I commented out the imports that referred to
header files that don't exist in 7.0 and commented out all code
references. I may have made changes that were too broad and commented
out functions to print critical data, but below is the dump. Let me know
if it should have more detail. It seems a bit short and not very verbose.

Excuse the lengthy dump, there are 32 databases that I've lost. 38 items
are listed in the file dump. I'm not sure what the relationship is there.

Thanks

# ./pg_filedump -fa /var/lib/pgsql/pg_database

************************************************************ *****
* PostgreSQL File/Block Formatted Dump Utility
*
* File: /var/lib/pgsql/pg_database
* Options used: -fa
*
* Dump created on: Thu Apr 25 15:15:38 2002
************************************************************ *****

Block 0 ******************************************************

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Michael Glenn writes:
> It's been quite a while since I've actually programmed in C but it
> appears to have worked.

Looks reasonable. Could I trouble you for the output with switches -f -i
though? It's the item details we need.

regards, tom lane

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

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Tom Lane wrote:

>Michael Glenn writes:
>
>
>>It's been quite a while since I've actually programmed in C but it
>>appears to have worked.
>>
>>
>
>Looks reasonable. Could I trouble you for the output with switches -f -i
>though? It's the item details we need.
>
>
Trouble me? I'm grateful your looking at at. Eternally grateful if you
can solve it.

Thanks again.

# ./pg_filedump -f -i /var/lib/pgsql/pg_database

************************************************************ *****
* PostgreSQL File/Block Formatted Dump Utility
*
* File: /var/lib/pgsql/pg_database
* Options used: -f -i
*
* Dump created on: Thu Apr 25 16:07:22 2002
************************************************************ *****

Block 0 ******************************************************

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Michael Glenn writes:
> [ pg_filedump output ]

Looking at this, I'm kind of wondering whether you didn't have a
transaction ID wrap after all. You've got a number of rows here that
appear to have been touched by quite large transaction numbers,
for instance:

> Item 8 -- Length: 80 Offset: 7508 (0x1d54) Flags: USED
> OID: 109529120 CID: min(0) max(0) XID: min(24597178) max(0)
^^^^^^^^

> Item 9 -- Length: 89 Offset: 6896 (0x1af0) Flags: USED
> OID: 133213920 CID: min(0) max(0) XID: min(34149469) max(0)
^^^^^^^^

and they're marked committed too, which means that some other
transaction agreed that that XID had gotten committed. You sure
that there's not anything you've forgotten to tell us about past
sins with pg_log? There's no way that XID 34149469 could have
been marked committed unless pg_log were at least 8.5 megabytes.

What I think you might be able to do as a band-aid solution is to force
up the current-XID counter, which lives in, hmm, $PGDATA/pg_variable in
7.0.*. Without the former contents of pg_log this will not give you a
completely accurate reconstruction of your data, but it should be good
at least back to the last vacuum, which is a lot better than nothing
(assuming you were more religious about vacuuming than backups ;-)).

What do you get from "od -x pg_variable"?

regards, tom lane

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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

I haven't had any issues with pg_log that I know of. Until this incident
I didn't even know what it did. I did lose a few databases a little over
a year ago but didn't persue it a agressively as this situation because
it wasn't as dire.

The scarry thing is I almost never use vacuum becuase I just plain
forgot a long time ago about it. I didn't realise that it could lead to
such corruption and was under the impression that it was more for
performance than anything else.

I have an old database that was very high in transactions but has been
dormant for over a year now. I thought that 98K seemed way too small for
a transaction log file. Perhaps it was damaged.

Well, it will probably be a few months worth of restoration if there
isn't any other solution, but I guess it serves me right for not reading
the docs more closely. What is the procedure for bumping up the
current-XID counter in pg_variable? Is it theoretically possible to
restore a database from all of it's related files.

Thanks

Also, are the source code modifications for pg_filedump useful to anyone?

Tom Lane wrote:

>Michael Glenn writes:
>
>
>>[ pg_filedump output ]
>>
>>
>
>Looking at this, I'm kind of wondering whether you didn't have a
>transaction ID wrap after all. You've got a number of rows here that
>appear to have been touched by quite large transaction numbers,
>for instance:
>
>
>
>> Item 8 -- Length: 80 Offset: 7508 (0x1d54) Flags: USED
>> OID: 109529120 CID: min(0) max(0) XID: min(24597178) max(0)
>>
>>
> ^^^^^^^^
>
>
>
>> Item 9 -- Length: 89 Offset: 6896 (0x1af0) Flags: USED
>> OID: 133213920 CID: min(0) max(0) XID: min(34149469) max(0)
>>
>>
> ^^^^^^^^
>
>and they're marked committed too, which means that some other
>transaction agreed that that XID had gotten committed. You sure
>that there's not anything you've forgotten to tell us about past
>sins with pg_log? There's no way that XID 34149469 could have
>been marked committed unless pg_log were at least 8.5 megabytes.
>
>What I think you might be able to do as a band-aid solution is to force
>up the current-XID counter, which lives in, hmm, $PGDATA/pg_variable in
>7.0.*. Without the former contents of pg_log this will not give you a
>completely accurate reconstruction of your data, but it should be good
>at least back to the last vacuum, which is a lot better than nothing
>(assuming you were more religious about vacuuming than backups ;-)).
>
>What do you get from "od -x pg_variable"?
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html
>
>
>
>


--
Michael Glenn
http://www.mglenn.com
416.544.9904

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 6.5.8 for non-commercial use

mQGiBDi1W3gRBADgkh1Qvms9Qz1zpStGDdSs36K0KGX8mhuXMn21C6cE9DQ4 V6d7
S8yQo+fFwos0lV+iIy0vWomq2LI1tiniV46v8cn7OyM0QI2c4IVgNn7h5hwq 8Yue
RmdSk9Nc1B8FJjWXZKkAxrZ9UtBRpl1USUnh8NnN0uQ+4pB9QoRK77OFnQCg /8hh
KqMCe7y3FF5jHtSK/pHT308D/ifQNxg97Sp1BQxrOGA07Jj4MbWwZDUZH3h0 loSJ
TmqEZU8dykPFu3+MCgiUP6en2b5Qk0r/ayHiS7cOwCMUnsmI2Ys4TC36w2CX IhUh
yt8xWqR8uGJDw3OsRr4bOgOm2rhcBtsCx4CSCZ80ysWcDT2KERg4l9kgP1po I27x
l38MA/9cJiLDhT84+ktmTpwkzDIbBWqBEa9avd28fMLjziJMw6Ak2a5B3lON DBWD
ymd0UHjuuHm3aXDA2xAiZtQRvYpEFKsIOoL6+eMjkDC2VfEjoYOACqSlPxO5 lxb4
oINcoxBWHjPMWIjS29LydC+OyVZW0RfCqLyANEZFqZT0lkJPI7QfTWljaGFl bCBH
bGVubiA8bWlrZUBtZ2xlbm4uY29tPokATgQQEQIADgUCOLVbeAQLAwIBAhkB AAoJ
EG/6eNodQfh3VAQAoOiLvTGsq59pmWUh9XdjjU4SS3aUAJ4ywgkjUkmUJ5Im Thp2
3k1rEax3i7kCDQQ4tVt4EAgA9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlL OCDa
AadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N 286Z
4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/ RgBY
K+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2O u1WM
uF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqV DNmW
n6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuquiXsNV6TILOwACAgf9H57D7zhr /7t6
IxbxBMCFy4EHkD5awkfpxSjv0kLV4AQsXfdk1LsEJLFp8WLquo2ftPpSsMR2 vYMa
qtyK6FB9I+wq8h76m2RsHoAYVeXYpxckbXtNstz/9qENctdYn2f190v46FCx un3c
IghoP4rBnJQNOQIcSQWSEWyOfFjCSlEv/7RSS3cL19r7OE0m7yJprBvAmav+ TuHM
UmG4Etdi89VEiMYXeFV08CmT12xt+Lel7/YpDlcFBQEjy810nb19w2HCOxh/ JMEO
C5gXXKMMgtWUTfY/gw9oZOXSy5EffcLjk4jJ2J3FJSwqhOQgBKi0l8I4r1QM mOdE
9WPpnDrHrYkARgQYEQIABgUCOLVbeAAKCRBv+njaHUH4d547AJ9ze+4zXlsv /NdX
GhsLTWp+BOQEvACgqEN5l2RiBVEYJDx1ktz9cSuvcrI=
=KXHB
-----END PGP PUBLIC KEY BLOCK-----




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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

Michael Glenn writes:
> Well, it will probably be a few months worth of restoration if there
> isn't any other solution, but I guess it serves me right for not reading
> the docs more closely. What is the procedure for bumping up the
> current-XID counter in pg_variable? Is it theoretically possible to
> restore a database from all of it's related files.

If you haven't vacuumed in a long time then it could be pretty messy;
you will have a problem with not being able to tell aborted transactions
from committed ones. If you didn't abort transactions very often then
maybe the headaches won't be too bad, but otherwise ...

What I would do at this point is:

1. Make a tarball copy of your entire $PGDATA tree, if at all possible.
This will let you start over when you want to.

2. Use a binary-file editor to insert some very large value (4 billion
minus a few hundred, perhaps) into nextXid, which is the second 4 bytes
of the pg_variable file. (You might want to take note of what's there
now, too.)

3. Replace pg_log with a file containing 1Gb worth of 0xAA bytes. This
will make it look like all your transactions committed.

4. Start postmaster --- it should start happily at this point.

5. Without doing anything else, pg_dumpall. You have a few hundred
transactions before everything goes to hell again, so don't waste 'em.
(You don't want to give yourself too much headroom here, because you
are certainly losing the effects of every transaction after the nextXid
you chose.)

6. initdb a fresh installation (might as well move up to 7.2.1 here...),
try to restore pg_dumpall script into it, settle down to a lot of
cross-checking to try to validate data.

The reason you will have consistency problems is that some aborted
transactions will be taken as committed --- maybe in only some of their
effects, not all. As a rule of thumb, any tuple that was read by
another transaction before the wrap happened will be marked with
the correct commit state. Anything that hadn't been examined will
be taken to be committed, which might be wrong. So the newer and
more seldom-examined the update, the riskier it will be. It's very
likely the pgdump script will not even restore (due to unique-key
violations) until it's hand-edited, so you might want to dump schema
and data separately to ease editing.

It might be useful to try this procedure with a few different nextXid
selections --- that will give you snapshots further and further back
in the past, with hopefully correspondingly fewer inconsistencies.
In any case you're in for a lot of no-fun. Sorry the news is not
better.

regards, tom lane

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

http://www.postgresql.org/users-lounge/docs/faq.html

Re: Database "xxxx", OID yyyyy, has disappeared from pg_database

It worked!

This is a few days after success but I wanted to test out the databases
before I declared victory.

Many thanks Tom. This incident has spurred me to vacuum more often,
backup every day, and RTFM.

See "The Postgres Incident" http://www.mglenn.com/archives/2002/05/01/
for a synopsis.

Thanks again, I'm in your debt.

Tom Lane wrote:

>Michael Glenn writes:
>
>
>>Well, it will probably be a few months worth of restoration if there
>>isn't any other solution, but I guess it serves me right for not reading
>>the docs more closely. What is the procedure for bumping up the
>>current-XID counter in pg_variable? Is it theoretically possible to
>>restore a database from all of it's related files.
>>
>>
>
>If you haven't vacuumed in a long time then it could be pretty messy;
>you will have a problem with not being able to tell aborted transactions
>from committed ones. If you didn't abort transactions very often then
>maybe the headaches won't be too bad, but otherwise ...
>
>What I would do at this point is:
>
>1. Make a tarball copy of your entire $PGDATA tree, if at all possible.
>This will let you start over when you want to.
>
>2. Use a binary-file editor to insert some very large value (4 billion
>minus a few hundred, perhaps) into nextXid, which is the second 4 bytes
>of the pg_variable file. (You might want to take note of what's there
>now, too.)
>
>3. Replace pg_log with a file containing 1Gb worth of 0xAA bytes. This
>will make it look like all your transactions committed.
>
>4. Start postmaster --- it should start happily at this point.
>
>5. Without doing anything else, pg_dumpall. You have a few hundred
>transactions before everything goes to hell again, so don't waste 'em.
>(You don't want to give yourself too much headroom here, because you
>are certainly losing the effects of every transaction after the nextXid
>you chose.)
>
>6. initdb a fresh installation (might as well move up to 7.2.1 here...),
>try to restore pg_dumpall script into it, settle down to a lot of
>cross-checking to try to validate data.
>
>The reason you will have consistency problems is that some aborted
>transactions will be taken as committed --- maybe in only some of their
>effects, not all. As a rule of thumb, any tuple that was read by
>another transaction before the wrap happened will be marked with
>the correct commit state. Anything that hadn't been examined will
>be taken to be committed, which might be wrong. So the newer and
>more seldom-examined the update, the riskier it will be. It's very
>likely the pgdump script will not even restore (due to unique-key
>violations) until it's hand-edited, so you might want to dump schema
>and data separately to ease editing.
>
>It might be useful to try this procedure with a few different nextXid
>selections --- that will give you snapshots further and further back
>in the past, with hopefully correspondingly fewer inconsistencies.
>In any case you're in for a lot of no-fun. Sorry the news is not
>better.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html
>
>
>
>


--
Michael Glenn
http://www.mglenn.com
416.544.9904

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 6.5.8 for non-commercial use

mQGiBDi1W3gRBADgkh1Qvms9Qz1zpStGDdSs36K0KGX8mhuXMn21C6cE9DQ4 V6d7
S8yQo+fFwos0lV+iIy0vWomq2LI1tiniV46v8cn7OyM0QI2c4IVgNn7h5hwq 8Yue
RmdSk9Nc1B8FJjWXZKkAxrZ9UtBRpl1USUnh8NnN0uQ+4pB9QoRK77OFnQCg /8hh
KqMCe7y3FF5jHtSK/pHT308D/ifQNxg97Sp1BQxrOGA07Jj4MbWwZDUZH3h0 loSJ
TmqEZU8dykPFu3+MCgiUP6en2b5Qk0r/ayHiS7cOwCMUnsmI2Ys4TC36w2CX IhUh
yt8xWqR8uGJDw3OsRr4bOgOm2rhcBtsCx4CSCZ80ysWcDT2KERg4l9kgP1po I27x
l38MA/9cJiLDhT84+ktmTpwkzDIbBWqBEa9avd28fMLjziJMw6Ak2a5B3lON DBWD
ymd0UHjuuHm3aXDA2xAiZtQRvYpEFKsIOoL6+eMjkDC2VfEjoYOACqSlPxO5 lxb4
oINcoxBWHjPMWIjS29LydC+OyVZW0RfCqLyANEZFqZT0lkJPI7QfTWljaGFl bCBH
bGVubiA8bWlrZUBtZ2xlbm4uY29tPokATgQQEQIADgUCOLVbeAQLAwIBAhkB AAoJ
EG/6eNodQfh3VAQAoOiLvTGsq59pmWUh9XdjjU4SS3aUAJ4ywgkjUkmUJ5Im Thp2
3k1rEax3i7kCDQQ4tVt4EAgA9kJXtwh/CBdyorrWqULzBej5UxE5T7bxbrlL OCDa
AadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N 286Z
4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/ RgBY
K+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2O u1WM
uF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaGxAMZyAcpesqV DNmW
n6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuquiXsNV6TILOwACAgf9H57D7zhr /7t6
IxbxBMCFy4EHkD5awkfpxSjv0kLV4AQsXfdk1LsEJLFp8WLquo2ftPpSsMR2 vYMa
qtyK6FB9I+wq8h76m2RsHoAYVeXYpxckbXtNstz/9qENctdYn2f190v46FCx un3c
IghoP4rBnJQNOQIcSQWSEWyOfFjCSlEv/7RSS3cL19r7OE0m7yJprBvAmav+ TuHM
UmG4Etdi89VEiMYXeFV08CmT12xt+Lel7/YpDlcFBQEjy810nb19w2HCOxh/ JMEO
C5gXXKMMgtWUTfY/gw9oZOXSy5EffcLjk4jJ2J3FJSwqhOQgBKi0l8I4r1QM mOdE
9WPpnDrHrYkARgQYEQIABgUCOLVbeAAKCRBv+njaHUH4d547AJ9ze+4zXlsv /NdX
GhsLTWp+BOQEvACgqEN5l2RiBVEYJDx1ktz9cSuvcrI=
=KXHB
-----END PGP PUBLIC KEY BLOCK-----




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