> 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:0
On 29 July 2012 16:01, Fujii Masao 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.
The proposed pat
On Wed, Aug 8, 2012 at 06:42:27PM -0400, Tom Lane wrote:
> Alvaro Herrera 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.or
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 wrote:
> > > > Yes, the list of rough edg
On Wed, Aug 08, 2012 at 04:55:43PM -0400, Robert Haas wrote:
> On Wed, Aug 1, 2012 at 4:28 AM, Fabien COELHO 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
Alvaro Herrera 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 currently req
On Wed, Aug 8, 2012 at 4:29 PM, Alvaro Herrera 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 a file, then
>
i l
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 wrote:
> > > Yes, the list of rough edges is the 14-steps you have to perform to run
> > > pg_upgrade, as docum
On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote:
> On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian 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/do
On Wed, Aug 1, 2012 at 4:28 AM, Fabien COELHO 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 -1 < i
On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian 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 reduce the numbe
On 8 August 2012 20:34, Robert Haas wrote:
> On Tue, Aug 7, 2012 at 4:52 PM, Simon Riggs 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
On Tue, Aug 7, 2012 at 4:52 PM, Simon Riggs 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 reason they can't b
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). Bu
... 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 Wed, Aug 8, 2012 at 3:08 AM, Simon Riggs wrote:
> On 2 August 2012 17:18, Fujii Masao 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".
>> 2. The restored WAL file
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
Fujii Masao 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 wildcard
> character (
On Wed, Aug 8, 2012 at 09:26:41AM -0500, Kevin Grittner wrote:
> Bruce Momjian 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 kn
On Tue, Aug 7, 2012 at 6:08 PM, Tom Lane 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 commit what
Robert Ross 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 GlobalTransaction
> because the G
Heikki Linnakangas 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 for this, but I
> think a san
Bruce Momjian 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 all missed, a simp
On Wed, Aug 8, 2012 at 1:24 PM, 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 r
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 t
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 int16_
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 m
Hey Jim,
2012/8/8 Jim Vanns
> 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 DELE
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 c
On 8 August 2012 03:44, Jeff Janes wrote:
> On Tue, Aug 7, 2012 at 1:52 PM, Simon Riggs wrote:
>> On 7 August 2012 20:58, Jeff Janes wrote:
>>> Hi Heikki,
>>>
>>> Is the bulk index insert still an active area for you?
>>>
>>> If not, is there some kind of summary of design or analysis work
>>> a
30 matches
Mail list logo