On Mon, May 27, 2013 at 9:41 AM, Simon Riggs wrote:
> On 27 May 2013 15:36, Tom Lane wrote:
>> Bruce Momjian writes:
>>> On Mon, May 27, 2013 at 08:26:48AM -0400, Stephen Frost wrote:
That said, many discussions and ideas do get shut down, perhaps too
early, because of pg_upgrade consi
Bruce Momjian wrote:
> On Mon, May 27, 2013 at 03:06:13PM -0400, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > I would have each data segment be self-identifying, i.e. have a magic
> > number at the beginning of the file and the relation OID, some fork
> > identification and the segment numbe
> On 05/28/2013 04:05 PM, Bruce Momjian wrote:
>>
>> On Tue, May 28, 2013 at 03:39:10PM -0700, Joshua D. Drake wrote:
>>>
>>> On 05/28/2013 03:36 PM, Bruce Momjian wrote:
>>>
> The other option would be to do it on query execute but that doesn't
> seem as efficient as it would have to be pa
On Tue, May 28, 2013 at 4:26 PM, Joshua D. Drake wrote:
>
> On 05/28/2013 02:18 PM, Bruce Momjian wrote:
>
>>> I would like to see the ability to define if a query is read only at
>>> the protocol level, so that load balances that speak libpq can know
>>> what to do with the query without parsing
On 05/29/2013 05:11 AM, Bruce Momjian wrote:
> Sure, it is on the TODO list:
>
> https://wiki.postgresql.org/wiki/Todo#.2Fcontrib.2Fpg_upgrade
>
> I can only get a link to pg_upgrade from there, so look two sections
> below that for "Wire Protocol Changes".
Thanks.
The direct link is
https:
On 05/28/2013 04:05 PM, Bruce Momjian wrote:
On Tue, May 28, 2013 at 03:39:10PM -0700, Joshua D. Drake wrote:
On 05/28/2013 03:36 PM, Bruce Momjian wrote:
The other option would be to do it on query execute but that doesn't
seem as efficient as it would have to be parsed each time. Although
On Tue, May 28, 2013 at 03:39:10PM -0700, Joshua D. Drake wrote:
>
> On 05/28/2013 03:36 PM, Bruce Momjian wrote:
>
> >>The other option would be to do it on query execute but that doesn't
> >>seem as efficient as it would have to be parsed each time. Although
> >>it would still be better than re
On 05/28/2013 03:36 PM, Bruce Momjian wrote:
The other option would be to do it on query execute but that doesn't
seem as efficient as it would have to be parsed each time. Although
it would still be better than reading the actual SQL.
Well, you could do SET TRANSACTION READ ONLY, and that wo
On Mon, May 27, 2013 at 03:06:13PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > OK, I have added a section to the TODO list for this:
> >
> > Desired changes that would prevent upgrades with pg_upgrade
> >
> > 32-bit page checksums
> >
> > Are there any others?
>
On Tue, May 28, 2013 at 02:26:06PM -0700, Joshua D. Drake wrote:
> >Sounds nice, but how would we do that? That would require libpq to know
> >it, right? Do we pass anything back after parsing but before execution?
> > Could it be optional? What about functions that modify the database
> >--- i
Bruce Momjian wrote:
> On Mon, May 27, 2013 at 05:21:16PM -0700, Joshua D. Drake wrote:
> > I would like to see the ability to define if a query is read only at
> > the protocol level, so that load balances that speak libpq can know
> > what to do with the query without parsing it.
>
> Sounds nic
On 05/28/2013 02:18 PM, Bruce Momjian wrote:
I would like to see the ability to define if a query is read only at
the protocol level, so that load balances that speak libpq can know
what to do with the query without parsing it.
Sounds nice, but how would we do that? That would require libpq
On Mon, May 27, 2013 at 02:09:05PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 27, 2013 at 09:17:50AM -0400, Bruce Momjian wrote:
> >> Yes, we should be collecting things we want to do for a pg_upgrade break
> >> so we can see the list all in one place.
>
> > OK, I have added a
On Mon, May 27, 2013 at 05:21:16PM -0700, Joshua D. Drake wrote:
>
> On 05/27/2013 04:58 PM, Craig Ringer wrote:
> >
> >On 05/28/2013 12:41 AM, Simon Riggs wrote:
> >>I'm happy with that.
> >>
> >>I was also thinking about collecting changes not related just to disk
> >>format, if any exist.
> >An
On Tue, May 28, 2013 at 07:58:33AM +0800, Craig Ringer wrote:
> On 05/28/2013 12:41 AM, Simon Riggs wrote:
> > I'm happy with that.
> >
> > I was also thinking about collecting changes not related just to disk
> > format, if any exist.
> Any wire protocol or syntax changes?
>
> I can't seem to fin
On 05/28/2013 08:36 AM, Hannu Krosing wrote:
The conversation does not change.
Further, we are not Firefox. We are not user software. We are
developer software.
At least some of the real-world problems with PostgreSQL
comes from "We are developer software" mentality.
Yes, We are developer so
On Tue, May 28, 2013 at 11:56 AM, Josh Berkus wrote:
>
>>> This argument comes up every couple of years and the people that
>>> are trying to solve the problem by changing the versioning are
>>> ignoring the fact that there is no problem to solve.
>
> We just had this discussion on -advocacy (wher
>> This argument comes up every couple of years and the people that
>> are trying to solve the problem by changing the versioning are
>> ignoring the fact that there is no problem to solve.
We just had this discussion on -advocacy (where it belongs, frankly) a
couple months ago:
http://www.postg
On 05/28/2013 06:13 AM, Joshua D. Drake wrote:
>
> On 05/27/2013 06:53 PM, Craig Ringer wrote:
>>
>> On 05/28/2013 09:39 AM, Gavin Flower wrote:
>>> Yes, I hate the Firefox style number inflation.
>> I was arguing *for* it ;-)
>>
>> I don't like it much either, but (a) we do about one release a yea
On Sat, May 25, 2013 at 11:27 AM, Merlin Moncure wrote:
> On Sat, May 25, 2013 at 4:39 AM, Simon Riggs wrote:
>> There are a number of changes we'd probably like to make to the way
>> things work in Postgres. This thread is not about discussing what
>> those are, just to say that requirements exi
On 05/27/2013 06:53 PM, Craig Ringer wrote:
On 05/28/2013 09:39 AM, Gavin Flower wrote:
Yes, I hate the Firefox style number inflation.
I was arguing *for* it ;-)
I don't like it much either, but (a) we do about one release a year, not
one every few weeks and (b) it's very clear from a quick
On 05/28/2013 09:39 AM, Gavin Flower wrote:
> Yes, I hate the Firefox style number inflation.
I was arguing *for* it ;-)
I don't like it much either, but (a) we do about one release a year, not
one every few weeks and (b) it's very clear from a quick look at Stack
Overflow or first-posts to pgsql-
On 28/05/13 11:48, Craig Ringer wrote:
On 05/27/2013 05:45 PM, Michael Paquier wrote:
On Mon, May 27, 2013 at 2:01 PM, Craig Ringer wrote:
On 05/25/2013 05:39 PM, Simon Riggs wrote:
- Switching to single-major-version release numbering. The number of
people who say "PostgreSQL 9.x" is amazing
On 05/27/2013 04:58 PM, Craig Ringer wrote:
On 05/28/2013 12:41 AM, Simon Riggs wrote:
I'm happy with that.
I was also thinking about collecting changes not related just to disk
format, if any exist.
Any wire protocol or syntax changes?
I can't seem to find a "things we want to do in wire p
On 05/28/2013 12:41 AM, Simon Riggs wrote:
> I'm happy with that.
>
> I was also thinking about collecting changes not related just to disk
> format, if any exist.
Any wire protocol or syntax changes?
I can't seem to find a "things we want to do in wire protocol v4" doc in
the wiki but I know I've
On 05/28/2013 07:22 AM, Michael Paquier wrote:
> On Tue, May 28, 2013 at 7:52 AM, David Fetter wrote:
>
>> What's been proposed before that wouldn't break previous applications
>> is a numbering system like this:
>>
>> 10.0.0
>> 10.0.1
>> 10.0.2
>> 10.0.3
>> ...
>> 11.0.0
>> 11.0.1
>>
>> i.e. only
On 05/27/2013 05:45 PM, Michael Paquier wrote:
> On Mon, May 27, 2013 at 2:01 PM, Craig Ringer wrote:
>
>> On 05/25/2013 05:39 PM, Simon Riggs wrote:
>> - Switching to single-major-version release numbering. The number of
>> people who say "PostgreSQL 9.x" is amazing; even *packagers* get this
>>
On Tue, May 28, 2013 at 7:52 AM, David Fetter wrote:
> What's been proposed before that wouldn't break previous applications
> is a numbering system like this:
>
> 10.0.0
> 10.0.1
> 10.0.2
> 10.0.3
> ...
> 11.0.0
> 11.0.1
>
> i.e. only change the "most-major" version number and always leave the
>
Michael Paquier escribió:
> On Tue, May 28, 2013 at 12:36 AM, Alvaro Herrera
> wrote:
> > You do -- they are used for minor releases, i.e. 10.1 would be a bugfix
> > release for 10.0. If we continue using the current numbering scheme,
> > 10.1 would be the major version after 10.0.
> >
> Sorry fo
On Tue, May 28, 2013 at 07:39:35AM +0900, Michael Paquier wrote:
> On Tue, May 28, 2013 at 12:36 AM, Alvaro Herrera
> wrote:
>
> > Michael Paquier escribió:
> > > On Mon, May 27, 2013 at 2:01 PM, Craig Ringer
> > wrote:
> > >
> > > > On 05/25/2013 05:39 PM, Simon Riggs wrote:
> > > > - Switching
On Tue, May 28, 2013 at 12:36 AM, Alvaro Herrera
wrote:
> Michael Paquier escribió:
> > On Mon, May 27, 2013 at 2:01 PM, Craig Ringer
> wrote:
> >
> > > On 05/25/2013 05:39 PM, Simon Riggs wrote:
> > > - Switching to single-major-version release numbering. The number of
> > > people who say "Post
Bruce Momjian wrote:
> OK, I have added a section to the TODO list for this:
>
> Desired changes that would prevent upgrades with pg_upgrade
>
> 32-bit page checksums
>
> Are there any others?
I would have each data segment be self-identifying, i.e. have a magic
number a
Bruce Momjian writes:
> On Mon, May 27, 2013 at 09:17:50AM -0400, Bruce Momjian wrote:
>> Yes, we should be collecting things we want to do for a pg_upgrade break
>> so we can see the list all in one place.
> OK, I have added a section to the TODO list for this:
> Desired changes that woul
On 27 May 2013 15:36, Tom Lane wrote:
> Bruce Momjian writes:
>> On Mon, May 27, 2013 at 08:26:48AM -0400, Stephen Frost wrote:
>>> That said, many discussions and ideas do get shut down, perhaps too
>>> early, because of pg_upgrade considerations. If we had a plan to have
>>> an incompatible re
On Mon, May 27, 2013 at 09:17:50AM -0400, Bruce Momjian wrote:
> > That said, many discussions and ideas do get shut down, perhaps too
> > early, because of pg_upgrade considerations. If we had a plan to have
> > an incompatible release in the future, those ideas and discussions might
> > be able
Tom Lane wrote:
> Bruce Momjian writes:
> > Yes, we should be collecting things we want to do for a pg_upgrade break
> > so we can see the list all in one place.
>
> Precisely. We've said right along that we reserve the right to have a
> non-upgradable disk format change whenever sufficiently m
Michael Paquier escribió:
> On Mon, May 27, 2013 at 2:01 PM, Craig Ringer wrote:
>
> > On 05/25/2013 05:39 PM, Simon Riggs wrote:
> > - Switching to single-major-version release numbering. The number of
> > people who say "PostgreSQL 9.x" is amazing; even *packagers* get this
> > wrong and produc
Bruce Momjian writes:
> On Mon, May 27, 2013 at 08:26:48AM -0400, Stephen Frost wrote:
>> That said, many discussions and ideas do get shut down, perhaps too
>> early, because of pg_upgrade considerations. If we had a plan to have
>> an incompatible release in the future, those ideas and discussi
On 05/26/2013 06:18 PM, Josh Berkus wrote:
>> Not sure which ones Simon meant, but at least any new/better
>> storage manager would seem to me to be requiring
>> a non-pg_upgrade upgrade path unless we require the storage manager
>> to also include a parallel implementation of pg_upgrade.
> Isn't t
On Mon, May 27, 2013 at 08:26:48AM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > If I had to _guess_, I would say users who are using the default storage
> > manager would still be able to use pg_upgrade, and those using
> > non-default storage managers perhaps can't.
* Bruce Momjian (br...@momjian.us) wrote:
> If I had to _guess_, I would say users who are using the default storage
> manager would still be able to use pg_upgrade, and those using
> non-default storage managers perhaps can't.
That would make sense.
> But, again, this is all so hypothetical that
On Sun, May 26, 2013 at 09:18:41PM -0400, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
> > and it's entirely possible that we'll be able to implement SMs without
> > breaking pgupgrade.
>
> I'd certainly hope so.. It's certainly not obvious, to me at least,
> why a new SM or su
On Mon, May 27, 2013 at 2:01 PM, Craig Ringer wrote:
> On 05/25/2013 05:39 PM, Simon Riggs wrote:
> - Switching to single-major-version release numbering. The number of
> people who say "PostgreSQL 9.x" is amazing; even *packagers* get this
> wrong and produce "postgresql-9" packages. Witness Ama
On 05/25/2013 05:39 PM, Simon Riggs wrote:
> 2. Name the next release after that 10.0 (would have been 9.5). We
> declare now that
> a) 10.0 will support on-line upgrade from 9.4 (only)
> b) various major incompatibilities will be introduced in 10.0 - the
> change in release number will indicate to
The assumption that we ought to plan expressly for an incompatibility that
essentially discards pg_upgrade seems premature, particularly in advance of
would-be solutions that, in some cases, mightn't actually work.
If pg_upgrade doesn't work, then, at present, the plausible solutions are
to either
Stephen Frost writes:
> btw, has anyone posted the SM API proposal..? Unfortunately, I think I
> had to leave before that was hashed out..
There isn't one yet. We think we understand where the pain points are,
but there's still a long way to go to have a proposal.
regar
* Josh Berkus (j...@agliodbs.com) wrote:
> and it's entirely possible that we'll be able to implement SMs without
> breaking pgupgrade.
I'd certainly hope so.. It's certainly not obvious, to me at least,
why a new SM or supporting any of those features would require
breaking pg_upgrade. Perhaps
> Not sure which ones Simon meant, but at least any new/better
> storage manager would seem to me to be requiring
> a non-pg_upgrade upgrade path unless we require the storage manager
> to also include a parallel implementation of pg_upgrade.
Isn't this a bit of horse-cart inversion here? We jus
On 05/26/2013 04:22 PM, Bruce Momjian wrote:
> On Sun, May 26, 2013 at 09:18:11AM -0400, Bruce Momjian wrote:
>> On Sun, May 26, 2013 at 10:53:37AM +0100, Simon Riggs wrote:
I consider this thread to be not thought-through, obviously.
>>> My proposal has had lots of serious consideration, but
On Sun, May 26, 2013 at 09:18:11AM -0400, Bruce Momjian wrote:
> On Sun, May 26, 2013 at 10:53:37AM +0100, Simon Riggs wrote:
> > > I consider this thread to be not thought-through, obviously.
> >
> > My proposal has had lots of serious consideration, but that is not the
> > topic of this thread.
On Sun, May 26, 2013 at 10:53:37AM +0100, Simon Riggs wrote:
> > I consider this thread to be not thought-through, obviously.
>
> My proposal has had lots of serious consideration, but that is not the
> topic of this thread.
>
> The title of the thread is a general one, with a clear objective.
>
On 25 May 2013 21:44, Bruce Momjian wrote:
> On Sat, May 25, 2013 at 10:39:30AM +0100, Simon Riggs wrote:
>> There are a number of changes we'd probably like to make to the way
>> things work in Postgres. This thread is not about discussing what
>> those are, just to say that requirements exist an
On Sat, May 25, 2013 at 10:39:30AM +0100, Simon Riggs wrote:
> There are a number of changes we'd probably like to make to the way
> things work in Postgres. This thread is not about discussing what
> those are, just to say that requirements exist and have been discussed
> in various threads over t
On 25 May 2013 18:13, Jeff Davis wrote:
> On Sat, 2013-05-25 at 10:39 +0100, Simon Riggs wrote:
>> The constraint on such changes is that we've decided that we must have
>> an upgrade path from release to release.
>
> Is this proposal only relaxing the binary upgrade requirement, or would
> it als
On Sat, 2013-05-25 at 10:39 +0100, Simon Riggs wrote:
> The constraint on such changes is that we've decided that we must have
> an upgrade path from release to release.
Is this proposal only relaxing the binary upgrade requirement, or would
it also relax other compatibility requirements, such as
On Sat, May 25, 2013 at 4:39 AM, Simon Riggs wrote:
> There are a number of changes we'd probably like to make to the way
> things work in Postgres. This thread is not about discussing what
> those are, just to say that requirements exist and have been discussed
> in various threads over time.
>
>
There are a number of changes we'd probably like to make to the way
things work in Postgres. This thread is not about discussing what
those are, just to say that requirements exist and have been discussed
in various threads over time.
The constraint on such changes is that we've decided that we mu
57 matches
Mail list logo
