On Thu, Sep 03, 2015 at 04:21:55PM -0400, Robert Haas wrote:
> On Sat, Aug 22, 2015 at 2:23 AM, Noah Misch wrote:
> >> > Can you get away with only looking at tuples though? For example,
> >> > what about advisory locks? Table locks?
> >>
> >> Well, that's an interesting question. Can we get aw
> Pushed. I'm not too sure about the expected outputs for python other
> than 2.6, nor for sepgsql, but hopefully the buildfarm will provide
> feedback.
>
>
Thank you very much
Pavel
Noah Misch writes:
> On Sat, Sep 05, 2015 at 10:22:59PM -0400, Tom Lane wrote:
>> The kill() coding works on Windows (I believe); waitpid() not so much.
> Windows has the concept under a different name. See postmaster.c.
Well, if someone else wants to code and test that, feel free. I don't
do
On Sat, Sep 05, 2015 at 10:22:59PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > kill() adds nothing when dealing with a pg_ctl child. waitpid() is enough.
>
> The kill() coding works on Windows (I believe); waitpid() not so much.
Windows has the concept under a different name. See postmaste
Noah Misch writes:
> kill() adds nothing when dealing with a pg_ctl child. waitpid() is enough.
The kill() coding works on Windows (I believe); waitpid() not so much.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Thanks for the solution.
On Wed, Sep 2, 2015 at 4:15 PM, Bruce Momjian wrote:
> On Wed, Sep 2, 2015 at 04:50:32PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > On Fri, Aug 28, 2015 at 10:34:38PM -0700, AI Rumman wrote:
> >
> > > > In pg_upgrade, how about adding a feature to copy
On Sun, Jul 26, 2015 at 11:15 PM, Peter Geoghegan wrote:
> The SQLite people have been using a tool like this for some time.
> They've also had luck finding bugs with a generic fuzz-testing tool
> called "american fuzzy lop" (yes, seriously, that's what it's called),
> which apparently is the stat
On Fri, Sep 04, 2015 at 10:54:51PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Sep 03, 2015 at 03:31:06PM -0400, Tom Lane wrote:
> >>> This is the first time I've seen an indication that the
> >>> start_postmaster change mentioned in the comment is actually important
> >>> for producti
On Sun, Sep 6, 2015 at 5:11 AM, Julien Rouhaud
wrote:
> I just noticed that part of storage.sgml was not updated when 9.3
> introduced checksum (and removed pd_tli from PageHeaderData).
>
Yep, see that as well:
http://www.postgresql.org/message-id/cab7npqsv1kr6fqwf2rovter5cxaw8oth+dkzjwp4meji5do
Greg Stark writes:
> But that said, here's a tricksy patch that triggers an assertion
> failure if the expected_lines is wrong. I intended it to trigger in
> the regression tests so it only checks if the pager is actually off.
> It wouldn't be hard to make it always check though.
Hmm ... that wou
Hi,
I just noticed that part of storage.sgml was not updated when 9.3
introduced checksum (and removed pd_tli from PageHeaderData).
Here's a simple patch to fix that.
Regards.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.s
YUriy Zhuravlev writes:
> During my work on CMake I stumbled upon this simple bug. I think this is
> important for mingw users.
> The function is trying to return a variable that has not been announced.
> Patch in attach. Probably relevant for stable releases.
Will commit, thanks!
Hi Pavel,
On Sat, Sep 5, 2015 at 12:36 AM, Pavel Stehule
wrote:
>
>
> 2015-09-05 8:35 GMT+02:00 dinesh kumar :
>
>>
>>
>> On Fri, Sep 4, 2015 at 2:03 PM, Pavel Stehule
>> wrote:
>>
>>>
>>>
>>> 2015-09-02 21:49 GMT+02:00 dinesh kumar :
>>>
On Mon, Aug 31, 2015 at 10:08 PM, Pavel Stehule <
>
On Fri, Aug 28, 2015 at 05:33:34PM +0900, Kyotaro HORIGUCHI wrote:
> Hello, this patch enables planner to be couscious of inter-column
> correlation.
>
> Sometimes two or more columns in a table has some correlation
> which brings underestimate, which leads to wrong join method and
> ends with slo
Hello hackers.
During my work on CMake I stumbled upon this simple bug. I think this is
important for mingw users.
The function is trying to return a variable that has not been announced.
Patch in attach. Probably relevant for stable releases.
Thanks!
--
YUriy Zhuravlev
Postgres Professional:
On Fri, Sep 4, 2015 at 11:21 AM, Greg Stark wrote:
> On Thu, Sep 3, 2015 at 2:13 PM, Merlin Moncure wrote:
>> I find this talk of platters and spindles to be somewhat
>> baroque; for a 200$ part I have to work pretty hard to max out the
>> drive when reading and I'm still not completely sure if
On Sat, Sep 5, 2015 at 5:55 PM, Tom Lane wrote:
> Ordinarily I might think that was overkill, but given the number of times
> that we've failed to update those counts in the past, I think this is
> definitely a worthwhile investment in maintainability.
So to preface this, this was just a silly ha
Hi,
On 09/05/2015 10:53 AM, Simon Riggs wrote:
On 4 September 2015 at 22:03, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
A summary of 100 EXPLAIN timings looks like this:
master A B C D E F
--
I wrote:
> BTW, I noticed that the PageOutput line counts for psql's usage(),
> slashUsage(), and helpVariables() were all three wrong, which I'm afraid
> has been their usual state in the past too. Since commit 07c8651dd91d5aea
> there's been a pretty easy way to check them, which I added comment
On 09/05/2015 09:05 AM, Tom Lane wrote:
> I wrote:
>> If there are not major objections, I'll work on cleaning up and
>> committing the patch.
>
> Pushed. I'm not too sure about the expected outputs for python other
> than 2.6, nor for sepgsql, but hopefully the buildfarm will provide
> feedback.
I wrote:
> If there are not major objections, I'll work on cleaning up and
> committing the patch.
Pushed. I'm not too sure about the expected outputs for python other
than 2.6, nor for sepgsql, but hopefully the buildfarm will provide
feedback.
BTW, I noticed that the PageOutput line counts for
Michael Paquier writes:
> On Sat, Sep 5, 2015 at 3:41 PM, Jim Nasby wrote:
>> I was about to test this and was verifying that the crash still worked
>> when I noticed this in the logs (9.4.1, not HEAD). Not sure if there's any
>> realion here or not...
>>
>> WARNING: relation "pg_proc" page 121
On Fri, Sep 4, 2015 at 09:40:10AM +0900, Michael Paquier wrote:
> Robert Haas wrote:
> > On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera
> > wrote:
> > > FabrÃzio de Royes Mello wrote:
> > >
> > >> Why this patch was reverted one day after applied [1]? I didn't see
> a
On 2015-09-02 16:14, Fujii Masao wrote:
On Wed, Aug 5, 2015 at 2:16 AM, Robert Haas wrote:
On Mon, Aug 3, 2015 at 10:31 AM, Fujii Masao wrote:
track_commit_timestamp tracks COMMIT PREPARED as expected in standby server,
but not in master server. Is this intentional? It should track COMMIT PRE
Hello hackers!This patch contains LWLocks changes from pg_stat_activity thread(http://www.postgresql.org/message-id/flat/ca+tgmoyd3gtz2_mjfuhf+rpe-bcy75ytjekvv9x-o+soncg...@mail.gmail.com/)and I think it deserves a separate thread.The goal is to split LWLocks from one array to logical pieces (with
On 09/05/2015 10:16 AM, Oskari Saarenmaa wrote:
Attached a patch to fix a number of typos in docs and comments I noticed
over the past few weeks.
Thanks, applied!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On 4 September 2015 at 22:03, Tomas Vondra
wrote:
> A summary of 100 EXPLAIN timings looks like this:
>
>
> master A B C D E F
> -
> min0.10 0.10 0.30
2015-09-05 8:35 GMT+02:00 dinesh kumar :
>
>
> On Fri, Sep 4, 2015 at 2:03 PM, Pavel Stehule
> wrote:
>
>>
>>
>> 2015-09-02 21:49 GMT+02:00 dinesh kumar :
>>
>>> On Mon, Aug 31, 2015 at 10:08 PM, Pavel Stehule >> > wrote:
>>>
2015-09-01 6:59 GMT+02:00 Pavel Stehule :
>
>>>
Attached a patch to fix a number of typos in docs and comments I noticed
over the past few weeks.
/ Oskari
>From dd5cb727d7fc1f1168040f502521a897d01cc127 Mon Sep 17 00:00:00 2001
From: Oskari Saarenmaa
Date: Sat, 5 Sep 2015 10:12:04 +0300
Subject: [PATCH] typofixes
---
contrib/btree_gist/btr
On Sat, Sep 5, 2015 at 3:41 PM, Jim Nasby wrote:
> I was about to test this and was verifying that the crash still worked
> when I noticed this in the logs (9.4.1, not HEAD). Not sure if there's any
> realion here or not...
>
> WARNING: relation "pg_proc" page 121 is uninitialized --- fixing
> W
30 matches
Mail list logo
