Michael Paquier writes:
> It seems that you have forgotten pg_prewarm--unpackaged--1.0.sql when
> committing this extension. Patch attached fixes that.
Um, what's that needed for? There's no pre-extension version of this
module to worry about upgrading from. Or did I miss something?
On Fri, Dec 20, 2013 at 10:16 PM, Robert Haas wrote:
> pg_prewarm, a contrib module for prewarming relationd data.
>
> Patch by me. Review by Álvaro Herrera, Amit Kapila, Jeff Janes,
> Gurjeet Singh, and others.
>
> Branch
> --
> master
>
> Details
> ---
> http://git.postgresql.org/pg/com
On 12/24/2013 05:09 AM, Robert Haas wrote:
Yeah. The alternatives seem to be:
1. Change a lot of regression tests. This would be a serious PITA,
not so much for the one-time cost as for every time we needed to
back-patch a regression test that includes explain output. -1.
2. Don't display th
On 12/24/2013 02:31 PM, Peter Eisentraut wrote:
On 12/23/13, 8:12 PM, Andreas Karlsson wrote:
A user asked in -performance[1] if there is a way to measure the
planning time.
log_planner_stats
Thanks for the suggestion, I will use that if I need to know the plan
times. But I do not think thi
On Wed, Dec 25, 2013 at 2:36 AM, Fujii Masao wrote:
> On Tue, Dec 24, 2013 at 1:58 PM, Michael Paquier
> wrote:
>> On Sat, Dec 21, 2013 at 4:13 AM, Robert Haas wrote:
>>> On Fri, Dec 20, 2013 at 9:06 AM, Alvaro Herrera
>>> wrote:
Michael Paquier escribió:
> On Fri, Dec 20, 2013 at 1:05
On 12/24/2013 08:53 AM, Martijn van Oosterhout wrote:
(Untested). Isn't this just a case of psql not printing out a timing if
the server responds with PGRES_EMPTY_QUERY?
Yes, it is. Sorry should have made myself more clear (way more clear
when I read my messages from yesterday). Then I thought
From: "Boszormenyi Zoltan"
The app wasn't attached, only the patch.
If this is a small test app, it can also be a part of the patch in the
form of a
regression test.
Sorry, attached. Thank you for pointing it out.
Regards
MauMau
sigbus.pgc
Description: Binary data
--
Sent via pgsql-hac
On Tue, Dec 24, 2013 at 4:09 AM, Andres Freund wrote:
> I don't really see the lack of review as being crucial at this point. At
> least I have quite some doubts about the approach you've chosen and I
> have voiced it - so have others.
Apparently you haven't been keeping up with this thread. The
2013-12-24 13:55 kelteze'ssel, MauMau i'rta:
> Hello,
>
> I encountered a bug of ECPG with PG 9.2.4, which probably exists in all
> releases. The
> attached patch is for 9.4. Could you review and backport this to at least 9.2
> and later?
>
>
> [Problem]
> The attached ECPG app
The app wasn't at
Hello,
It seems to me changes in the base security policy on Fedora affected to
the regression test. Our test cases for sepgsql_setcon() utilizes the MCS
rules, that prevents domain transition from narrow categories to wider ones,
to control the success cases and failure cases.
However, its cover
I was recently annoyed that I had to do
CREATE TABLESPACE x LOCATION y;
ALTER TABLESPACE x SET (random_page_cost = z);
The attached patch is a quick n' dirty extension to allow the SET
directly on the CREATE statement.
CREATE TABLESPACE x LOCATION y SET (random_page_cost = z);
If people think t
On Tue, Dec 24, 2013 at 2:57 AM, Amit Kapila wrote:
> On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila wrote:
>> On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao wrote:
>>> I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
>>> it is here.
>>>
>>> $ psql
>>> =# ALTER SYSTEM SET shared
On Tue, Dec 24, 2013 at 1:58 PM, Michael Paquier
wrote:
> On Sat, Dec 21, 2013 at 4:13 AM, Robert Haas wrote:
>> On Fri, Dec 20, 2013 at 9:06 AM, Alvaro Herrera
>> wrote:
>>> Michael Paquier escribió:
On Fri, Dec 20, 2013 at 1:05 PM, Sawada Masahiko
wrote:
>>>
> Sorry the patch
Andres Freund writes:
>> This is inconsistent, IMO. I think if we were to fix things so that
>> leading block comments were dropped the same way -- comments are, that
>> would also take care of the behavior complained of in this thread.
>> There's been some previous discussion of this point, I th
fixed
2013/12/24 Peter Eisentraut
> Please fix this:
>
> src/bin/psql/print.c:1269: trailing whitespace.
> src/bin/psql/print.c:1351: trailing whitespace.
> src/bin/psql/print.c:1359: trailing whitespace.
> src/bin/psql/print.c:1364: trailing whitespace.
> src/bin/psql/print.c:2263: trailing wh
Hi,
On 2013-12-24 12:58:04 -0300, Alvaro Herrera wrote:
> > Shortly after this patch was committed, buildfarm member locust (running
> > Mac OS X 10.5 apparently) started failing the pg_upgrade check:
> >
> > command:
> > "/Users/pgbuildfarm/Documents/workdir/HEAD/pgsql.82393/contrib/pg_upgrade/
Alvaro Herrera wrote:
Heikki, Andres,
> Shortly after this patch was committed, buildfarm member locust (running
> Mac OS X 10.5 apparently) started failing the pg_upgrade check:
>
> command:
> "/Users/pgbuildfarm/Documents/workdir/HEAD/pgsql.82393/contrib/pg_upgrade/tmp_check/install//Users/pg
Please fix this:
src/bin/psql/print.c:1269: trailing whitespace.
src/bin/psql/print.c:1351: trailing whitespace.
src/bin/psql/print.c:1359: trailing whitespace.
src/bin/psql/print.c:1364: trailing whitespace.
src/bin/psql/print.c:2263: trailing whitespace.
--
Sent via pgsql-hackers mailing lis
On 12/22/13, 2:36 AM, Fabien COELHO wrote:
I'm not sure whether the policy is to update the version number of the
extension for such a change. As the library is always "isn.so", two
versions cannot live in parallel anyway. If it is useful, the second
patch attached also upgrade the version numb
On 12/10/13, 2:44 PM, Alexander Korotkov wrote:
> However, patch didn't apply to head. Corrected version is attached.
Update the pgstattuple regression test results.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On 12/5/13, 7:07 AM, MauMau wrote:
> From: "Tom Lane"
>> If you're going to do a postmaster_is_alive check, why bother with
>> repeated get_pgpid()?
>
> As I said yesterday, I removed get_pgpid() calls. I'll add this patch
> to 2014-1 commitfest this weekend if it is not committed until then.
T
> The real question is whether we shouldn't suppress the whole PQexec.
> I believe this is very closely related to the question of what we do
> with a comment preceding the next command. Try this experiment:
> regression=# /* block comment here */
> regression-# select 2+2;
> regression=# -- das
On 24 December 2013 12:12, Craig Ringer wrote:
> On 12/24/2013 03:21 PM, Abbas Butt wrote:
>
>> Could you please explain a little bit more how would you solve the posed
>> problem using map_variable_attnos?
>
> It actually turns out to be even simpler, and easy to do in one pass,
> when using Repl
Andres Freund writes:
> Maybe I am thinking to technical here, but why would that be a good
> idea? After all, the comment will have triggered sending a statement to
> the server and waiting for the result. The user might want to know about
> that.
I agree; if we triggered a server operation, we
On Tue, December 24, 2013 15:19, Andres Freund wrote:
> Hi,
>
> On 2013-12-24 02:05:23 +0100, Erik Rijkers wrote:
>> With \timing on, a trailing comment yields a timing.
>>
>> # test.sql
>> select 1;
>>
>> /*
>> select 2
>> */
>>
>> $ psql -f test.sql
>> ?column?
>> --
>> 1
>> (1 r
On 2013-12-23 14:15:29 -0500, Robert Haas wrote:
> On Mon, Dec 23, 2013 at 1:57 PM, Andres Freund wrote:
> > Well, all of the fundamental changes (combocids, the initial multixact
> > introduction) have been quite some time ago. I think backward compat has
> > a much higher value these days (I als
Hi,
On 2013-12-24 02:05:23 +0100, Erik Rijkers wrote:
> With \timing on, a trailing comment yields a timing.
>
> # test.sql
> select 1;
>
> /*
> select 2
> */
>
> $ psql -f test.sql
> ?column?
> --
> 1
> (1 row)
>
> Time: 0.651 ms
> Time: 0.089 ms
>
> I assume it is timing so
On 2013-12-23 15:04:08 -0500, Robert Haas wrote:
> On Thu, Dec 5, 2013 at 6:39 AM, Andres Freund wrote:
> > On 2013-11-19 10:37:35 -0500, Tom Lane wrote:
> >> Or does the warning
> >> mean code bloat (lots of useless copies of the inline function)?
> >
> > After thinking on that for a bit, yes tha
On 12/22/13, 2:36 AM, Fabien COELHO wrote:
> I'm not sure whether the policy is to update the version number of the
> extension for such a change. As the library is always "isn.so", two
> versions cannot live in parallel anyway. If it is useful, the second
> patch attached also upgrade the version
On 12/24/13, 5:40 AM, Fabrízio de Royes Mello wrote:
>> (Untested). Isn't this just a case of psql not printing out a timing if
>> the server responds with PGRES_EMPTY_QUERY?
>>
>
> Works... look to the attached patch!
That looks reasonable.
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On 12/24/13, 1:33 AM, Etsuro Fujita wrote:
> This is a small patch to fix a typo in src/backend/utils/mmgr/README.
I don't think that change is correct.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On 12/23/13, 8:12 PM, Andreas Karlsson wrote:
> A user asked in -performance[1] if there is a way to measure the
> planning time.
log_planner_stats
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
Hello,
I encountered a bug of ECPG with PG 9.2.4, which probably exists in all
releases. The attached patch is for 9.4. Could you review and backport
this to at least 9.2 and later?
[Problem]
The attached ECPG app crashes and dumps core with SIGBUS on Solaris for
SPARC. I used Solaris 10
On 2013-12-23 18:28:51 +0100, Magnus Hagander wrote:
> On Dec 19, 2013 12:06 AM, "Andres Freund" wrote:
> >
> > Hi Magnus,
> >
> > It looks to me like the path to do_pg_start_backup() outside of a
> > transaction context comes from your initial commit of the base backup
> > facility.
> > The probl
On 12/24/2013 03:21 PM, Abbas Butt wrote:
> Could you please explain a little bit more how would you solve the posed
> problem using map_variable_attnos?
It actually turns out to be even simpler, and easy to do in one pass,
when using ReplaceVarsFromTargetList .
You just generate a temporary new
On 2013-12-23 14:59:31 -0800, Peter Geoghegan wrote:
> On Mon, Dec 23, 2013 at 7:49 AM, Robert Haas wrote:
> > I don't think this is a project to rush through. We've lived without
> > MERGE/UPSERT for several years now, and we can live without it for
> > another release cycle while we try to reac
Sent from my iPad
> On 24-Dec-2013, at 2:50, Tom Lane wrote:
>
> Atri Sharma writes:
>> Please find attached the latest patch for WITHIN GROUP. This patch is
>> after fixing the merge conflicts.
>
> I've committed this after significant editorialization --- most notably,
> I pushed control o
On 12/24/2013 03:21 PM, Abbas Butt wrote:
> Could you please explain a little bit more how would you solve the posed
> problem using map_variable_attnos?
>
> I was recently working on a similar problem and used the following algo
> to solve it.
>
> I had to find to which column of the base table
On Tue, Dec 24, 2013 at 5:53 AM, Martijn van Oosterhout
wrote:
>
> On Tue, Dec 24, 2013 at 03:40:58AM +0100, Andreas Karlsson wrote:
> > On 12/24/2013 03:17 AM, David Johnston wrote:
> > It is not sent to the server as a trailing comment. The following
> > file is sent to the server like this.
> >
39 matches
Mail list logo
