Peter Eisentraut writes:
> On Sun, 2012-09-16 at 15:58 -0400, Tom Lane wrote:
>> Maybe we're talking past each other. What I thought you meant was
>> adding this #define unconditionally, without any awareness of what it
>> might do on particular platforms. If you are thinking of adding it
>> onl
On Sun, 2012-09-16 at 15:58 -0400, Tom Lane wrote:
> Maybe we're talking past each other. What I thought you meant was
> adding this #define unconditionally, without any awareness of what it
> might do on particular platforms. If you are thinking of adding it
> only on platforms where it is consi
On Mon, Sep 17, 2012 at 11:14 AM, Andres Freund wrote:
> I just noted during investigating of the impact of the fakerelcache bug that
> contrary to whats claimed at several places END_OF_RECOVERY checkpoints do
> *not* behave the same way CHECKPOINT_IS_SHUTDOWN ones do. Which doesn't seem
> to
>
On Sun, 2012-09-16 at 16:16 -0500, Kevin Grittner wrote:
> I'm attaching an alternative proposal, with changes for the following
> reasons:
Looks good to me, aside from not wrapping the text.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Mon, Sep 17, 2012 at 01:03:37PM +0800, Rural Hunter wrote:
> >As you can see, we look at the existing TOAST usage and force the new
> >cluster to match. As I remember we replay the DROP COLUMN in binary
> >upgrade mode so the new cluster always matches the old cluster's TOAST
> >usage. I certa
On 17 September 2012 15:59, Robert Haas wrote:
> On Sun, Sep 16, 2012 at 2:54 PM, Simon Riggs wrote:
>> Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown checkpoint.
>> Recovery code documents clearly that a shutdown checkpoint is executed at
>> end of recovery - a shutdown checkpoin
Alvaro Herrera wrote:
> Excerpts from Kevin Grittner's message:
>
>> (1) The complete re-wrap of that first paragraph made it really
>> hard to see what the actual change to the documentation was. I
>> would rather change it like this and have a separate patch to
>> re-wrap the paragraph (with
Excerpts from Kevin Grittner's message of dom sep 16 18:16:22 -0300 2012:
> (1) The complete re-wrap of that first paragraph made it really hard
> to see what the actual change to the documentation was. I would
> rather change it like this and have a separate patch to re-wrap the
> paragraph (wi
On Monday, September 17, 2012 04:59:06 PM Robert Haas wrote:
> On Sun, Sep 16, 2012 at 2:54 PM, Simon Riggs wrote:
> > Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown
> > checkpoint. Recovery code documents clearly that a shutdown checkpoint
> > is executed at end of recovery - a sh
On Sun, Sep 16, 2012 at 2:54 PM, Simon Riggs wrote:
> Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown checkpoint.
> Recovery code documents clearly that a shutdown checkpoint is executed at
> end of recovery - a shutdown checkpoint WAL record is written but the buffer
> manager had
On Monday, September 17, 2012 04:18:28 PM Heikki Linnakangas wrote:
> On 17.09.2012 17:08, Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> On 17.09.2012 13:01, Andres Freund wrote:
> >>> It seems we would need one additional callback for both approaches
> >>> like: ->error(severity, format, ..
On Monday, September 17, 2012 04:08:01 PM Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 17.09.2012 13:01, Andres Freund wrote:
> >> It seems we would need one additional callback for both approaches like:
> >> ->error(severity, format, ...)
> >> For both to avoid having to draw in elog.c.
>
On 17.09.2012 17:08, Tom Lane wrote:
Heikki Linnakangas writes:
On 17.09.2012 13:01, Andres Freund wrote:
It seems we would need one additional callback for both approaches like:
->error(severity, format, ...)
For both to avoid having to draw in elog.c.
Yeah. Another approach would be to re
Heikki Linnakangas writes:
> On 17.09.2012 13:01, Andres Freund wrote:
>> It seems we would need one additional callback for both approaches like:
>> ->error(severity, format, ...)
>> For both to avoid having to draw in elog.c.
> Yeah. Another approach would be to return the error string from
>
Andres Freund writes:
> Btw, I played with this some more on Saturday and I think, while definitely a
> bad bug, the actual consequences aren't as bad as at least I initially feared.
> Fake relcache entries are currently set in 3 scenarios during recovery:
> 1. removal of ALL_VISIBLE in heapam.c
On Sun, Sep 16, 2012 at 11:52 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > I noticed that xlog.h uses PGDLLIMPORT, but it does not include c.h
> > directly or indirectly.
>
> In general, all include files in Postgres assume that you've included
> postgres.h or postgres_fe.h (as appropriate) f
On Monday, September 17, 2012 12:52:32 PM Heikki Linnakangas wrote:
> On 17.09.2012 12:07, Andres Freund wrote:
> > On Monday, September 17, 2012 10:30:35 AM Heikki Linnakangas wrote:
> >> The user of the facility doesn't need to be aware of record boundaries,
> >> that's the responsibility of the
On Sun, Sep 16, 2012 at 12:44 PM, Andrew Dunstan wrote:
>
> On 09/16/2012 12:04 PM, Tom Lane wrote:
>>
>> It's annoying that the buildfarm animals running on older versions of
>> Solaris randomly fail with "Connection refused" errors, such as in
>> today's example:
>>
>> http://buildfarm.postgresq
On Monday, September 17, 2012 01:50:33 PM Heikki Linnakangas wrote:
> On 17.09.2012 14:42, Andres Freund wrote:
> > On Monday, September 17, 2012 12:55:47 PM Heikki Linnakangas wrote:
> >> On 17.09.2012 13:01, Andres Freund wrote:
> >>> On Monday, September 17, 2012 11:07:28 AM Andres Freund wrote:
On 17.09.2012 14:42, Andres Freund wrote:
On Monday, September 17, 2012 12:55:47 PM Heikki Linnakangas wrote:
On 17.09.2012 13:01, Andres Freund wrote:
On Monday, September 17, 2012 11:07:28 AM Andres Freund wrote:
On Monday, September 17, 2012 10:30:35 AM Heikki Linnakangas wrote:
On 17.09.2
On Monday, September 17, 2012 12:55:47 PM Heikki Linnakangas wrote:
> On 17.09.2012 13:01, Andres Freund wrote:
> > On Monday, September 17, 2012 11:07:28 AM Andres Freund wrote:
> >> On Monday, September 17, 2012 10:30:35 AM Heikki Linnakangas wrote:
> >>> On 17.09.2012 11:12, Andres Freund wrote:
On 17.09.2012 13:01, Andres Freund wrote:
On Monday, September 17, 2012 11:07:28 AM Andres Freund wrote:
On Monday, September 17, 2012 10:30:35 AM Heikki Linnakangas wrote:
On 17.09.2012 11:12, Andres Freund wrote:
On Monday, September 17, 2012 09:40:17 AM Heikki Linnakangas wrote:
If you don'
On 17.09.2012 12:07, Andres Freund wrote:
On Monday, September 17, 2012 10:30:35 AM Heikki Linnakangas wrote:
The user of the facility doesn't need to be aware of record boundaries,
that's the responsibility of the facility. I thought that's exactly the
point of generalizing this thing, to make
On Monday, September 17, 2012 11:07:28 AM Andres Freund wrote:
> On Monday, September 17, 2012 10:30:35 AM Heikki Linnakangas wrote:
> > On 17.09.2012 11:12, Andres Freund wrote:
> > > On Monday, September 17, 2012 09:40:17 AM Heikki Linnakangas wrote:
> > > If you don't want the capability to forw
On Monday, September 17, 2012 10:30:35 AM Heikki Linnakangas wrote:
> On 17.09.2012 11:12, Andres Freund wrote:
> > On Monday, September 17, 2012 09:40:17 AM Heikki Linnakangas wrote:
> >> On 15.09.2012 03:39, Andres Freund wrote:
> >> 2. We should focus on reading WAL, I don't see the point of mix
On 17 September 2012 07:44, Andres Freund wrote:
> So I think while that bug had the possibility of being really bad we were
> pretty lucky...
Yes, agreed. The impact is not as severe as I originally thought.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development
On 17.09.2012 11:12, Andres Freund wrote:
On Monday, September 17, 2012 09:40:17 AM Heikki Linnakangas wrote:
On 15.09.2012 03:39, Andres Freund wrote:
2. We should focus on reading WAL, I don't see the point of mixing WAL
writing into this.
If you write something that filters/analyzes and then
Hi Heikki,
On Monday, September 17, 2012 09:40:17 AM Heikki Linnakangas wrote:
> On 15.09.2012 03:39, Andres Freund wrote:
> > Features:
> > - streaming reading/writing
> > - filtering
> > - reassembly of records
> >
> > Reusing the ReadRecord infrastructure in situations where the code that
> >
On 15.09.2012 03:39, Andres Freund wrote:
Features:
- streaming reading/writing
- filtering
- reassembly of records
Reusing the ReadRecord infrastructure in situations where the code that wants
to do so is not tightly integrated into xlog.c is rather hard and would require
changes to rather int
On Sunday, September 16, 2012 12:14 AM Fujii Masao wrote:
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila wrote:
> On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
> On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila
wrote:
>>
>> On Thursday, September 13, 2012 10:57 PM Fujii Masao
>> On Thu,
30 matches
Mail list logo
