On tor, 2011-06-09 at 00:14 -0400, Greg Smith wrote:
> Following up on the idea we've been exploring for making some
> extensions
> more prominent, attached is the first rev that I think may be worth
> considering seriously. Main improvement from the last is that I
> reorganized the docs to bre
On Jun 9, 2011, at 11:29 AM, Robert Haas wrote:
> On Thu, Jun 9, 2011 at 11:54 AM, Bruce Momjian wrote:
>> Can someone explain why pg_stat_activity has a column named procpid and
>> not simply pid? 'pid' is that pg_locks uses, and 'procpid' is redundant
>> (proc-process-id). A mistake?
>
> Well
On Jun 9, 2011, at 9:28 AM, Robert Haas wrote:
> On Thu, Jun 9, 2011 at 10:22 AM, Alvaro Herrera
> wrote:
>>> 1. Subdivide XLOG insertion into three operations: (1) allocate space
>>> in the log buffer, (2) copy the log records into the allocated space,
>>> and (3) release the space to the buffer
On Fri, Jun 10, 2011 at 09:43:58PM +0300, Heikki Linnakangas wrote:
> > Do checks such as that argue for keeping the volatile flag, or do
> > you think we can drop it if we make those changes? (That would also
> > allow dropping a number of casts which exist just to avoid
> > warnings.)
>
> I bel
On Fri, Jun 10, 2011 at 14:24, Tom Lane wrote:
> Alex Hunsaker writes:
>> Hrm, Couldn't we change all the references to tmpRecPtr to use RecPtr
>> instead? (Except of course where we assign RecPtr = &tmpRecPtr); I
>> think that would make the code look a lot less confused. Something
>> like the
Alex Hunsaker writes:
> On Fri, Jun 10, 2011 at 12:38, Tom Lane wrote:
>> I think we need a workaround.
My second idea about moving the test up doesn't work, because we can't
know the page header size until after we've read the page. But I've
verified that the attached patch does make the probl
On Fri, Jun 10, 2011 at 12:38, Tom Lane wrote:
>
> I've been able to reproduce this on released Fedora 15, and sure enough
> it is a compiler bug. The problem comes from these fragments of
> ReadRecord():
> [ ... ]
Whoa, awesome. I spent a few more hours comparing the assembly-- then
I tried com
On 6/10/11 12:34 PM, Robert Haas wrote:
> On Fri, Jun 10, 2011 at 2:53 PM, Josh Berkus wrote:
>>> Let's imagine we're taking filesystem snapshots each day by whatever
>>> means. We're also archiving xlogs, but only have space for 48 hours'
>>> worth. Now we want to recover to 3 days ago, but the
On 10.06.2011 22:34, Robert Haas wrote:
On Fri, Jun 10, 2011 at 2:53 PM, Josh Berkus wrote:
Let's imagine we're taking filesystem snapshots each day by whatever
means. We're also archiving xlogs, but only have space for 48 hours'
worth. Now we want to recover to 3 days ago, but there are no W
On Fri, Jun 10, 2011 at 2:53 PM, Josh Berkus wrote:
>> Let's imagine we're taking filesystem snapshots each day by whatever
>> means. We're also archiving xlogs, but only have space for 48 hours'
>> worth. Now we want to recover to 3 days ago, but there are no WALs
>> from that time, so we do a
Magnus Hagander writes:
> I came across a situation today with a pretty bad crash of pg_dump,
> due to not checking the return code from malloc(). When looking
> through the code, it seems there are a *lot* of places in pg_dump that
> doesn't check the malloc return code.
> But we do have a pg_ma
David,
> Let's imagine we're taking filesystem snapshots each day by whatever
> means. We're also archiving xlogs, but only have space for 48 hours'
> worth. Now we want to recover to 3 days ago, but there are no WALs
> from that time, so we do a crash recovery from the filesystem
> snapshot. D
Marti Raudsepp writes:
> On Fri, Jun 10, 2011 at 17:20, Tom Lane wrote:
>> I put this right about on par with the occasional suggestions that we
>> implement our own filesystem.
> I am worried that legitimate calculations can bring the database into
> a state where a backup succeeds, but is no l
David,
> Let's imagine we're taking filesystem snapshots each day by whatever
> means. We're also archiving xlogs, but only have space for 48 hours'
> worth. Now we want to recover to 3 days ago, but there are no WALs
> from that time, so we do a crash recovery from the filesystem
> snapshot. D
On 10.06.2011 18:05, Kevin Grittner wrote:
Heikki Linnakangas wrote:
o There is no safeguard against actually wrapping around the
SLRU, just the warning
Any thoughts on what we should do instead? If someone holds open a
transaction long enough to burn through a billion transaction
Mark Kirkwood writes:
> On 09/06/11 06:58, Alex Hunsaker wrote:
>> Yeah :-). However ill note it looks like its the default compiler for
>> fedora 15, ubuntu natty and debian sid.
> FWIW Ubuntu natty uses gcc 4.5.2, probably just as as well in the light
> of your findings :-)
I've been able to
I came across a situation today with a pretty bad crash of pg_dump,
due to not checking the return code from malloc(). When looking
through the code, it seems there are a *lot* of places in pg_dump that
doesn't check the malloc return code.
But we do have a pg_malloc() function in there - but from
Florian Pflug wrote:
> Here is review of the patch.
Thanks for the review. I think I'd better try to keep the decks
clear for dealing with any SSI issues which may surface during the
coming month, so I'm going to mark this patch "Returned with
Feedback" and look at this for possible resubmiss
On Mon, May 23, 2011 at 6:54 PM, Alexander Korotkov
wrote:
> Second version of patch attached. Main changes:
> 1) ANY and ALL keywords handling.
> 2) Collecting statistics of array length. It is used in "column <@ const".
> 3) Relatively accurate estimation of "column <@ const" selectivity. This
Alexey,
On Fri, Jun 10, 2011 at 05:46:42PM +0300, Alexey Klyukin wrote:
> Providing my thoughts on the 'mundane' question first.
I was actually referring to this paragraph:
The standing code handled index/constraint dependencies of changing columns by
extracting the SQL definition using pg_g
On Fri, Jun 10, 2011 at 17:20, Tom Lane wrote:
> I put this right about on par with the occasional suggestions that we
> implement our own filesystem. It's not our core competency and in the
> end there is no value-add. If you need to work with denormals, find
> a platform that supports them bet
On Fri, Jun 10, 2011 at 01:20:25AM -0400, Robert Haas wrote:
> On Thu, Jun 9, 2011 at 8:59 PM, Tom Lane wrote:
> > David Fetter writes:
> >> The nice people at VMware, where I work, have come up with a small
> >> patch to allow PITR to create a new timeline. This is useful in cases
> >> where yo
"Kevin Grittner" wrote:
> I am in full agreement with this patch.
I found that pgindent would like to tweak whitespace in three places
in that patch, and I found an unnecessary include that I would like
to remove. Normally, I would post a new version of the patch with
those adjustments, but t
On 06/10/2011 11:26 AM, Alex Hunsaker wrote:
On Fri, Jun 10, 2011 at 00:53, Greg Smith wrote:
4) Use a system with git>=1.7.0, which adds:
git branch --set-upstream REL9_1_STABLE origin/REL9_1_STABLE
But wait! there's more!
5) delete your local branch and recreate it after you push the br
On Fri, Jun 10, 2011 at 00:53, Greg Smith wrote:
> On 06/10/2011 12:19 AM, Alex Hunsaker wrote:
>>
>> It looks like if you push the remote branch first everything should work
>> nicely:
>> git checkout master
>> git push origin origin:refs/heads/REL9_1_STABLE
>> git fetch # fetch the new branch
>>
Heikki Linnakangas wrote:
> Here's a bunch of small issues that I spotted:
Thanks for going over it again. It is encouraging that you didn't
spot any *big* issues.
> * The oldserxid code is broken for non-default BLCKSZ.
>o The warning will come either too early or too late
Good point
Noah,
Providing my thoughts on the 'mundane' question first.
On Tue, May 24, 2011 at 1:40 PM, Noah Misch wrote:
>
> I also had a more mundane design question in the second paragraph of [2]. It
> can probably wait for the review of the next version of the patch. However,
> given that it affects
Marti Raudsepp writes:
> Looking at utils/adt/float.c, seems that some platforms also have
> other problems with the strtod() function. Maybe it's time to
> implement our own, without bugs and with proper handling for denormal
> float values?
I put this right about on par with the occasional sugg
On 10.06.2011 13:06, Grzegorz Szpetkowski wrote:
What do you think about adding new postgresql.conf property, let's
briefly say standard_quoting_identifiers with default value off to
maintain backward compatibility, which allows to use standard
upper-case equivalents (so Foo and "FOO" will be the
On Fri, Jun 10, 2011 at 12:40 AM, Tom Lane wrote:
> Joe Abbate writes:
> > No, it doesn't trash anything. The branch is just an additional
> > "pointer" to 'master' (at that point in time). I recommend taking a
> > look at this:
>
> > http://progit.org/book/ch3-5.html
>
> Yes, I was reading ex
Hi,
Greg Smith writes:
> Following up on the idea we've been exploring for making some extensions
> more prominent, attached is the first rev that I think may be worth
> considering seriously. Main improvement from the last is that I reorganized
> the docs to break out what I decided to tentativ
It makes wonders to take a couple of months break from looking at a
piece of code, and then review it in detail again. It's like a whole new
pair of eyes :-).
Here's a bunch of small issues that I spotted:
* The oldserxid code is broken for non-default BLCKSZ.
o The warning will come either
2011/2/24 Andrew Tipton :
> While playing around with the BOX and POINT datatypes, I was surprised to
> note that BOX @> POINT (and likewise POINT <@ BOX) queries were not using
> the GiST index I had created on the BOX column. The attached patch adds a
> new strategy @>(BOX,POINT) to the box_ops
Forgive me if there was already some discussion about it (I can't find
anyone). As documentation describes
(http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html):
"Quoting an identifier also makes it case-sensitive, whereas unquoted
names are always folded to lower case. For example,
Hi list,
I was playing around with denormal float values in response to the
Itanium thread and noticed that Postgres' float conversion functions
behave inconsistently, at least on Linux with glibc 2.14
It can successfully convert denormal float values to strings:
marti=# select '0.25e-307'::float
On Jan29, 2011, at 00:15 , Kevin Grittner wrote:
> The people who write my paychecks have insisted on me chunking out
> some items which are part of our long-term plan besides the one I've
> been focusing on lately. Most of it isn't of interest to anyone
> outside Wisconsin Courts, but this piece
36 matches
Mail list logo
