Hi, hackersI was exporting my project to a patch file. As the patch review
requires, the patch needs to be in context diff format
(http://wiki.postgresql.org/wiki/Reviewing_a_Patch). But the git diff exports
in a format similar to unified format. What is everyone doing with patching
now?
Having statistics on ranges was really missing! The planner was doing
some really, really bad choices on bigger tables regarding seq/random
scans, nested loop/other joins etc.
Is there any chance this makes it into 9.2 final? It would really
round-off the introduction of range types and maybe
On 8 August 2012 03:44, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Aug 7, 2012 at 1:52 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 7 August 2012 20:58, Jeff Janes jeff.ja...@gmail.com wrote:
Hi Heikki,
Is the bulk index insert still an active area for you?
If not, is there some kind
Hello PG hackers. Yesterday I began diagnosing a peculiar bug in some
production code that has been happily running for months. I finally got
to the bottom of it despite the rather misleading error message. Anyway,
within a section of code we are making a DELETE call to the database via
the libpq
Hey Jim,
2012/8/8 Jim Vanns james.va...@framestore.com
Hello PG hackers. Yesterday I began diagnosing a peculiar bug in some
production code that has been happily running for months. I finally got
to the bottom of it despite the rather misleading error message. Anyway,
within a section of
Ah ha. Yes, you're correct. It does mention here that an Int16 is used
to specify the number of parameter format codes, values etc.
I suggest then that the documentation is updated to reflect this? Anf
again, perhaps the 'int' for nParams should be an int16_t or short?
Naturally I have already
On 08.08.2012 12:36, Jim Vanns wrote:
Ah ha. Yes, you're correct. It does mention here that an Int16 is used
to specify the number of parameter format codes, values etc.
I suggest then that the documentation is updated to reflect this? Anf
again, perhaps the 'int' for nParams should be an
On Wed, 2012-08-08 at 14:24 +0300, Heikki Linnakangas wrote:
On 08.08.2012 12:36, Jim Vanns wrote:
Ah ha. Yes, you're correct. It does mention here that an Int16 is used
to specify the number of parameter format codes, values etc.
I suggest then that the documentation is updated to
On Wed, Aug 8, 2012 at 1:24 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 08.08.2012 12:36, Jim Vanns wrote:
Ah ha. Yes, you're correct. It does mention here that an Int16 is used
to specify the number of parameter format codes, values etc.
I suggest then that the
Bruce Momjian br...@momjian.us wrote:
Did we ever decide on this?
We discussed it to the point of consensus, and Tom wrote a patch to
implement that. Testing in my shop hit problems for which the cause
was not obvious. I don't know whether there is a flaw in the
designed approach that we
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 08.08.2012 12:36, Jim Vanns wrote:
I suggest then that the documentation is updated to reflect this? Anf
again, perhaps the 'int' for nParams should be an int16_t or short?
I don't think we should change the function signature
Robert Ross rr...@translattice.com writes:
I have looked at the Postgres 9.2 stable and Postgres 9.2 beta 3 git
archives and this bug still appears to be present.
TwoPhaseGetDummyProc returns a PGPROC*. In 9.0, it was safe for
TwoPhaseGetDummyBackendId() to cast this to a
On Tue, Aug 7, 2012 at 6:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
What I'd like to do next, barring objections, is to band-aid the places
where the planner could crash on a LATERAL query (probably just make it
throw FEATURE_NOT_SUPPORTED errors), write some documentation, and
then
On Wed, Aug 8, 2012 at 09:26:41AM -0500, Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
Did we ever decide on this?
We discussed it to the point of consensus, and Tom wrote a patch to
implement that. Testing in my shop hit problems for which the cause
was not obvious. I
Fujii Masao masao.fu...@gmail.com writes:
When I used pg_trgm, I encountered the problem that the search result of
SeqScan was the different from that of BitmapScan even if the search
keyword was the same. Is this a bug?
Surely.
The cause is ISTM that pg_trgm wrongly ignores the heading
On Thu, Aug 2, 2012 at 05:03:04PM +0800, Qi Huang wrote:
Hi, hackers
I was exporting my project to a patch file. As the patch review requires,
the patch needs to be in context diff format (http://wiki.postgresql.org/wiki/
Reviewing_a_Patch). But the git diff exports in a format similar to
On Wed, Aug 8, 2012 at 3:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 2 August 2012 17:18, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
In HEAD and 9.2, the following scenario happens in archive recovery.
1. The archived WAL file is restored onto the temporary file name
RECOVERYXLOG.
... btw, I think there is another problem here, which is that
generate_wildcard_trgm will restart get_wildcard_part at the
same place that the second loop exits, which means it would
do the wrong thing if what it returns is a pointer to the
second char of an escape pair. Consider for instance
On 08/08/2012 01:29 PM, Bruce Momjian wrote:
On Thu, Aug 2, 2012 at 05:03:04PM +0800, Qi Huang wrote:
Hi, hackers
I was exporting my project to a patch file. As the patch review requires,
the patch needs to be in context diff format (http://wiki.postgresql.org/wiki/
Reviewing_a_Patch).
On Tue, Aug 7, 2012 at 4:52 PM, Simon Riggs si...@2ndquadrant.com wrote:
Incidentally, we can also optimise repeated inserts within a normal
transaction using this method, by implementing deferred unique
constraints. At present we say that unique constraints aren't
deferrable, but there's no
On 8 August 2012 20:34, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 7, 2012 at 4:52 PM, Simon Riggs si...@2ndquadrant.com wrote:
Incidentally, we can also optimise repeated inserts within a normal
transaction using this method, by implementing deferred unique
constraints. At present
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
Yes, the list of rough edges is the 14-steps you have to perform to run
pg_upgrade, as documented in the pg_upgrade manual page:
http://www.postgresql.org/docs/9.2/static/pgupgrade.html
The unknown is how to
On Wed, Aug 1, 2012 at 4:28 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
Dear PostgreSQL developers,
Plese find attached a patch so that:
Make psql -1 file.sql work as with -f
Make psql --single-transaction option work on a non-interactive
standard input as well, so that psql
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
Yes, the list of rough edges is the 14-steps you have to perform to run
pg_upgrade, as documented in the pg_upgrade manual page:
Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012:
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
Yes, the list of rough edges is the 14-steps you have to perform to run
pg_upgrade,
On Wed, Aug 8, 2012 at 4:29 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
I wonder if things would be facilitated by having a config file for
pg_upgrade to specify binary and PGDATA paths instead of having awkward
command line switches. That way you could request the user to create
such
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012:
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
I think this is one good idea:
http://archives.postgresql.org/message-id/29806.1340655...@sss.pgh.pa.us
If we
On Wed, Aug 08, 2012 at 04:55:43PM -0400, Robert Haas wrote:
On Wed, Aug 1, 2012 at 4:28 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
Dear PostgreSQL developers,
Plese find attached a patch so that:
Make psql -1 file.sql work as with -f
Make psql --single-transaction option
On Wed, Aug 8, 2012 at 05:29:49PM -0400, Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012:
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian br...@momjian.us wrote:
Yes, the list of
On Wed, Aug 8, 2012 at 06:42:27PM -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012:
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
I think this is one good idea:
On 29 July 2012 16:01, Fujii Masao masao.fu...@gmail.com wrote:
Attached patch changes the startup process so that it creates .done file
whenever WAL file is successfully restored, whether archive mode is
enabled or not. The restored WAL files will not be archived again because
of .done file.
Date: Wed, 8 Aug 2012 15:05:06 -0400
From: and...@dunslane.net
To: br...@momjian.us
CC: huangq...@outlook.com; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Git diff patch in context diff format
On 08/08/2012 01:29 PM, Bruce Momjian wrote:
On Thu, Aug 2, 2012 at 05:03:04PM
32 matches
Mail list logo
