On Tue, Dec 24, 2013 at 5:53 AM, Martijn van Oosterhout klep...@svana.org
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
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 does
Sent from my iPad
On 24-Dec-2013, at 2:50, Tom Lane t...@sss.pgh.pa.us wrote:
Atri Sharma atri.j...@gmail.com 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
On 2013-12-23 14:59:31 -0800, Peter Geoghegan wrote:
On Mon, Dec 23, 2013 at 7:49 AM, Robert Haas robertmh...@gmail.com 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
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 18:28:51 +0100, Magnus Hagander wrote:
On Dec 19, 2013 12:06 AM, Andres Freund and...@2ndquadrant.com 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
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
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:
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:
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
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 2013-12-23 15:04:08 -0500, Robert Haas wrote:
On Thu, Dec 5, 2013 at 6:39 AM, Andres Freund and...@2ndquadrant.com 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
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 something about that
On 2013-12-23 14:15:29 -0500, Robert Haas wrote:
On Mon, Dec 23, 2013 at 1:57 PM, Andres Freund and...@2ndquadrant.com 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
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 row)
Time: 0.651 ms
Time:
Andres Freund and...@2ndquadrant.com 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
On 24 December 2013 12:12, Craig Ringer cr...@2ndquadrant.com 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,
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=# -- dash
On 12/5/13, 7:07 AM, MauMau wrote:
From: Tom Lane t...@sss.pgh.pa.us
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
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:
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
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
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:
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:
fixed
2013/12/24 Peter Eisentraut pete...@gmx.net
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:
Andres Freund and...@2ndquadrant.com 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
On Tue, Dec 24, 2013 at 1:58 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Dec 21, 2013 at 4:13 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 20, 2013 at 9:06 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier escribió:
On Fri, Dec 20, 2013 at 1:05
On Tue, Dec 24, 2013 at 2:57 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sun, Dec 22, 2013 at 8:32 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sun, Dec 22, 2013 at 3:01 PM, Fujii Masao masao.fu...@gmail.com wrote:
I found the bug of ALTER SYSTEM SET patch. The procedure to reproduce
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
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
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 attached,
On Tue, Dec 24, 2013 at 4:09 AM, Andres Freund and...@2ndquadrant.com 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
From: Boszormenyi Zoltan z...@cybertec.at
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
--
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
On Wed, Dec 25, 2013 at 2:36 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Dec 24, 2013 at 1:58 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Sat, Dec 21, 2013 at 4:13 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 20, 2013 at 9:06 AM, Alvaro Herrera
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
On Fri, Dec 20, 2013 at 10:16 PM, Robert Haas rh...@postgresql.org 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
---
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
Michael Paquier michael.paqu...@gmail.com 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
39 matches
Mail list logo
