On Tue, Jun 17, 2014 at 08:46:00PM -0400, Bruce Momjian wrote:
> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> > >> Can't you compare it to the historic default value? I mean, add an
> >
On Wed, Jun 18, 2014 at 3:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane wrote:
>>> The net behavior would be the same, but I thought it might be easier to
>>> code by thinking of it this way. Or maybe it wouldn't --- it's just a
>>> suggestion.
>
>> W
Robert Haas writes:
> On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane wrote:
>> The net behavior would be the same, but I thought it might be easier to
>> code by thinking of it this way. Or maybe it wouldn't --- it's just a
>> suggestion.
> Well, the difference is that if we just don't check it, the
On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian wrote:
>>> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
What about comparing to the symbolic value LOBLKSIZE? This would make
pg_upgrade assume that th
Robert Haas writes:
> On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian wrote:
>> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
>>> What about comparing to the symbolic value LOBLKSIZE? This would make
>>> pg_upgrade assume that the old installation had been tweaked the same
>>> as in i
On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian wrote:
> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>> > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
>> >> Can't you compare it to the historic default value? I mean, add an
>> >> assumptio
On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> >> Can't you compare it to the historic default value? I mean, add an
> >> assumption that people thus far has never tweaked it.
>
> > Well, if
Bruce Momjian writes:
> On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
>> Can't you compare it to the historic default value? I mean, add an
>> assumption that people thus far has never tweaked it.
> Well, if they did tweak it, then they would be unable to use pg_upgrade
> becau
On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Uh, I think pg_upgrade needs to check that they match too.
> > >
> > > Possibly. What do you think it should do
Bruce Momjian wrote:
> On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Uh, I think pg_upgrade needs to check that they match too.
> >
> > Possibly. What do you think it should do when examining a pg_control
> > version that lacks the field?
>
> Good que
On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, I think pg_upgrade needs to check that they match too.
>
> Possibly. What do you think it should do when examining a pg_control
> version that lacks the field?
Good question. I have existing cases where f
Bruce Momjian writes:
> Uh, I think pg_upgrade needs to check that they match too.
Possibly. What do you think it should do when examining a pg_control
version that lacks the field?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Wed, Jun 4, 2014 at 06:57:31PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> There are at least two places in inv_api.c where we have
> >> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
> >> into a local variable of size L
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> There are at least two places in inv_api.c where we have
>> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
>> into a local variable of size LOBLKSIZE, so that the only thing standing
>> between us and a stack-
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> There are at least two places in inv_api.c where we have
> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
> into a local variable of size LOBLKSIZE, so that the only thing standing
> between us and a stack-smash security issue that's t
Robert Haas writes:
> On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane wrote:
>> BTW, just comparing the handling of TOAST_MAX_CHUNK_SIZE and LOBLKSIZE,
>> I noticed that the tuptoaster.c functions are reasonably paranoid about
>> checking that toast chunks are the expected size, but the large object
>>
On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> I've not heard one either, but there was just somebody asking in
>>> pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
>>> That's not a big enough sample size t
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I've not heard one either, but there was just somebody asking in
>> pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
>> That's not a big enough sample size to make me panic about getting a
>> hasty fix into 9.4,
Andres Freund writes:
> Btw, I had wondered before if we shouldn't also add sizeof(long) to
> pg_control to catch cases where a database is copied between a LLP64
> (64bit windows) and an LP64 (nearly every other 64bit system) system. I
> have my doubts that we're completely clean about the size
>
On 2014-06-04 10:03:09 -0400, Tom Lane wrote:
> I just chanced to notice that if someone were to change the value for
> LOBLKSIZE and recompile, there'd be nothing to stop him from starting
> that postmaster against an existing database, even though it would
> completely misinterpret and mangle any
Stephen Frost writes:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> On 06/04/2014 10:03 AM, Tom Lane wrote:
>>> I just chanced to notice that if someone were to change the value for
>>> LOBLKSIZE and recompile, there'd be nothing to stop him from starting
>>> that postmaster against an existi
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Andrew Dunstan (and...@dunslane.net) wrote:
> >> On 06/04/2014 10:03 AM, Tom Lane wrote:
> >>> I just chanced to notice that if someone were to change the value for
> >>> LOBLKSIZE and recompile, there'd be nothing to stop him fr
On 06/04/2014 10:27 AM, Andres Freund wrote:
On 2014-06-04 10:25:07 -0400, Andrew Dunstan wrote:
If we did an initdb-requiring change for 9.4 could we piggy-back this onto
it?
Do you know of a problem requiring that?
No, just thinking ahead.
cheers
andrew
--
Sent via pgsql-hackers mai
* Andrew Dunstan (and...@dunslane.net) wrote:
> On 06/04/2014 10:03 AM, Tom Lane wrote:
> >I just chanced to notice that if someone were to change the value for
> >LOBLKSIZE and recompile, there'd be nothing to stop him from starting
> >that postmaster against an existing database, even though it w
On 2014-06-04 10:25:07 -0400, Andrew Dunstan wrote:
> If we did an initdb-requiring change for 9.4 could we piggy-back this onto
> it?
Do you know of a problem requiring that?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24
On 06/04/2014 10:03 AM, Tom Lane wrote:
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
completely misinterpret and mangle any data in pg
I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
completely misinterpret and mangle any data in pg_largeobject.
I think there ought to be a
27 matches
Mail list logo
