On Wed, Oct 12, 2016 at 12:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark wrote:
>>> Fwiw I was considering proposing committing some patches for these old
>>> releases to make them easier to build. I would suggest creating a tag
>>> for a for this s
Robert Haas writes:
> On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark wrote:
>> Fwiw I was considering proposing committing some patches for these old
>> releases to make them easier to build. I would suggest creating a tag
>> for a for this stable legacy version and limiting the commits to just:
>>
On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark wrote:
> On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark wrote:
>>
>> The code is here:
>>
>> https://github.com/gsstark/retropg
>>
>> The build script is called "makeall" and it applies patches from the
>> "old-postgres-fixes" directory though some of the
On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark wrote:
>
> The code is here:
>
> https://github.com/gsstark/retropg
>
> The build script is called "makeall" and it applies patches from the
> "old-postgres-fixes" directory though some of the smarts are in the
> script because it knows about how to run
On Mon, Oct 10, 2016 at 3:36 AM, Jim Nasby wrote:
> FWIW, Greg Stark did a talk at PG Open about PG performance going back to at
> least 7.4. He did discuss what he had to do to get those versions to compile
> on modern tools, and has a set of patches that enable it. Unfortunately his
> slides are
On 10/7/16 12:48 PM, Tom Lane wrote:
Branches before about 7.3 or 7.4 don't build cleanly on modern tools.
In fact, they don't even build cleanly on my old HPUX 10.20 box ...
I just tried, and they have problems with the bison and flex I have
installed there now. As a data point, that bison exec
On Sat, Oct 8, 2016 at 2:59 AM, Stephen Frost wrote:
> Another approach to this would be to figure out a way for the newer
> testing framework in HEAD to be run against older versions, though we'd
> need to have a field which indicates which version of PG a given test
> should be run against as th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Realistically though, how much would code coverage info have helped?
> Code coverage on a back branch would not have told you about whether
> it leaves blobs behind in the final regression DB state. Code coverage
> on HEAD might have helped you notice some
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Stephen Frost wrote:
> > >
> > > > What would be really nice would be code coverage information for the
> > > > back-branches also, as that would allow us to figur
Alvaro Herrera writes:
> Stephen Frost wrote:
>> I wasn't sure how far back it went, but if it's only to 9.1, then yes,
>> farther than that. Specifically, to as far back as we wish to provide
>> support for pg_dump, assuming it's reasonable to do so.
> Do you really want to go back to applying
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> It might be a good idea to retroactively modify 9.1-9.3 so that there
>> are some blobs in the final state, for purposes of testing pg_dump and
>> pg_upgrade.
> I certainly think that would be a good idea. I thought we had been
>
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Stephen Frost wrote:
> >
> > > What would be really nice would be code coverage information for the
> > > back-branches also, as that would allow us to figure out what we're
> > > missing coverage for. I realize that we
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > What would be really nice would be code coverage information for the
> > back-branches also, as that would allow us to figure out what we're
> > missing coverage for. I realize that we don't like adding new things to
Stephen Frost wrote:
> What would be really nice would be code coverage information for the
> back-branches also, as that would allow us to figure out what we're
> missing coverage for. I realize that we don't like adding new things to
> back-branches as those changes could impact packagers, but
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Ugh. Thanks for fixing. I had tested back to 7.4 with the regression
> > tests but either those didn't include blobs or something got changed
> > after my testing and I didn't re-test all the way back when I should
> > have.
>
>
Stephen Frost writes:
> Ugh. Thanks for fixing. I had tested back to 7.4 with the regression
> tests but either those didn't include blobs or something got changed
> after my testing and I didn't re-test all the way back when I should
> have.
It looks like the final state of the regression test
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Amit Langote writes:
> > Just noticed that the getBlobs() query does not work for a 7.3 server
> > (maybe <= 7.3) due to the following change in commit 23f34fa4 [1]:
>
> Ugh.
>
> > I could fix that using the attached patch.
>
> There's more wrong than th
Robert Haas writes:
> On Fri, Oct 7, 2016 at 9:39 AM, Tom Lane wrote:
>> There's more wrong than that, as you'd notice if you tried dumping
>> a DB that actually had some LOs in it :-(. This obviously wasn't
>> tested on anything older than 9.0.
> Back in 2014, we talked about removing support
On Fri, Oct 7, 2016 at 9:39 AM, Tom Lane wrote:
> Amit Langote writes:
>> Just noticed that the getBlobs() query does not work for a 7.3 server
>> (maybe <= 7.3) due to the following change in commit 23f34fa4 [1]:
>
> Ugh.
>
>> I could fix that using the attached patch.
>
> There's more wrong tha
Amit Langote writes:
> Just noticed that the getBlobs() query does not work for a 7.3 server
> (maybe <= 7.3) due to the following change in commit 23f34fa4 [1]:
Ugh.
> I could fix that using the attached patch.
There's more wrong than that, as you'd notice if you tried dumping
a DB that actual
On 2016/10/07 11:47, Amit Langote wrote:
> Just noticed that the getBlobs() query does not work for a 7.3 server
> (maybe <= 7.3) due to the following change in commit 23f34fa4 [1]:
>
> else if (fout->remoteVersion >= 70100)
> appendPQExpBufferStr(blobQry,
> -
21 matches
Mail list logo