On Tue, Aug 23, 2011 at 5:25 AM, Robert Haas wrote:
> I've been giving this quite a bit more thought, and have decided to
> abandon the scheme described above, at least for now. It has the
> advantage of avoiding virtually all locking, but it's extremely
> inefficient in its use of memory in the
On Fri, Aug 26, 2011 at 10:46:33AM +0200, Tomas Vondra wrote:
> Hmmm, let me explain what led me to this patch - right now I'm doing a
> comparison of filesystems with various block sizes (both fs and db
> blocks). I've realized that the db block size significantly influences
> frequency of checkpo
On Thu, Aug 25, 2011 at 6:29 PM, Jim Nasby wrote:
> Actually, I wasn't thinking about the system dynamically sizing shared memory
> on it's own... I was only thinking of providing the ability for a user to
> change something like shared_buffers and allow that change to take effect
> with a SIGH
On Thu, Aug 25, 2011 at 6:24 PM, Jim Nasby wrote:
> On Aug 25, 2011, at 8:24 AM, Robert Haas wrote:
>> My hope (and it might turn out that I'm an optimist) is that even with
>> a reasonably small buffer it will be very rare for a backend to
>> experience a wraparound condition. For example, consi
On Fri, Aug 26, 2011 at 12:08 AM, Josh Kupershmidt wrote:
> I noticed a few places where it would be handy if dropdb took a flag
> like "--if-exists" which would basically just add in the 'IF EXISTS'
> clause to the DROP DATABASE statement. For example, scripts like
> find_static or mbregress.sh u
On Fri, Aug 26, 2011 at 4:32 PM, Jim Nasby wrote:
> On Aug 25, 2011, at 5:08 AM, Dean Rasheed wrote:
>>> Funny you should mention intervals...
>>>
>>> timestamptz 'today' - interval '5 days'
>>> timestamptz 'now' + interval '2 hours'
>>>
>>
>> Yes, but what I am trying to achieve is a way of enter
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie ago 26 01:35:45 -0300 2011:
> > It has been years since I ran src/tools/pginclude/pgrminclude to remove
> > unnecessary include files. (I have already fixed things so include
> > files can be compiled on their own.)
> >
> > The
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > It has been years since I ran src/tools/pginclude/pgrminclude to remove
> > > unnecessary include files. (I have already fixed things so include
> > > files can be compiled on their own.)
> >
> > > The attached patch removes
Daniel Farina writes:
> Some Postgres servers will error out for a while with the following
> error message:
> "expected authentication request from server, but received c"
> [ and this seems to be triggered by fork failures in the server ]
Fascinating.
I poked at this for awhile by the expedien
Excerpts from Bruce Momjian's message of vie ago 26 01:35:45 -0300 2011:
> It has been years since I ran src/tools/pginclude/pgrminclude to remove
> unnecessary include files. (I have already fixed things so include
> files can be compiled on their own.)
>
> The attached patch removes unneeded in
On 08/26/2011 04:46 PM, Jim Nasby wrote:
On Aug 26, 2011, at 12:15 PM, Andrew Dunstan wrote:
I knew there would be some bike-shedding about how we specify these things,
which is why I haven't written docs yet.
While we're debating what shade of yellow to paint the shed...
My actual use case
Alvaro Herrera writes:
> The "--section=data --section=indexes" proposal seems very reasonable to
> me -- more so than "--sections='data indexes'".
+1 ... not only easier to code and less squishily defined, but more like
the existing precedent for other pg_dump switches, such as --table.
jes...@krogh.cc writes:
>> Attached SQL files gives (at least in my hands) a reliable backend crash
>> with this stacktrace .. reproduced on both 9.0.4 and HEAD. I'm sorry
>> I cannot provide a more trimmed down set of vectors the reproduces the
>> bug, thus
>> the "obsfucated" dataset. But even de
Hello list,
This is something that I've only recently somewhat pinned down to a cause...
Some Postgres servers will error out for a while with the following
error message:
"expected authentication request from server, but received c"
If one uses Their Favorite Search Engine, this message is sca
On Aug 26, 2011, at 12:15 PM, Andrew Dunstan wrote:
> I knew there would be some bike-shedding about how we specify these things,
> which is why I haven't written docs yet.
While we're debating what shade of yellow to paint the shed...
My actual use case is to be able to be able to "inject" SQL
On Aug 25, 2011, at 5:08 AM, Dean Rasheed wrote:
>> Funny you should mention intervals...
>>
>> timestamptz 'today' - interval '5 days'
>> timestamptz 'now' + interval '2 hours'
>>
>
> Yes, but what I am trying to achieve is a way of entering such
> relative timestamps using a single input value
Excerpts from Robert Haas's message of vie ago 26 15:36:36 -0300 2011:
> On Fri, Aug 26, 2011 at 1:15 PM, Andrew Dunstan wrote:
> > I don't have anything in principle against your '--sections="foo bar"'
> > suggestion, but it would be more work to program. Simpler, and probably more
> > consistent
On Fri, Aug 26, 2011 at 1:15 PM, Andrew Dunstan wrote:
> I don't have anything in principle against your '--sections="foo bar"'
> suggestion, but it would be more work to program. Simpler, and probably more
> consistent with how we do other things, would be allowing multiple --section
> options, i
On 26 Srpen 2011, 19:17, Greg Smith wrote:
> On 08/26/2011 03:54 AM, Magnus Hagander wrote:
>> In theory, this could be the "progress view" or
>> "progress field" talked about around Gregs previous patch - or it
>> could just be modifying the commandstring in pg_stat_activity.
>
> Right. The whole
On 26 Srpen 2011, 9:54, Magnus Hagander wrote:
> This seems like the wrong thing to write to the log. It's really only
> useful *during* the checkpoint run, isn't it? If so, I think it should
> go in a pg_stat view. In theory, this could be the "progress view" or
> "progress field" talked about aro
On 08/26/2011 03:54 AM, Magnus Hagander wrote:
In theory, this could be the "progress view" or
"progress field" talked about around Gregs previous patch - or it
could just be modifying the commandstring in pg_stat_activity.
Right. The whole progress indicator idea is hard to do for queries in
On 08/26/2011 12:46 PM, Robert Haas wrote:
On Fri, Aug 26, 2011 at 11:22 AM, Andrew Dunstan wrote:
But we could also add these switches to pg_dump too if people feel it's
worthwhile. I haven't looked but the logic should not be terribly hard.
Something like the attached, in fact, which seems
On Fri, 2011-08-26 at 12:46 -0400, Robert Haas wrote:
> --sections='predata data'
> --sections='postdata'
> --sections='index'
Agreed. After command line options reach a certain level of complexity,
I think it's worth looking for a more general way to express them.
Regards,
Jeff Davis
-
On Fri, Aug 26, 2011 at 11:22 AM, Andrew Dunstan wrote:
>> But we could also add these switches to pg_dump too if people feel it's
>> worthwhile. I haven't looked but the logic should not be terribly hard.
>
> Something like the attached, in fact, which seems pretty simple.
It seems like there ar
On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
>
> OK, this was very helpful. I found out that there is a bug in current
> 9.0.X, 9.1.X, and HEAD that I introduced recently when I excluded temp
> tables. (The bug is not in any released version of pg_upgrade.) The
> attached, app
On 08/25/2011 06:15 PM, Andrew Dunstan wrote:
But we could also add these switches to pg_dump too if people feel
it's worthwhile. I haven't looked but the logic should not be terribly
hard.
Something like the attached, in fact, which seems pretty simple.
cheers
andrew
diff --git a
On Fri, Aug 26, 2011 at 3:09 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 08/26/2011 07:27 AM, Albe Laurenz wrote:
>>> http://oracle-fdw.projects.postgresql.org/
>>>
>>> Would it make sense to mention that in chapter 5.10
>>> of the documentation?
>
>> I don't think so, any more than any ot
On Thu, Aug 25, 2011 at 10:53 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
>
>> In the tests on the first version of patch I found index quality of
>> regular
>> build much better than it of buffering build (without neighborrelocation).
>> Now it's similar, though it's beca
On Thu, Aug 25, 2011 at 11:08 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Could you share the test scripts, patches and data sets etc. needed to
> reproduce the tests you've been running? I'd like to try them out on a test
> server.
>
1) I've updated links to the datase
Andrew Dunstan writes:
> On 08/26/2011 07:27 AM, Albe Laurenz wrote:
>> http://oracle-fdw.projects.postgresql.org/
>>
>> Would it make sense to mention that in chapter 5.10
>> of the documentation?
> I don't think so, any more than any other external module should be
> mentioned in the docs. Th
On 08/26/2011 07:27 AM, Albe Laurenz wrote:
I wrote:
I wrote a FDW for Oracle to a) learn some server coding
and b) see how well the FDW API works for me.
I have released the software on PgFoundry:
http://oracle-fdw.projects.postgresql.org/
Would it make sense to mention that in chapter 5.10
Jesper Krogh writes:
> On 2011-08-26 05:28, Tom Lane wrote:
>> Hm ... I can reproduce this on one of my usual machines, but not
>> another. What platform are you on exactly?
> 64 bit Ubuntu Lucid (amd64).
Huh, weird ... because the platform it's not failing for me on is
Fedora 14 x86_64. Which
Tom Lane wrote:
> Bruce Momjian writes:
> > It has been years since I ran src/tools/pginclude/pgrminclude to remove
> > unnecessary include files. (I have already fixed things so include
> > files can be compiled on their own.)
>
> > The attached patch removes unneeded include references, and ma
I wrote:
> I wrote a FDW for Oracle to a) learn some server coding
> and b) see how well the FDW API works for me.
I have released the software on PgFoundry:
http://oracle-fdw.projects.postgresql.org/
Would it make sense to mention that in chapter 5.10
of the documentation?
Yours,
Laurenz Albe
> Hi
>
> Attached SQL files gives (at least in my hands) a reliable backend crash
> with this stacktrace .. reproduced on both 9.0.4 and HEAD. I'm sorry
> I cannot provide a more trimmed down set of vectors the reproduces the
> bug, thus
> the "obsfucated" dataset. But even deleting single terms in
Robert, Thanks for your reviewing.
> For me, the line you removed from dml.out causes the regression tests to fail.
>
Fixed. Why did I removed this line??
> I don't understand what this is going for:
>
> + /*
> + * To boost up trusted procedure checks on db_procedure object
> +
On 26 Srpen 2011, 9:35, Greg Smith wrote:
> On 08/25/2011 04:57 PM, Tomas Vondra wrote:
>> (b) sends bgwriter stats (so that the buffers_checkpoint is updated)
>>
> As for throwing more log data out, I'm not sure what new analysis you're
> thinking of that it allows. I/O gets increasingly spiky as
On Thu, Aug 25, 2011 at 22:57, Tomas Vondra wrote:
> Hello,
>
> I'd like to propose a small patch that allows better checkpoint progress
> monitoring. The patch is quite simple - it adds a new integer GUC
> "checkpoint_update_limit" and every time checkpoint writes this number of
> buffers, it doe
On 08/25/2011 04:57 PM, Tomas Vondra wrote:
(b) sends bgwriter stats (so that the buffers_checkpoint is updated)
The idea behind only updating the stats in one chunk, at the end, is
that it makes one specific thing easier to do. Let's say you're running
a monitoring system that is grabbi
39 matches
Mail list logo
