| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Cc: | "Dave Page" <dpage(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Stefan Schwarzer" <stefan(dot)schwarzer(at)grid(dot)unep(dot)ch>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org> |
| Subject: | Re: Forgot to dump old data before re-installing machine |
| Date: | 2008-01-18 16:37:32 |
| Message-ID: | 200801181737.33007.peter_e@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-patches |
Am Freitag, 18. Januar 2008 schrieb Dave Page:
> It got figured out when someone who knew what they were looking for
> peeked at the byte ordering in a file which for all we knew at the
> time might have been damaged anyway
What might be better is if we had an explicit endianness mark in pg_control
rather than relying on users discovering endianness problems by seemingly
corrupted version numbers.
> For just about zero cost we could drop something like:
>
> --------
> Architecture: Darwin snake 8.11.1 Darwin Kernel Version 8.11.1: Wed
> Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386
I think we should address the problem were it happens. Adding this output
will increase the amount of information available for causing confusion,
while it would probably still require expert knowledge to read an endianness
issue out of that.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan de Visser | 2008-01-18 16:44:35 | transactionid lock type? |
| Previous Message | Peter Wilson | 2008-01-18 16:34:07 | Re: Replication Using Triggers |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2008-01-18 16:47:39 | Re: Forgot to dump old data before re-installing machine |
| Previous Message | Dave Page | 2008-01-18 16:31:15 | Re: Forgot to dump old data before re-installing machine |