On Wed, Apr 16, 2014 at 11:01:56PM -0400, Bruce Momjian wrote:
On Tue, Apr 1, 2014 at 10:32:01AM -0400, Tom Lane wrote:
Adrian Vondendriesch adrian.vondendrie...@credativ.de writes:
I patched the function conninfo_array_parse() which is used by
PQconnectStartParams to behave like
On Tue, Apr 1, 2014 at 05:06:08PM +0200, Adrian Vondendriesch wrote:
Am 01.04.2014 16:32, schrieb Tom Lane:
Adrian Vondendriesch adrian.vondendrie...@credativ.de writes:
I patched the function conninfo_array_parse() which is used by
PQconnectStartParams to behave like PQsetdbLogin. The
On Tue, Apr 1, 2014 at 10:32:01AM -0400, Tom Lane wrote:
Adrian Vondendriesch adrian.vondendrie...@credativ.de writes:
I patched the function conninfo_array_parse() which is used by
PQconnectStartParams to behave like PQsetdbLogin. The patch also
contains a document patch which clarify
Hi,
Am Wed, 12 Feb 2014 13:47:41 -0500
schrieb Robert Haas robertmh...@gmail.com:
On Mon, Feb 10, 2014 at 12:14 PM, Jeff Janes jeff.ja...@gmail.com
wrote:
Presumably whatever behavior difference you are seeing is somehow
related to the use of PQconnectdbParams() rather than
Adrian Vondendriesch adrian.vondendrie...@credativ.de writes:
I patched the function conninfo_array_parse() which is used by
PQconnectStartParams to behave like PQsetdbLogin. The patch also
contains a document patch which clarify unspecified parameters.
I see no documentation update here.
Am 01.04.2014 16:32, schrieb Tom Lane:
Adrian Vondendriesch adrian.vondendrie...@credativ.de writes:
I patched the function conninfo_array_parse() which is used by
PQconnectStartParams to behave like PQsetdbLogin. The patch also
contains a document patch which clarify unspecified parameters.
On Mon, Feb 10, 2014 at 12:14 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Presumably whatever behavior difference you are seeing is somehow
related to the use of PQconnectdbParams() rather than PQsetdbLogin(),
but the fine manual does not appear to document a different between
those functions
On Sun, Feb 9, 2014 at 4:56 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 9, 2014 at 6:33 PM, Jeff Janes jeff.ja...@gmail.com wrote:
Since this commit (17676c785a95b2598c573), pgbench no longer uses
.pgpass to
obtain passwords, but instead prompts for a password
This
On Wed, Jul 4, 2012 at 12:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 3, 2012 at 11:36 PM, Amit Kapila amit.kap...@huawei.com
wrote:
Hi Shigeru/Robert,
The way fixing oid2name and pgbench seems reasonable, so applying it to
vacuumlo (as Peter mentioned) would be enough
On Sun, Feb 9, 2014 at 6:33 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Wed, Jul 4, 2012 at 12:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 3, 2012 at 11:36 PM, Amit Kapila amit.kap...@huawei.com
wrote:
Hi Shigeru/Robert,
The way fixing oid2name and pgbench seems
On Tue, Jul 3, 2012 at 11:36 PM, Amit Kapila amit.kap...@huawei.com wrote:
Hi Shigeru/Robert,
The way fixing oid2name and pgbench seems reasonable, so applying it to
vacuumlo (as Peter mentioned) would be enough for this issue.
Shall I consider following 2 points to update the patch:
1.
On fre, 2012-06-08 at 17:14 +, Amit kapila wrote:
This patch is to provide support for fallback application name for
contrib/pgbench, oid2name, and dblink.
vacuumlo should also be treated, I think.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
(2012/06/28 11:16), Robert Haas wrote:
If it can be done without costing anything meaningful, I don't object,
but I would humbly suggest that this is not hugely important one way
or the other. application_name is primarily a monitoring convenience,
so it's not hugely important to have it set
Hi Shigeru/Robert,
-Original Message-
From: Shigeru HANADA [mailto:shigeru.han...@gmail.com]
Sent: Wednesday, July 04, 2012 6:57 AM
(2012/06/28 11:16), Robert Haas wrote:
If it can be done without costing anything meaningful, I don't object,
but I would humbly suggest that this is not
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Thursday, June 28, 2012 7:46 AM
On Wed, Jun 27, 2012 at 9:57 PM, Shigeru HANADA
shigeru.han...@gmail.com wrote:
On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas robertmh...@gmail.com
wrote:
Indeed reparsing connection string is not cheap, but
On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila amit.kap...@huawei.com wrote:
To achieve the same in dblink, we need to parse the passed connection string
and check if it contains fallback_application_name, if yes then its
On Wed, Jun 27, 2012 at 9:57 PM, Shigeru HANADA
shigeru.han...@gmail.com wrote:
On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila amit.kap...@huawei.com wrote:
To achieve the same in dblink, we need to parse the passed
On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila amit.kap...@huawei.com wrote:
Why not 'dblink'?
We can do for dblink as well. I just wanted to check before implementing in
dblink.
I have checked the dblink_connect() function, it receives the connect string
and used in most cases that string
That seems undesirable. I don't think this is important enough to be
worth reparsing the connection string for.
The connect string should not be long, so parsing is not a big cost
performance wise.
I have currently modified the code for dblink in the patch I have uploaded
in CF.
However as
I have created the patch by including fallback_application_name for dblink
as well.
In this I have used the name of fallback_application_name as dblink.
Please let me know your suggestions regarding the same.
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent:
On Mon, Jun 11, 2012 at 5:30 AM, Amit Kapila amit.kap...@huawei.com wrote:
As per the previous discussion in link below, it seems that fallback
application name needs to be provided for only
pgbench and oid2name.
Why not 'dblink'?
We can do for dblink as well. I just wanted to check before implementing in
dblink.
I have checked the dblink_connect() function, it receives the connect string
and used in most cases that string to
call libpq connect which is different from pgbench and oid2name where
As per the previous discussion in link below, it seems that fallback
application name needs to be provided for only
pgbench and oid2name.
http://archives.postgresql.org/message-id/w2g9837222c1004070216u3bc46b3ahbdd
fdffdbfb46...@mail.gmail.com
However the title of Todo Item suggests it
This patch is to provide support for fallback application name for
contrib/pgbench, oid2name, and dblink.
Currently I have done the implementation for pgbench. The implementation is
same as in psql.
Before creating a final patch, I wanted to check whether my direction for
creating a patch is
24 matches
Mail list logo
