Thanks! Pushed. Marking the open item as closed too.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Apr 26, 2019 at 11:55:17AM +0900, Michael Paquier wrote:
On Thu, Apr 25, 2019 at 12:54:06PM -0700, Andres Freund wrote:
I think that'd make sense. The rest of the RMT probably isn't awake
however, so I think it'd be good to give them 24h to object.
It would be nice to clean all that no
On Thu, Apr 25, 2019 at 12:54:06PM -0700, Andres Freund wrote:
> I think that'd make sense. The rest of the RMT probably isn't awake
> however, so I think it'd be good to give them 24h to object.
It would be nice to clean all that now, so +1 from me to apply the
patch.
--
Michael
signature.asc
D
Hi,
On 2019-04-25 15:05:47 -0400, Alvaro Herrera wrote:
> On 2019-Mar-10, Dmitry Dolgov wrote:
>
> > Then I guess we need to add the attached patch on top of a pg_dump support
> > for
> > table am. It contains changes to use NULL as a default value for owner /
> > defn /
> > dropStmt (exactly w
On 2019-Mar-10, Dmitry Dolgov wrote:
> Then I guess we need to add the attached patch on top of a pg_dump support for
> table am. It contains changes to use NULL as a default value for owner / defn
> /
> dropStmt (exactly what we've changed back in 19455c9f56), and doesn't crash,
> since K_VERS i
> On Mon, Mar 4, 2019 at 7:15 PM Andres Freund wrote:
>
> The pluggable storage patchset contains exactly that... I've attached
> the precursor patch (CREATE ACCESS METHOD ... TYPE TABLE), and the patch
> for pg_dump support. They need a bit more cleanup, but it might be
> useful information for t
Hi,
On 2019-03-04 13:25:40 -0500, Tom Lane wrote:
> Andres Freund writes:
> > One thing I want to bring up here rather than in the pluggable storage
> > thread is that currently the pg_dump support for access methods deals
> > with table access methods in a manner similar to the way we deal with
Andres Freund writes:
> One thing I want to bring up here rather than in the pluggable storage
> thread is that currently the pg_dump support for access methods deals
> with table access methods in a manner similar to the way we deal with
> tablespaces. Instead of specifying the AM on every table
Hi,
On 2019-02-27 09:32:17 -0300, Alvaro Herrera wrote:
> On 2019-Feb-27, Dmitry Dolgov wrote:
> > But I hope there are no objections if I'll then submit the original
> > changes with more consistent null handling separately to make decision
> > about them more consciously.
>
> I think we should
> On Thu, Feb 28, 2019 at 9:24 PM Alvaro Herrera
> wrote:
>
> Pushed, thanks. I added the reminder comment I mentioned.
Thank you, sorry for troubles.
On 2019-Feb-27, Dmitry Dolgov wrote:
> > On Wed, Feb 27, 2019 at 1:32 PM Alvaro Herrera
> > wrote:
> >
> > > > I think it would be better to just put back the .defn = "" (etc) to the
> > > > ArchiveEntry calls.
> > >
> > > Then we should do this not only for defn, but for owner and dropStmt too.
On Wed, Feb 27, 2019 at 12:02:43PM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
>> I think we should save such a patch for whenever we next update the
>> archive version number, which could take a couple of years given past
>> history. I'm inclined to add a comment near K_VERS_SELF to remind
>
> On Wed, Feb 27, 2019 at 1:32 PM Alvaro Herrera
> wrote:
>
> > > I think it would be better to just put back the .defn = "" (etc) to the
> > > ArchiveEntry calls.
> >
> > Then we should do this not only for defn, but for owner and dropStmt too.
>
> Yeah, absolutely.
Done, please find the attach
Alvaro Herrera writes:
> On 2019-Feb-27, Dmitry Dolgov wrote:
>> But I hope there are no objections if I'll then submit the original
>> changes with more consistent null handling separately to make decision
>> about them more consciously.
> I think we should save such a patch for whenever we next
On 2019-Feb-27, Dmitry Dolgov wrote:
> > On Tue, Feb 26, 2019 at 11:53 PM Alvaro Herrera
> > wrote:
> >
> > I think it would be better to just put back the .defn = "" (etc) to the
> > ArchiveEntry calls.
>
> Then we should do this not only for defn, but for owner and dropStmt too.
Yeah, absolu
> On Tue, Feb 26, 2019 at 11:53 PM Alvaro Herrera
> wrote:
>
> On 2019-Feb-26, Dmitry Dolgov wrote:
>
> > Yes, it should be rather simple, we can e.g. return to the old less
> > consistent
> > NULL handling approach something (like in the attached patch), or replace a
> > NULL
> > value with an
Alvaro Herrera writes:
> I think it would be better to just put back the .defn = "" (etc) to the
> ArchiveEntry calls.
Yeah, that was what I was imagining --- just make the ArchiveEntry calls
act exactly like they did before in terms of what gets filled into the
TOC fields. This episode is a fin
On 2019-Feb-26, Dmitry Dolgov wrote:
> > On Tue, Feb 26, 2019 at 6:38 AM Michael Paquier wrote:
> >
> > Works for me. With a quick read of the code, it seems to me that it
> > is possible to keep compatibility while keeping the simplifications
> > around ArchiveEntry()'s refactoring.
>
> Yes, i
Alvaro Herrera writes:
> Hmm, shouldn't we modify sanitize_line so that it returns strdup(hyphen)
> when input is empty and want_hyphen, too?
If this patch is touching the behavior of functions like that, then
it's going in the wrong direction; the need for any such change suggests
strongly that
On 2019-Feb-26, Dmitry Dolgov wrote:
> Yes, it should be rather simple, we can e.g. return to the old less consistent
> NULL handling approach something (like in the attached patch), or replace a
> NULL
> value with an empty string in WriteToc. Give me a moment, I'll check it out.
> At
> the sam
On 2019-Feb-26, Michael Paquier wrote:
> On Tue, Feb 26, 2019 at 12:16:35AM -0500, Tom Lane wrote:
> > Well, if we didn't want to fix this, a reasonable way to go about
> > it would be to bump the archive version number in pg_dump output,
> > so that old versions would issue a useful complaint ins
> On Tue, Feb 26, 2019 at 9:13 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Feb 26, 2019 at 6:38 AM Michael Paquier wrote:
> >
> > Works for me. With a quick read of the code, it seems to me that it
> > is possible to keep compatibility while keeping the simplifications
> > aroun
> On Tue, Feb 26, 2019 at 6:38 AM Michael Paquier wrote:
>
> Works for me. With a quick read of the code, it seems to me that it
> is possible to keep compatibility while keeping the simplifications
> around ArchiveEntry()'s refactoring.
Yes, it should be rather simple, we can e.g. return to the
On Tue, Feb 26, 2019 at 12:16:35AM -0500, Tom Lane wrote:
> Well, if we didn't want to fix this, a reasonable way to go about
> it would be to bump the archive version number in pg_dump output,
> so that old versions would issue a useful complaint instead of crashing.
> However, I repeat that this
Michael Paquier writes:
> On Mon, Feb 25, 2019 at 11:20:14AM -0500, Tom Lane wrote:
>> It appears to me that f831d4acc required a good deal more adult
>> supervision than it actually got. That was alleged to be a small
>> notational refactoring, not a redefinition of what gets put into
>> dump fi
On Mon, Feb 25, 2019 at 11:20:14AM -0500, Tom Lane wrote:
> It appears to me that f831d4acc required a good deal more adult
> supervision than it actually got. That was alleged to be a small
> notational refactoring, not a redefinition of what gets put into
> dump files.
How much consistent do we
On Mon, Feb 25, 2019 at 08:45:39AM +0100, hubert depesz lubaczewski wrote:
> Hi,
> I did upgrade of my test pg. Part of this is pg_dump -Fd of each
> database, then upgrade binaries, then initdb, and pg_restore.
Sorry, please disregard this problem.
Error was sitting on a chair.
Best regards,
d
Justin Pryzby writes:
> What's crashing for me is restoring the (12dev) dumpfile using v11 psql:
Yeah, I can reproduce that here, using either -Fc or -Fd format dumps.
The immediate problem in your example is that the "defn" field of a
TABLE DATA entry is now null where it used to be an empty str
On Mon, Feb 25, 2019 at 11:01:05AM +0100, Dmitry Dolgov wrote:
> > On Mon, Feb 25, 2019 at 8:45 AM hubert depesz lubaczewski
> > wrote:
> >
> > I did upgrade of my test pg. Part of this is pg_dump -Fd of each
> > database, then upgrade binaries, then initdb, and pg_restore.
> >
> > But - I can't
> On Mon, Feb 25, 2019 at 8:45 AM hubert depesz lubaczewski
> wrote:
>
> I did upgrade of my test pg. Part of this is pg_dump -Fd of each
> database, then upgrade binaries, then initdb, and pg_restore.
>
> But - I can't restore any database that has any data - I get segfaults.
Thank for reportin
30 matches
Mail list logo
