From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: Monday, July 16, 2012 3:06 AM
> It might have accidentally failed to fail if tested on a compiler that
> gives a full 32 bits to enum ForkNumber, but there absolutely would be
> padding
Peter Geoghegan writes:
> On 1 June 2012 01:02, Jeff Janes wrote:
>> Sorry it has taken me a year to get back to this patch. I have wanted
>> to use it, and to ask other people to run it and report their results,
>> several time recently, so I would like to get it into the core.
> Who marked th
On 07/16/2012 09:37 AM, Tom Lane wrote:
There's one way that doesn't have any housekeeping cost to Pg. It's
pretty bad manners if there's anybody other than Pg on the system though:
sync()
Yeah, I thought about that: if we could document that issuing a manual
sync after turning fsync on leav
Craig Ringer writes:
> On 07/16/2012 02:29 AM, Tom Lane wrote:
>> Yeah, you have a point there. It's not real clear that switching fsync
>> from off to on is an operation that we can make any guarantees about,
>> short of executing something like the code recently added to initdb
>> to force-sync
On 1 June 2012 01:02, Jeff Janes wrote:
> Sorry it has taken me a year to get back to this patch. I have wanted
> to use it, and to ask other people to run it and report their results,
> several time recently, so I would like to get it into the core.
Who marked this patch as rejected in the comm
Josh Berkus writes:
>> Which three patches didn't get any review?
> Or to be more specific: I'm in favor of closing out everything which has
> had some review. I think the three patches without any review should be
> dealt with case-by-case.
Well, I might be wrong, but the ones that don't show
Marko Kreen writes:
> Now, looking at the problem with some perspective, the solution
> is obvious: when in single-row mode, the PQgetResult() must return
> proper PGresult for that single row. And everything else follows that.
> Such API is implemented in attached patch:
I'm starting to look a
On 16 July 2012 01:16, Tom Lane wrote:
> At this point we could move the open items to the September fest and
> call this one good, or we could keep trying to close things out.
> Personally I'd like to do the former, because we really need to spend
> some effort on closing out the various open iss
> Which three patches didn't get any review?
Or to be more specific: I'm in favor of closing out everything which has
had some review. I think the three patches without any review should be
dealt with case-by-case.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgs
On 07/16/2012 02:29 AM, Tom Lane wrote:
Yeah, you have a point there. It's not real clear that switching fsync
from off to on is an operation that we can make any guarantees about,
short of executing something like the code recently added to initdb
to force-sync the entire PGDATA tree.
There's
> At this point we could move the open items to the September fest and
> call this one good, or we could keep trying to close things out.
> Personally I'd like to do the former, because we really need to spend
> some effort on closing out the various open issues for 9.2, and the
> commitfest seems
We are now at the end of the originally scheduled one-month window for
the June commitfest. While the numbers look fairly bad:
Needs Review: 17, Waiting on Author: 10, Ready for Committer: 3, Committed: 29,
Returned with Feedback: 12, Rejected: 5. Total: 76.
it's not quite a complete disaster,
... btw, in the penny wise and pound foolish department, I observe that
smgrdounlink calls mdunlink separately for each possibly existing fork
of a relation to be dropped. That means we are queuing a separate fsync
queue entry for each fork, and could immediately save a factor of four
in FORGET_RE
CompactCheckpointerRequestQueue supposes that it can use an entry of the
checkpointer request queue directly as a hash table key. This will work
reliably only if there are no pad bytes in the CheckpointerRequest
struct, which means in turn that neither RelFileNodeBackend nor
RelFileNode can contai
On Fri, Jul 13, 2012 at 6:25 PM, Alvaro Herrera
wrote:
>
> Excerpts from Andrew Dunstan's message of vie jul 13 16:05:37 -0400 2012:
> > Why does the isolation check take such a long time? On some of my slower
> > buildfarm members I am thinking of disabling it because it takes so
> > long. This s
Robert Haas writes:
> On Sat, Jul 14, 2012 at 6:16 PM, Tom Lane wrote:
>> Hm. I seem to recall that at least some of these lines were themselves
>> put in to suppress compiler warnings.
> You mean things like this?
> -
> - /* keep compiler happy */
> - return NULL;
That particular cas
2012/7/12 Etsuro Fujita :
>> 2012/6/26 Kohei KaiGai :
>> > Harada-san,
>> >
>> > I checked your patch, and had an impression that includes many
>> > improvements from the previous revision that I looked at the last
>> > commit fest.
>> >
>> > However, I noticed several points to be revised, or inve
On Sat, Jul 14, 2012 at 6:16 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> A small sidetrack here. I've managed to set up the Solaris Studio
>> compiler on Linux and tried this out. It turns out these "statement not
>> reached" warnings have nothing to do with knowledge about library
>> fun
On Sun, Jul 15, 2012 at 11:49 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > On Sat, Jul 14, 2012 at 4:02 PM, Tom Lane wrote:
> >> I would like to sneak this fix into 9.2, though. Does anyone think
> >> it's already too late to be touching these APIs for 9.2?
>
> > I'd like us to stick to the
Jeff Janes writes:
> On Thu, Jul 12, 2012 at 9:55 PM, Jeff Janes wrote:
>> The topic was poor performance when truncating lots of small tables
>> repeatedly on test environments with fsync=off.
>>
>> On Thu, Jul 12, 2012 at 6:00 PM, Jeff Janes wrote:
>>> I think the problem is in the Fsync Abso
Gurjeet Singh writes:
> On Sat, Jul 14, 2012 at 4:02 PM, Tom Lane wrote:
>> I would like to sneak this fix into 9.2, though. Does anyone think
>> it's already too late to be touching these APIs for 9.2?
> I'd like us to stick to the standard practice of not changing features/API
> in beta relea
On Sat, Jul 14, 2012 at 4:02 PM, Tom Lane wrote:
>
> While I was at it, it seemed like DefineIndex's parameter list had grown
> well past any sane bound, so I refactored it to pass the IndexStmt
> struct as-is rather than passing all the fields individually.
>
> With or without that choice, thoug
Le dimanche 15 juillet 2012 07:02:01, Stephen Frost a écrit :
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Sat, Jul 14, 2012 at 09:17:22PM -0400, Stephen Frost wrote:
> > > So, can you explain which case you're specifically worried about?
> >
> > OK. The basic problem is that I
23 matches
Mail list logo
