Josh Berkus writes:
> On 03/19/2014 10:37 AM, Alvaro Herrera wrote:
>> I wonder about suggesting other versions of ALTER TABLE that can do
>> heap rewrites.
> I don't want to recommend any version of ALTER TABLE until someone
> actually tests it on a corrupted database.
A test would be a good id
On 03/19/2014 10:37 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Josh Berkus writes:
>>> On 03/17/2014 05:49 PM, Josh Berkus wrote:
https://wiki.postgresql.org/wiki/20140320UpdateIssues
>>
>>> Anyone? We're going public with this in 36 hours, so I'd love for it to
>>> actually be correct.
Tom Lane wrote:
> Josh Berkus writes:
> > On 03/17/2014 05:49 PM, Josh Berkus wrote:
> >> https://wiki.postgresql.org/wiki/20140320UpdateIssues
>
> > Anyone? We're going public with this in 36 hours, so I'd love for it to
> > actually be correct.
>
> I did a bit more hacking on this page. Coul
Josh Berkus writes:
> On 03/17/2014 05:49 PM, Josh Berkus wrote:
>> https://wiki.postgresql.org/wiki/20140320UpdateIssues
> Anyone? We're going public with this in 36 hours, so I'd love for it to
> actually be correct.
I did a bit more hacking on this page. Could use another look from Alvaro
a
On 03/18/2014 04:39 PM, Andres Freund wrote:
Mail that's CC/TOed to me onlist, is automatically marked as read by a
sieve script so I don't have to mark it as read twice. It seems
something went wrong there for a couple of messages...
Why not just turn on eliminatecc on the majordomo server
On 2014-03-18 17:34:34 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2014-03-18 16:19:01 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2014-03-18 19:28:53 +, Greg Stark wrote:
> > > >> It would be nice to be able to tell people that if they vacuum, then
> > > >> re
Andres Freund wrote:
> On 2014-03-18 16:19:01 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2014-03-18 19:28:53 +, Greg Stark wrote:
> > >> It would be nice to be able to tell people that if they vacuum, then
> > >> reindex and check all their foreign key constraints then they shou
On 2014-03-18 16:19:01 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-18 19:28:53 +, Greg Stark wrote:
> >> It would be nice to be able to tell people that if they vacuum, then
> >> reindex and check all their foreign key constraints then they should
> >> be ok.
>
> > I don't t
Andres Freund writes:
> On 2014-03-18 19:28:53 +, Greg Stark wrote:
>> It would be nice to be able to tell people that if they vacuum, then
>> reindex and check all their foreign key constraints then they should
>> be ok.
> I don't think so:
> http://archives.postgresql.org/message-id/2014031
On 03/18/2014 12:55 PM, Andres Freund wrote:
> On 2014-03-18 12:52:49 -0700, Josh Berkus wrote:
>> On 03/18/2014 12:35 PM, Andres Freund wrote:
>>> I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE
>>> old_type USING (col); is the only real thing to do.
>>
>> Then why wouldn't VA
On 2014-03-18 12:52:49 -0700, Josh Berkus wrote:
> On 03/18/2014 12:35 PM, Andres Freund wrote:
> > I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE
> > old_type USING (col); is the only real thing to do.
>
> Then why wouldn't VACUUM FULL work?
Please read the referenced messa
On 03/18/2014 12:35 PM, Andres Freund wrote:
> I still think a rewriting noop ALTER TABLE ... ALTER COLUMN col TYPE
> old_type USING (col); is the only real thing to do.
Then why wouldn't VACUUM FULL work?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers m
On 2014-03-18 19:28:53 +, Greg Stark wrote:
> It would be nice to be able to tell people that if they vacuum, then
> reindex and check all their foreign key constraints then they should
> be ok.
I don't think so:
http://archives.postgresql.org/message-id/20140317233919.GS16438%40awork2.anaraze
On Tue, Mar 18, 2014 at 7:05 PM, Greg Stark wrote:
> I'll do a first pass now.
I fixed the "Causes" section. I haven't touched the other sections
which are pretty reasonable. It would be nice to have more suggestions
for what people should do other than dump/restore.
It would be nice to be able
On Tue, Mar 18, 2014 at 6:41 PM, Josh Berkus wrote:
>
> Anyone? We're going public with this in 36 hours, so I'd love for it to
> actually be correct.
I'll do a first pass now.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On 03/17/2014 05:49 PM, Josh Berkus wrote:
> All,
>
> https://wiki.postgresql.org/wiki/20140320UpdateIssues
>
> I'm sure my explanation of the data corruption issue is not correct, so
> please fix it. Thanks!
>
Anyone? We're going public with this in 36 hours, so I'd love for it to
actually b
Josh Berkus wrote
> All,
>
> https://wiki.postgresql.org/wiki/20140320UpdateIssues
>
> I'm sure my explanation of the data corruption issue is not correct, so
> please fix it. Thanks!
I presume that because there is no way the master could have sent bad table
data to the replication slaves that
I sent a post to -general with a much more detailed brain dump of my current
understanding on this topic. The main point I'm addressing here is how to
recover from this problem.
Since a symptom of the problem is that pg_dump/restore can fail saying that
(in some instances) the only viable restore
18 matches
Mail list logo
