Le vendredi 3 mai 2013 02:54:15, Michael Paquier a écrit :
> On Fri, May 3, 2013 at 8:56 AM, Bruce Momjian wrote:
> > On Thu, May 2, 2013 at 09:31:03AM +0200, Magnus Hagander wrote:
> > > Actually, there is - I hear it quite often from people not so
> > > experienced in PostgreSQL. Though in fair
On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
> > > > > This changes the existing API which will confuse people that know it
> > > > > and invalidate everything written in software and on wikis as to how
> > > > > to do it. That means all the "in case of fire break glass"
> > >
On Fri, May 3, 2013 at 07:57:07AM +0200, Fabien COELHO wrote:
>
> >>This seems to suggest that instead of generating one large ebook, the
> >>build should generate a set of ebooks, say one for each part. At the
> >>minimum, a less detailed toc could be more usable and help navigate the
> >>huge c
On 03.05.2013 16:29, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
This changes the existing API which will confuse people that know it
and invalidate everything written in software and on wikis as to how
to do it. That means all the "in case of fire brea
On Tue, Apr 30, 2013 at 11:02 AM, Peter Eisentraut wrote:
> Revert "pg_ctl: Add idempotent option"
>
> This reverts commit 87306184580c9c49717b00d48a2f9e717f21e0a8. The
> behavior in certain cases is still being debated, and it's too late to
> solve this before beta.
You also need to remove the
On Fri, May 3, 2013 at 1:12 AM, Bruce Momjian wrote:
> I was more thinking of the idea of having some status on the first page
> that might need to change in a future release.
Incidentally, another option might be to have a .meta
fork that has information like this. It doesn't fundamentally chang
Le vendredi 3 mai 2013 15:40:51, Heikki Linnakangas a écrit :
> On 03.05.2013 16:29, Bruce Momjian wrote:
> > On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
> >> This changes the existing API which will confuse people that know it
> >> and invalidate everything written in
Hi,
I got the following assertion failure when I promoted the standby.
2013-05-04 00:12:31 JST sby1 LOG: received promote request
2013-05-04 00:12:31 JST sby1 FATAL: terminating walreceiver process
due to administrator command
2013-05-04 00:12:31 JST sby1 LOG: redo done at 0/6FFE038
2013-05-04
On 2013-05-03 16:11:13 +0100, Greg Stark wrote:
> On Fri, May 3, 2013 at 1:12 AM, Bruce Momjian wrote:
> > I was more thinking of the idea of having some status on the first page
> > that might need to change in a future release.
>
> Incidentally, another option might be to have a .meta
> fork th
On Fri, May 3, 2013 at 12:09 AM, Andres Freund wrote:
>> But that brings up an interesting question. How hard / feasible would it be
>> to add DIO functionality to PG itself?
>
> I don't think there is too much chance of that - but I also don't really
> see the point in trying to do it. We should
On Fri, May 3, 2013 at 05:24:54PM +0200, Andres Freund wrote:
> On 2013-05-03 16:11:13 +0100, Greg Stark wrote:
> > On Fri, May 3, 2013 at 1:12 AM, Bruce Momjian wrote:
> > > I was more thinking of the idea of having some status on the first page
> > > that might need to change in a future releas
On Sat, May 4, 2013 at 12:11:48AM +0900, Fujii Masao wrote:
> On Tue, Apr 30, 2013 at 11:02 AM, Peter Eisentraut wrote:
> > Revert "pg_ctl: Add idempotent option"
> >
> > This reverts commit 87306184580c9c49717b00d48a2f9e717f21e0a8. The
> > behavior in certain cases is still being debated, and i
On 5/3/13 2:05 AM, Fabien COELHO wrote:
>> EPUB is essentially a zip file with per-section simplified HTML files.
>> So any device that can render simple web pages should be able to handle
>> that with ease. What I think iBooks is doing is it internally
>> pre-renders all the pages in order to be
* Andres Freund (and...@2ndquadrant.com) wrote:
> The problem with an extra metadata fork is that it essentially would
> double the files in a cluster and it would also noticeably increase the
> amount of open files we need.
Why would we need it for every relation? We have other forks (fsm, vm),
On 05/02/2013 11:16 PM, Peter Eisentraut wrote:
On Wed, 2013-05-01 at 18:27 +0200, Fabien COELHO wrote:
The table of contents too much detailed, so it is long and slow to
scan, and there is no clear shortcut. Flipping pages in the
documentation takes ages (well, close to one second or more if I
Stephen Frost writes:
> I'm more concerned about moving information which really should be in
> the system catalogs out into magic files on disk..
Right. The whole thing is just a kluge, which I'm convinced we'll
regret sooner or later --- probably sooner. I would much rather drop
unlogged matv
Bruce Momjian escribió:
> On Fri, May 3, 2013 at 05:24:54PM +0200, Andres Freund wrote:
> > The problem with an extra metadata fork is that it essentially would
> > double the files in a cluster and it would also noticeably increase the
> > amount of open files we need.
> > There have been quite
On 2013-05-03 12:15:27 -0400, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> > On Fri, May 3, 2013 at 05:24:54PM +0200, Andres Freund wrote:
>
> > > The problem with an extra metadata fork is that it essentially would
> > > double the files in a cluster and it would also noticeably increase th
On Fri, May 3, 2013 at 12:10:14PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > I'm more concerned about moving information which really should be in
> > the system catalogs out into magic files on disk..
>
> Right. The whole thing is just a kluge, which I'm convinced we'll
> regret sooner
On Fri, May 3, 2013 at 12:05:45PM -0400, Andrew Dunstan wrote:
>
> On 05/02/2013 11:16 PM, Peter Eisentraut wrote:
> >On Wed, 2013-05-01 at 18:27 +0200, Fabien COELHO wrote:
> >>The table of contents too much detailed, so it is long and slow to
> >>scan, and there is no clear shortcut. Flipping p
Josh Berkus writes:
> As I understand it, we don't currently have any mechanism in Postgres
> which would cause allocated-but-empty pages.
That's not correct: the situation can easily arise after a database
crash. (The scenario is that we've done smgrextend to add the first
page to the file, but
On 2013-05-03 12:10:14 -0400, Tom Lane wrote:
> Stephen Frost writes:
> > I'm more concerned about moving information which really should be in
> > the system catalogs out into magic files on disk..
>
> Right. The whole thing is just a kluge, which I'm convinced we'll
> regret sooner or later --
Andres Freund writes:
> On 2013-05-03 12:10:14 -0400, Tom Lane wrote:
>> Right. The whole thing is just a kluge, which I'm convinced we'll
>> regret sooner or later --- probably sooner.
> I tentatively agree as well. The only argument for introducing some
> additional location for such informati
On Fri, May 3, 2013 at 12:45:36PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-05-03 12:10:14 -0400, Tom Lane wrote:
> >> Right. The whole thing is just a kluge, which I'm convinced we'll
> >> regret sooner or later --- probably sooner.
>
> > I tentatively agree as well. The only
Bruce Momjian wrote:
> On Fri, May 3, 2013 at 12:05:45PM -0400, Andrew Dunstan wrote:
> > I don't think we should be governed by the silly behaviour of one
> > epub reader. My ereader doesn't collapse the contents into one giant
> > list. If ibooks is doing stuff badly, complain to Apple.
>
> I
Not sure if I mentioned this, but having first line of the commit be a
subject has save me lots of time in writing the release notes. I know
it is helpful to others too who browse our commits on websites.
--
Bruce Momjian http://momjian.us
EnterpriseDB ht
I have removed both pg_ctl idempotent-commit items from the TODO list:
Allow pg_ctl --idempotent to a 'success' return code if the requested
start/stop action fails, but the cluster is already in the requested
state (Peter Eisentraut)
On 05/03/2013 01:23 PM, Bruce Momjian wrote:
Not sure if I mentioned this, but having first line of the commit be a
subject has save me lots of time in writing the release notes. I know
it is helpful to others too who browse our commits on websites.
Yeah. The recommended style is to have th
On Fri, May 3, 2013 at 01:42:33PM -0400, Andrew Dunstan wrote:
>
> On 05/03/2013 01:23 PM, Bruce Momjian wrote:
> >Not sure if I mentioned this, but having first line of the commit be a
> >subject has save me lots of time in writing the release notes. I know
> >it is helpful to others too who br
On 03.05.2013 20:56, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:42:33PM -0400, Andrew Dunstan wrote:
On 05/03/2013 01:23 PM, Bruce Momjian wrote:
Not sure if I mentioned this, but having first line of the commit be a
subject has save me lots of time in writing the release notes. I know
i
On Fri, May 3, 2013 at 09:08:08PM +0300, Heikki Linnakangas wrote:
> On 03.05.2013 20:56, Bruce Momjian wrote:
> >On Fri, May 3, 2013 at 01:42:33PM -0400, Andrew Dunstan wrote:
> >>
> >>On 05/03/2013 01:23 PM, Bruce Momjian wrote:
> >>>Not sure if I mentioned this, but having first line of the co
Tom Lane wrote:
> The current matview design gets around this problem by requiring
> that transition between scannable and unscannable states involve
> a complete table rewrite, and thus the transactionality issue can
> be hidden behind a transactional update of the matview's
> pg_class.relfileno
On Fri, May 3, 2013 at 10:28 AM, Bruce Momjian wrote:
> I have removed both pg_ctl idempotent-commit items from the TODO list:
>
>
>
> Allow pg_ctl --idempotent to a 'success' return code if the
> requested
> start/stop action fails, but the cluster is already in th
Heikki Linnakangas writes:
> On 03.05.2013 20:56, Bruce Momjian wrote:
>> On Fri, May 3, 2013 at 01:42:33PM -0400, Andrew Dunstan wrote:
>>> Yeah. The recommended style is to have the first line be 50 chars or
>>> less, which is a bit unfortunate - it can be a challenge to keep to
>>> that limit
On 05/03/2013 01:56 PM, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:42:33PM -0400, Andrew Dunstan wrote:
On 05/03/2013 01:23 PM, Bruce Momjian wrote:
Not sure if I mentioned this, but having first line of the commit be a
subject has save me lots of time in writing the release notes. I kno
On 1 May 2013 20:40, Jeff Davis wrote:
>> Looks easy. There is no additional logic for checksums, so there's no
>> third complexity.
>>
>> So we either have
>> * cleanup info with vismap setting info
>> * cleanup info only
>>
>> which is the same number of WAL records as we have now, just that we
On 05/03/2013 02:43 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 03.05.2013 20:56, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:42:33PM -0400, Andrew Dunstan wrote:
Yeah. The recommended style is to have the first line be 50 chars or
less, which is a bit unfortunate - it can be a cha
On 2013-05-03 14:54:23 -0400, Andrew Dunstan wrote:
>
> On 05/03/2013 02:43 PM, Tom Lane wrote:
> >Heikki Linnakangas writes:
> >>On 03.05.2013 20:56, Bruce Momjian wrote:
> >>>On Fri, May 3, 2013 at 01:42:33PM -0400, Andrew Dunstan wrote:
> Yeah. The recommended style is to have the first l
Kevin Grittner writes:
> Tom Lane wrote:
>> The current matview design gets around this problem by requiring
>> that transition between scannable and unscannable states involve
>> a complete table rewrite, and thus the transactionality issue can
>> be hidden behind a transactional update of the m
On 5/2/13 6:00 PM, Kevin Grittner wrote:
> (1) The ability to count on the results from a query which
> references a matview to reflect valid data from *some* point in
> time.
>
> (2) The ability to create unlogged materialized views.
>
> (3) The ability to consider a zero-length matview heap
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> The current matview design gets around this problem by
>>> requiring that transition between scannable and unscannable
>>> states involve a complete table rewrite, and thus the
>>> transactionality issue can be hidden behind a trans
On Fri, 2013-05-03 at 19:52 +0100, Simon Riggs wrote:
> On 1 May 2013 20:40, Jeff Davis wrote:
>
> >> Looks easy. There is no additional logic for checksums, so there's no
> >> third complexity.
> >>
> >> So we either have
> >> * cleanup info with vismap setting info
> >> * cleanup info only
> >>
Kevin Grittner writes:
> What do you see that I'm missing?
TBH, if I had 20-20 foresight, we'd not be having this discussion:
either I could see that you're right and this patch isn't going to
cause us enormous pain, or I could put my finger on exactly where
and why it's going to hurt us. But I
On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian wrote:
> Yes, I think the big question is how much information do we want per
> relation that we don't need in the system tables.
It's not that we don't need it in the system tables. It's that there's
some state that we *can't* have in the system tabl
On Sat, May 4, 2013 at 03:04:33AM +0100, Greg Stark wrote:
> On Fri, May 3, 2013 at 5:49 PM, Bruce Momjian wrote:
> > Yes, I think the big question is how much information do we want per
> > relation that we don't need in the system tables.
>
> It's not that we don't need it in the system tables
I don't think we should be governed by the silly behaviour of one epub
reader. My ereader doesn't collapse the contents into one giant list. If
ibooks is doing stuff badly, complain to Apple.
Indeed that makes sense as the issue is specific to this reader. I was
afraid that the problem was m
On 04/05/13 18:11, Fabien COELHO wrote:
I don't think we should be governed by the silly behaviour of one
epub reader. My ereader doesn't collapse the contents into one giant
list. If ibooks is doing stuff badly, complain to Apple.
Indeed that makes sense as the issue is specific to this rea
47 matches
Mail list logo
