any developer to work on it and
community to agree on it. This is just my personal opinion, so please feel free
to work the way you think is best.
2013/6/24 Amit Kapila
On Monday, June 24, 2013 1:23 PM Борис Ромашов wrote:
>> Why do you want to know the exact row due to which this happens,
nsert into tbl values(4,2);
ERROR: duplicate key value violates unique constraint "tbl_c1_idx"
DETAIL: Key (c1)=(4) already exists.
With Regards,
Amit Kapila.
2013/6/24 Amit Kapila
On Friday, June 21, 2013 1:24 PM Борис Ромашов wrote:
> I just realized that I wanted to as
generate_series(1,2));
?column?
--
f
(1 row)
postgres=# select 1 = (select generate_series(1,2));
ERROR: more than one row returned by a subquery used as an expression
postgres=#
Why do you want to know the exact row due to which this happens, and what you
want to do with it?
On Tuesday, June 11, 2013 12:15 AM Tom Lane wrote:
> [ got around to looking at this thread finally ]
>
> Amit Kapila writes:
> > What happens when you change ON DELETE rule of the view that really
> deletes
> > elements is that command type after applying rule re
On Wednesday, June 05, 2013 5:34 AM Rafał Rzepecki wrote:
> On Tue, Jun 4, 2013 at 12:35 PM, Amit Kapila
> wrote:
> > On Saturday, June 01, 2013 9:37 PM
> >
> >> Row type literals constructed with ROW() cause an error when used in
> >> an IN clause (stri
copyObject(lexpr),
rexpr,
a->location);
Changing the functionality of transformAExprIn() similar to transformAExprOp()
will fix this issue, but not sure if there is any other side effect of same.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
it works, I will
> use it as, I agree with you, it should meet my performance
> requirements.Note that my application can perform some SQL requests
> thousands of time during the same server session. So, for me, using
> prepared statement is an important feature !
> Thanks for you
eted;
Execute t1plan(10,90);
After preparing once, you can call Execute SQL statement multiple times, it
can save your time of prepare each time of delete statement, which was
your motto for using PQexecPrepared().
>
> >
> > 2013/5/28 Amit Kapila :
> > > On Tuesday, May 28,
he problem is related to libpq ?
>
> Did you tried the C code provided to see if you can reproduce the
> problem ?
>
> Regards,
> Brice
>
>
> 2013/5/28 Amit Kapila :
> > On Tuesday, May 28, 2013 12:39 AM Brice André wrote:
> >> Dear all,
> >>
&
| t
55 | t
56 | t
57 | t
58 | t
59 | t
60 | t
61 | t
62 | t
63 | t
64 | t
65 | t
66 | t
67 | t
68 | t
69 | t
70 | t
71 | t
72 | t
73 | t
74 | t
75 | t
76 | t
77 | t
78 | t
79 | t
80 | t
81 | t
82 | t
83 | t
84 | t
85 | t
86 | t
On Friday, May 24, 2013 6:04 AM Chaya Gilburt wrote:
> Dear Amit Kapila,
>
> The apparent problem with duplicate rows appearing in the database was
> solved. I forgot that I had modified a program to insert payments
> directly
> to the database. Not only that, but I also did no
appropriately
2. There are triggers defined on tables which could insert the extra rows
you are seeing.
Is the problem you described happen more than once? Could you form testcase
which can show such behavior?
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgre
lready rejected?
As per current implementation PostgreSQL behavior is different from Oracle in
the scenario mentioned by you.
However you can try by using Savepoint before failing statement and then after
failure do Rollback To Savepoint_name and then call your select statement.
This will make
> Sent: Wednesday, April 10, 2013 1:49 PM Dang Minh Huong wrote:
> To: Amit Kapila
> Subject: Re: [BUGS] replication_timeout not effective
On Wednesday, April 10, 2013 1:49 PM
> Hi,
>
> Thank you for your soon reply.
>
> I'm trying to set the network timeout related
ess but it
> come too slow (about 30minutes after standby PC was down).
For such scenario's, new parameter wal_sender_timeout has been introduced in
9.3. Refer below:
http://www.postgresql.org/docs/devel/static/runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SENDER
I am not sure h
quot;blah blah\"
Check on net how to open filename having space.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Monday, February 18, 2013 8:28 PM Rafael Martinez wrote:
> On 02/18/2013 03:41 PM, Amit Kapila wrote:
> [...]
> > Why you think this is wrong behavior, do you expect any time you
> > call pg_rotate_logfile(), it should truncate the file if
> > log_truncate_on_ro
you have used pg_rotate_logfile() to perform the action,
otherwise if it would have been done
based on time, it should have truncated the file.
Why you think this is wrong behavior, do you expect any time you call
pg_rotate_logfile(), it should truncate the file if
log_truncate_on_rotation is on?
I think if you are expecting such behavior, it might not be right expectation,
because it considers the the time and log_filename format as well.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
;dim_id" IS NULL
> Line: 1
>
> [Executed: 2/4/13 11:07:08 PM PST ] [Execution: 0/ms]
>
>
> exception.
>
> Is there anything i am missing.
Why the query is different in Exception?
Can you try with
SELECT
tbl.id,
tbl.day,
tbl.week,
t
o.5
> #5 0x0013d792 in PQgetResult () from /usr/local/pgsql/lib/libpq.so.5
I have also observed similar problem in some of tests, but it appears to be
hung due to network break and it came out after 15-20 minutes.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@post
On Thursday, October 11, 2012 8:22 PM Heikki Linnakangas wrote:
On 11.10.2012 13:17, Amit Kapila wrote:
>>> How does this look now?
>
>> The Patch is fine and test results are also fine.
>Ok, thanks. Committed.
Thank you very much.
With Regards,
Amit Kapila.
--
Sent v
On Wednesday, October 10, 2012 9:15 PM Heikki Linnakangas wrote:
> On 04.10.2012 13:12, Amit kapila wrote:
> > Following changes are done to support replication timeout in sender as
> well as receiver:
> >
> > 1. One new configuration parameter wal_receiver_timeout is a
On Tuesday, October 09, 2012 6:00 PM Robert Haas wrote:
> On Mon, Oct 8, 2012 at 10:42 AM, Amit Kapila
> wrote:
> > How about following:
> > 1. replication_client_timeout -- shouldn't it be client as new
> configuration
> > is for wal receiver
> > 2. replicat
> On Monday, October 08, 2012 7:38 PM Robert Haas wrote:
> On Thu, Oct 4, 2012 at 6:12 AM, Amit kapila
> wrote:
> > 1. One new configuration parameter wal_receiver_timeout is added to
> detect timeout at receiver task.
> > 2. Existing parameter replicati
> -Original Message-
> From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-
> ow...@postgresql.org] On Behalf Of Amit kapila
> Sent: Thursday, October 04, 2012 3:43 PM
> To: Heikki Linnakangas
> Cc: Fujii Masao; pgsql-bugs@postgresql.org; pgsql-hack...@postgresql
On Tuesday, October 02, 2012 1:56 PM Heikki Linnakangas wrote:
On 02.10.2012 10:36, Amit kapila wrote:
> On Monday, October 01, 2012 4:08 PM Heikki Linnakangas wrote:
>>> So let's think how this should ideally work from a user's point of view.
>>> I think th
gt; I agree, but also note that wal_receiver_status_interval serves
> another user-visible purpose as well.
By above do you mean to say that wal_receiver_status_interval is used for reply
of data sent by server to indicate till what point receiver has flushed data or
something else?
With Reg
On Monday, October 01, 2012 4:08 PM Heikki Linnakangas wrote:
On 21.09.2012 14:18, Amit kapila wrote:
> On Tuesday, September 18, 2012 6:02 PM Fujii Masao wrote:
> On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote:
>
>>>> Approach-2 :
>>>> Provide a variable wa
On Saturday, September 15, 2012 11:41 AM Fujii Masao wrote:
> On Fri, Sep 14, 2012 at 12:21 PM, Amit Kapila
> wrote:
> > On Thursday, September 13, 2012 10:32 PM Fujii Masao wrote:
> > On Thu, Sep 13, 2012 at 9:21 PM, Heikki Linnakangas
> wrote:
> >> On 12.09
On Tuesday, September 18, 2012 6:02 PM Fujii Masao wrote:
On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote:
>> Approach-2 :
>> Provide a variable wal_send_status_interval, such that if this is 0, then
>> the current behavior would prevail and if its non-zero then KeepAlive
&
On Tuesday, September 18, 2012 6:03 PM Fujii Masao wrote:
On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote:
>> To define the behavior correctly, according to me there are 2 options
now:
>
>> Approach-1 :
>> Document that both(sender and receiver) the timeout parameters shou
On Sunday, September 16, 2012 12:14 AM Fujii Masao wrote:
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila wrote:
> On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
> On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila
wrote:
>>
>> On Thursday, September 13, 2012 10:57 PM Fuj
On Sunday, September 16, 2012 12:14 AM Fujii Masao wrote:
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila wrote:
> On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
> On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila wrote:
>>
>> On Thursday, September 13, 2012 10:57 PM Fuj
On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila wrote:
>
> On Thursday, September 13, 2012 10:57 PM Fujii Masao
> On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
>> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
On Thursday, September 13, 2012 10:57 PM Fujii Masao
On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila wrote:
> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>>>> The following bug has been logged on the website:
>>>
&g
he website:
>>>
>>> Bug reference: 7533
>>> Logged by: Amit Kapila
>>> Email address: amit.kap...@huawei.com
>>> PostgreSQL version: 9.2.0
>>> Operating system: Suse
>>> Description:
>>>
>>> M host is prima
On Thursday, September 13, 2012 5:52 PM Heikki Linnakangas wrote:
On 12.09.2012 22:03, Fujii Masao wrote:
> On Wed, Sep 12, 2012 at 8:47 PM, wrote:
>> The following bug has been logged on the website:
>>
>>> Bug reference: 7533
>>> Logged by:
On Thursday, September 13, 2012 12:34 AM Fujii Masao wrote:
On Wed, Sep 12, 2012 at 8:47 PM, wrote:
>> The following bug has been logged on the website:
>
>> Bug reference: 7533
>> Logged by: Amit Kapila
>> Email address: amit.kap...@huawei.com
&
On Wednesday, September 12, 2012 10:15 PM Fujii Masao
On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7534
>> Logged by: Amit Kapila
>> Email address: amit.kap...@huawei.co
On Wednesday, September 12, 2012 10:12 PM Magnus Hagander wrote:
On Wed, Sep 12, 2012 at 1:54 PM, wrote:
>> The following bug has been logged on the website:
>
>> Bug reference: 7534
>> Logged by: Amit Kapila
>> Email address: amit.kap...@huawe
The following bug has been logged on the website:
Bug reference: 7534
Logged by: Amit Kapila
Email address: amit.kap...@huawei.com
PostgreSQL version: 9.2.0
Operating system: Suse 10
Description:
1. Both master and standby machine are connected normally,
2. then you
The following bug has been logged on the website:
Bug reference: 7533
Logged by: Amit Kapila
Email address: amit.kap...@huawei.com
PostgreSQL version: 9.2.0
Operating system: Suse
Description:
M host is primary, S host is standby and CS host is cascaded standby.
1
On Friday, September 07, 2012 12:20 AM Amit Kapila wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila wrote:
>> AFAICT during Update also, it doesn't contain useful. The only chance
it
>> would have contain something useful is when it goes for EvalPlanQual and
>> then a
However these attributes get
filled in heap_update much later.
So now should the fix be that it returns an error for system column
reference except for OID case?
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Friday, August 24, 2012 7:46 PM
Amit Kapila writes:
> From: pgsql-bugs-ow...@postgresql.org
> [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Tom Lane
>>> None of the system columns are set at the time check constraints
set at the time check constraints are
>checked.
Is there any problem if set tableOID before calling ExecConstarints()?
I am not sure may be this is not so important problem for which we don't
want to
change existing code.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pg
Sure, no problem.
But I also might take some time to do further analysis as I am little busy
with other things as well.
Hope it will not impact you much.
With Regards,
Amit Kapila.
From: Jeferson Braga [mailto:jefersonbl...@gmail.com]
Sent: Thursday, August 09, 2012 7:42 PM
To
this?
Have you tried it with less data?
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
From: Noah Misch [mailto:n...@leadboat.com]
Sent: Thursday, July 19, 2012 5:23 PM
On Tue, Jul 17, 2012 at 08:59:50AM +, Amit kapila wrote:
>> Patch is attached with this mail.
> Thanks. This patch is ready for committer.
>> +-- Test non-inheritable indices [UNIQUE, EXCL
>From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org]
>On
> Behalf Of sobhit.pande...@gmail.com
> The following bug has been logged on the website:
> Bug reference: 6740
> Logged by: sobhit
> Email address: sobhit.pande...@gmail.com
> PostgreSQL vers
> From: Noah Misch [n...@leadboat.com]
> Sent: Monday, July 16, 2012 8:42 PM
> On Mon, Jul 16, 2012 at 04:49:46PM +0530, Amit Kapila wrote:
>> > Care to prepare a patch with a test case addition?
>> Let me know if above is sufficient or shall I include anything more in
&g
test case addition?
Let me know if above is sufficient or shall I include anything more in
patch.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ith a test case addition?
Yes. I have started working.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
is specified.
In function ATExecDropConstraint(), for the constarint
"test_constraints_val1_val2_key" con->connoinherit is false,
due to which it tries to drop the constrint from child table as well.
I have checked that from function index_constraint_create() when it calls
function
thing I have noticed is that in function ExecScanSubPlan, the similar
work is not done in
Per-query memory context, I am not sure if it is of any relevance for the
problem you mentioned.
With Regards,
Amit Kapila.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chan
PM
To: Amit Kapila
Cc: 'Edmund Horner'; Tom Lane; Pg Bugs; Bruce Momjian
Subject: Re: [BUGS] 9.2 beta2 - pg_ctl crashes on Win32 when neither PGDATA nor
-D specified
Excerpts from Amit Kapila's message of mié jun 13 00:53:47 -0400 2012:
> > Unfortunately in src/backend/main/
out checking if it's running as root.
-Original Message-
From: Edmund Horner [mailto:ejr...@gmail.com]
Sent: Wednesday, June 13, 2012 6:26 AM
To: Amit Kapila
Cc: Tom Lane; pgsql-bugs@postgresql.org; Bruce Momjian
Subject: Re: [BUGS] 9.2 beta2 - pg_ctl crashes on Win32 when neither PG
>> I note that "postgres -C data_directory" will refuse to run on the
>> command line because I've got admin privileges in Windows, and that
>> pg_ctl normally starts postgres.exe using CreateRestrictedProcess.
>> But it does not do so for the popen call in adjust_data_dir.
> if that actually is a
Can you try installing it on different windows machine.
This should not be a bug of postgres, some problem with the way you or doing or
some env. Problem.
From: Milen Lazarov [mailto:milen_laza...@yahoo.com]
Sent: Saturday, May 05, 2012 11:30 PM
To: Amit Kapila
Subject: Re: [BUGS] no
To strat the service on windows, the user (postgres, incase you didn't
change during installation) needs to be have administrative privilege and
service has to run as that user.
You can use Run as in windows to run the particular executable or change the
user in services.
From: pgsql-bugs-ow..
No need to reply the below mail.
I am able to generate the scenario.
One of them is basically when there is an expression involving relations on
one side and Var on other side.
Select * from t1,t2 where t1.c1 + t2.c2 = t1.c3;
From: Amit Kapila [mailto:amit.kap...@huawei.com]
Sent
g a function with numeric or integer parameters.
Can you provide this with an example like how you have defined your function
and how it is getting called from ODBC.
-Original Message-
From: Barry Bell [mailto:barry_b...@harte-hanks.com]
Sent: Wednesday, April 11, 2012 6:24 PM
To: Amit
: Amit Kapila
Cc: pgsql-bugs@postgresql.org
Subject: RE: [BUGS] BUG #6534: Passing numeric Bind variables to ODBC driver
convers to "Double precision"
No matter what numeric type I try to pass,(integer, numeric, currency) the
ODBC driver is turning it into "Double Precision"
In ODBC while binding variable using SQLBindParameter(..) API you might be
using SQL_DOUBLE or SQL_Numeric or some similar datatype to send the
variable, thats why in postgres it is showing as "Double precision"
-Original Message-
From: pgsql-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-o
According to what I can see from this defect that it is not confirmed
whether the Postgre server is started or not properly.
You can try on confirming about the following 2 points:
1. How many postgres processes you are able to see in your task manager.
This can give hint whether appropriate postg
65 matches
Mail list logo
