| From: | Bosco Rama <postgres(at)boscorama(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Large object corruption during 'piped' pg_restore |
| Date: | 2011-01-21 17:44:21 |
| Message-ID: | 4D39C5F5.1090609@boscorama.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Tom Lane wrote:
>
> So I'm not sure whether to fix it, or leave it as a known failure case
> in old branches. Comments?
I understand the reluctance to fool with stable code. I have zero insight
into your installed versions distribution and backward compatibility needs
so any comment I may have here is purely selfish.
As an end user there is one area of the DB that I want to work correctly
100% of the time and that is the dump/restore tool(s). If it's not going
to work under certain circumstances it should at least tell me so and
fail. I don't think having the tool appear to work while corrupting the
data (even if documented as doing so) is a viable method of operation.
Just my $0.02
Bosco.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-01-21 17:54:53 | Re: [HACKERS] Large object corruption during 'piped' pg_restore |
| Previous Message | tuanhoanganh | 2011-01-21 17:41:26 | Re: PostgreSQL 9.0.1 PITR can not copy WAL file |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2011-01-21 17:48:25 | pgsql: Move test_fsync to /contrib. |
| Previous Message | Chris Browne | 2011-01-21 17:43:10 | Re: Review: compact fsync request queue on overflow |