r operator.
More details from another thread:
https://www.postgresql.org/message-id/bf2827dcce55594c8d7a8f7ffd3ab77159a9b...@szxeml521-mbs.china.huawei.com
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mechanism of Hash Join, now there is pipelining Hash
join where probe and build both happens together).
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ple --> Outer
The result we got was really impressive.
There is a paper by Thomas Neumann on this idea:
http://www.vldb.org/pvldb/vol4/p539-neumann.pdf
Note: VitesseDB has also implemented this approach for Hash Join along with
compilation and their result is really impressive.
Thanks and R
already this
function takes of handling " NOTICE message that the backend might have sent
just before it died "
Attached is the patch with this change.
Comments?
Thanks and Regards,
Kumar Rajeev Rastogi
dangle-v4.patch
Description: dangle-v4.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ugh I am also in favor of providing some error message to client. But with
the current infrastructure, I don’t think there is any way to pass this error
message to client [This error has happened without involvement of the client
side].
Comments?
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
sg("terminating connection due to postmaster
>>> shutdown")));
>>
>> Agreed, but I don't think "shutdown" is the right word to use here --
>> that makes it sound like it was orderly. Perhaps "crash"?
>
>Well, that's a little speculat
_read and secure_write function will
wait on an additional event as WL_POSTMASTER_DEATH.
2. There is a possibility that the command is read without waiting on latch.
This case is handled by checking postmaster status after command read (i.e.
after ReadCommand).
Attached is the patch.
Thanks and Regard
On 14 October 2015 14:03, Kyotaro HORIGUCHI:
>Subject: Re: [HACKERS] Dangling Client Backend Process
>
>At Wed, 14 Oct 2015 11:08:37 +0530, Amit Kapila
>wrote in
>
>> On Tue, Oct 13, 2015 at 3:54 PM, Rajeev rastogi
>>
>> wrote:
>> > If we add the even
On 12th October 2015 20:45, Rajeev Rastogi Wrote:
>>> I observed one strange behavior today that if postmaster process gets
>>> crashed/killed, then it kill all background processes but not the client
>>> backend process.
>> This is a known behaviour and
ame time I agree this is not the best solution, we should look for
more appropriate/better one.
Now as it is confirmed to be valid issue, I will spend some time on this to
find if there is something more appropriate solution.
Thanks and Regards,
Kumar Rajeev Rastogi
every command read but it will add extra cost for each query execution.
Any comments?
Thanks and Regards,
Kumar Rajeev Rastogi
and after execution of query. Then comparison of these two dump will be helpful
to further analyze.
Attached is the patch. Please provide your opinion. If it is OK, I will add it
to next commitFest.
Thanks and Regards,
Kumar Rajeev Rastogi
memory_ctxt_dumpv1.patch
Description: memory_ctxt_du
(2) we don't need a separate PGPROC for each
>autonomous transaction. The first of those benefits is agreeable; the
>second one is, in my opinion, a key design goal for this feature.
Yes I agree with this. I was in favor of error all the time without involving
deadlock detector
On 03 August 2015 18:40, Merlin Moncure [mailto:mmonc...@gmail.com] Wrote:
>On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi
> wrote:
>> On 31 July 2015 23:10, Robert Haas Wrote:
>>>I think we're going entirely down the wrong path here. Why is it ever
>useful for
the solution. Once error thrown
from autonomous transaction, main transaction may continue as it is (or abort
main transaction also??).
Any other suggestion to handle this will be really helpful.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hack
On 28 July 2015 03:21, Josh Berkus Wrote:
On 07/27/2015 02:47 AM, Rajeev rastogi wrote:
>>> Why have any fixed maximum?
>> Since we are planning to have nested autonomous transaction, so it is
>> required to have limit on this so that resources can be controlled.
>Is t
see the
>parent/child relationship from outside the backend doing the nested tx
>anyway.
Thanks, sounds to be a good idea. I shall evaluate the same.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 23 July 2015 21:04, Robert Haas Wrote:
On Thu, Jul 23, 2015 at 1:31 AM, Rajeev rastogi
wrote:
>> 2.It should be allowed to deadlock with master transaction. We
>> need to work-out a solution to avoid deadlock.
>This sentence seems to contradict itself. I though
cases.
Requesting for everyone's opinion regarding this based on which we can proceed
to enhance/tune/re-write our design.
Thanks and Regards,
Kumar Rajeev Rastogi
uce btree scan overhead for < and > strategies
For <, <=, > and >= strategies, mark the first scan key
as already matched if scanning in an appropriate direction.
If index tuple contains no nulls we can skip the first
re-check for each tuple.
Author: Kum
e let me know if community will be interested in this or if there were
already any discussion about this in past?
Please provide your opinion/suggestion.
Thanks and Regards,
Kumar Rajeev Rastogi
ng the version-10.
I just checked version-11 and version-12 and found to be already fixed.
I should have checked the latest version before sending the report…☺
Thanks and Regards,
Kumar Rajeev Rastogi
From: Amit Kapila [mailto:amit.kapil...@gmail.com]
Sent: 25 March 2015 16:00
To: Rajeev rast
e because of which this issue
has not yet been observed.
Thanks and Regards,
Kumar Rajeev Rastogi
On 23 March 2015 21:39, Robert Haas
> On Mon, Mar 23, 2015 at 6:01 AM, Rajeev rastogi
> wrote:
> > The cost of re-scan of SeqScan node is considered to be same scan of
> > SeqScan node, which always assumes that the records is fetched from
> > disk and hence disk acc
sure if we can consider this to be a problem or not but I just wanted
to share as generally it is expected by user to be Materialization faster than
Non-materialized.
Please provide your opinion. If we can do something about this then I can take
up this work.
Than
in many case.
With this change, I did one small performance test on pgbench with "prepared
queries for pgbench select with 16 users and observed performance benefit of
10%".
Please provide your opinion?
Thanks and Regards,
Kumar Rajeev Rastogi
ar enough. I'll do my best to
> improve that, then look to commit this in about 5 hours.
Thanks a lot for support. Please let me know if I also need to add something.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
comments need some work to more clearly explain what
> this patch does.
Please help me to understand this point, you want me to add more comments about
patch in this mail chain or in code.
Thanks and Regards,
Kumar Rajeev Rastogi
As per Simon Riggs suggestion:
unctions, then
I feel We don’t need to add anything for that.
Any opinion?
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 24 September 2014 17:15, Michael Paquier Wrote:
> On Wed, Sep 24, 2014 at 7:59 PM, Abhijit Menon-Sen
> wrote:
> > I can never remember that pg_controldata takes only a dirname rather
> > than "-D dirname", and I gather I'm not the only one. Here's a tiny
> > patch to make it work either way.
On 22 September 2014 18:51, Stephen Frost Wrote:
* Rajeev rastogi (rajeev.rast...@huawei.com) wrote:
> Thanks, I shall start to prepare a patch for this optimization and share in 1
> or 2 days.
> This sounded interesting to me also- please be sure to put it on the open
> commitf
On 22 September 2014 19:17, Heikki Linnakangas wrote:
> On 09/22/2014 04:45 PM, Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
> >>> So my proposal is to skip the condition check on the first scan key
> condit
> > I would like to submit the patch for this improvement.
> > Please provide your feedback. Also let me know if I am missing
> something.
>
> Yeah, sounds like a good idea. This scenario might not arise very often,
> but it should be cheap to check, so I doubt it will ad
t matching tuples.
I would like to submit the patch for this improvement.
Please provide your feedback. Also let me know if I am missing something.
Thanks and Regards,
Kumar Rajeev Rastogi
--Schema
create table tbl2(id1 int, id2 varchar(10), id3 int);
create index idx2 on tbl2(id2, id3);
--Proce
tandbys listed after this will take over the role
of synchronous standby if any of the first synchronous-standby-num standby
fails.
Let me know incase if something is not clear.
Thanks and Regards,
Kumar Rajeev Rastogi.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
um potential standbys.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
h case. In case of processing of CREATE TABLESPACE redo, same is
already handled.
I will add this to 2014-08 CF for review.
Thanks and Regards,
Kumar Rajeev Rastogi
rec_issue_with_drop_tblspc_redo.patch
Description: rec_issue_with_drop_tblspc_redo.patch
--
Sent via pgsql-hackers mailing l
9.4 2014-01 CommitFest, which was rejected because of some issues. This patch
was meant to degrade the synchronous
level of master, if all synchronous standbys are down.
I plan to resubmit this with better design sometime in 9.5.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent v
On 01 July 2014 12:00, Amit Kapila Wrote:
>On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi
>mailto:rajeev.rast...@huawei.com>> wrote:
>> On 30 June 2014 22:50, Pavel Stehule Wrote:
>> >I didn't find a related message.
>> >?
>>
>> I think there
o
include pinning_backend also in the description.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ion from autonomous transaction
to parent transaction
END
END;
Please let me know if I have missed to answer any of your queries.
Thanks and Regards,
Kumar Rajeev Rastogi
e know if any issue or I am missing something.
Thanks and Regards,
Kumar Rajeev Rastogi
practical, when you are concentrated to error's processing.
Yeah right, I just wanted to raise point to provoke other thought to see if
anyone having different opinion. If no objection from others, we can go ahead
with the current prefixing approach.
Thanks and Regards,
Kumar Rajeev Rastogi
apply cleanly to the current git master
>* includes necessary docs
>* I think It is very good and necessary feature.
>If Kumar Rajeev Rastogi do not have any extra comments, then I think patch is
>ready for committer.
I have reviewed this patch. Please find my review comments below
ow-stopper. This can be optimized later
by method
as you mentioned and also by some cut-off technique based on which we can
decide that a XID beyond a certain range will be always visible, and thereby
avoiding look-up in pg_clog.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12 May 2014 19:27, Heikki Linnakangas Wrote:
> On 01/24/2014 02:10 PM, Rajeev rastogi wrote:
> > We are also planning to implement CSN based snapshot.
> > So I am curious to know whether any further development is happening
> on this.
>
> I started looking into this,
_table();
IMO, this might be useful for dynamic use of table (later column might be added
using 'ALTER') or to use as abstract ancestor in class hierarchy.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ime" for the same query with
same statistics
will become variable depending on the amount of time it had to wait to acquire
lock, which
will be bit confusing for users.
May be if we really have to print other time (i.e. parsing + analyzing +
rewrite), then IMHO
we can print with some d
e re-used along with your new design.
Also if possible you can share your design (even rough is OK), I will see if I
can contribute to that in some-way.
Thanks and Regards,
Kumar Rajeev Rastogi
to
keep it less impacting incase it is not configured.
An autonomous transaction can also conflict with main transaction, so in order
to check conflict between them,
I am distinguishing at this level.
Please correct me If I am wrong anywhere and also please provide your thought
on this and on ove
state at AT
>start/commit/rollback. Sorry, I haven't looked at your WIP patch yet.
For some of the resources, I have already written AtATStart/AtATEOX kind of
routines in WIP patch.
Comments/feedbacks/doubts are welcome.
Thanks and Regards,
Kumar Rajeev Rastogi
state at AT
>start/commit/rollback. Sorry, I haven't looked at your WIP patch yet.
For some of the resources, I have already written AtATStart/AtATEOX kind of
routines in WIP patch.
Comments/feedbacks/doubts are welcome.
Thanks and Regards,
Kumar Rajeev Rastogi
issue.
Thanks and Regards,
Kumar Rajeev Rastogi
Yes I am changing both. But no specific changes were required. During commit
and assignment of autonomous transaction, it is automatically taken care.
Any comment/feedback/doubt are welcome?
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
s transaction 107 will be as below:
Xmin: 100
Xmax: 109
Snapshot->xip[]: 100, 101, 102, 103, 105, 106
Snapshot->subxip[]: 104
Thanks and Regards,
Kumar Rajeev Rastogi
equivalent
to iterative count(*), which might degrade performance for VACUUM.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
are right. I am not planning to support only using plpgsql. Initially
we can support this
Using the standalone SQL-commands and then later we can enhance based on this
infrastructure
to be used using plpgsql, triggers.
Thanks and Regards,
Kumar Rajeev Rastogi
to finish this feature in multiple rounds i.e. first
patch, we can try to support autonomous transaction from
standalone SQL-command only, which will set-up infrastructure for future work
in this area.
Using the WIP patch sent, I have done basic testing and it works fine.
Any comments?
Tha
On 05 April 2014 04:14, Tom Lane
> > [ pgctl_win32service_rel_dbpath_v6.patch ]
>
> Committed with minor corrections, mostly but not all cosmetic.
Thanks a lot...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
attached patch with the fix.
Thanks and Regards,
Kumar Rajeev Rastogi
multiconstissuev1.patch
Description: multiconstissuev1.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 27 March 2014 17:16, Tom Lane Wrote:
> I agree we need to make the docs match the code, but changing behavior
> that's been like that for ten or fifteen years isn't the answer.
Sounds good.
Please find the attached patch with only documentation change.
Thanks and Regar
code change. After modification, result will be as follows:
postgres=# create database newtempdb template postgres;
ERROR: DB name "postgres" given as template is not a template database
Please provide your feedback.
Thanks and Regards,
Kumar Rajeev Rastogi
datistemplate_i
nd, how it got changed in standby also (if you have not taken back
again)?
Let me know If I have missed something.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
by's max_connection values lesser
than the master's max_connection value.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ommand tag will not be displayed.
2. In-case of \COPY ... TO ..., command tag will not be displayed.
3. In all other cases, command tag will be displayed similar as were getting
displayed earlier.
I have modified the corresponding documentation.
Please find the attached revised patch.
Thanks and
been selected.
But in-case of COPY TO STDOUT, if we don't print anything, then user does not
have any direct way of finding
that how many rows were copied from table to STDOUT, which might have been very
useful.
Please let me know your opinion or if I have missed something.
Thanks a
commands.
I agree that it breaks the backward compatibility but I am not sure if anyone
is so tightly coupled with this ( or whether they will be effected with
additional status result).
To me option #1 seems to be more suitable specially since there is an option to
disable
the status output b
long time.
Please check if this can be committed now or any other changes required.
Thanks and Regards,
Kumar Rajeev Rastogi
> -Original Message-
> From: MauMau [mailto:maumau...@gmail.com]
> Sent: 24 February 2014 15:31
> To: Rajeev rastogi
> Cc: pgsql-hackers@postgresql.org;
destination file for next command given in sequence”.
This has been in “Ready for committer” stage for long time.
Please check if this can be committed now or any other changes required.
Thanks and Regards,
Kumar Rajeev Rastogi
A, B. Wait queue: C.
>
> This looks good to me also.
I have tested the revised patch and found ready to be committed.
I am marking this as "Ready for Committer".
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
me in the comment as in:
>
> /*
> * make_absolute_path
> *
> * ...existing function descripton
> */
Added.
> (2)
> Add errno description as in:
>
> fprintf(stderr, _("could not get current working directory: %s\n",
> strerror(errno)));
Modified.
Please find the
, surround the error message output with
> #ifdef FRONTEND ... #else ... #endif. See some other source files in
> src/port.
Changed the patch as per your suggestion.
Now only one version of make_absolute_path there defined in src/port/path.c
Found one small memory leak in the existing funct
On 12 February 2014 12:16, KONDO Mitsumasa Wrote:
> Hi Rajeev,
>
> > (2014/01/29 17:31), Rajeev rastogi wrote:
> >> No Issue, you can share me the test cases, I will take the
> performance report.
> Attached patch is supported to latest pg_stat_statements. It inc
.
> > Thought?
>
> Sounds reasonable to me. Attached patch changes messages to the
> following:
>
> Process holding the lock: A. Wait queue: B.
> Processes holding the lock: A, B. Wait queue: C.
This looks good to me also.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent vi
he function description comment as per your suggestion.
> Then update the CommitFest entry with the latest patch and let me know
> of that. Then, I'll change the patch status to ready for committer.
I will update commitFest with the latest patch immediately after sendi
s per suggestion.
> (5)
> Change "file/path" in the comment of find_my_abs_path() to "path",
> because
> file is also a path.
Changed as per suggestion.
Please find the attached revised patch.
Thanks and Regards,
Kumar Rajeev Rastogi
pgctl_win32service_rel_dbpath
m>> wrote:
> >>> > On 21 January 2014 12:54, KONDO Mitsumasa
> >> >>> <mailto:kondo.mitsum...@lab.ntt.co.jp>> wrote:
> >>> >> Rebased patch is attached.
> >>> >
> >>> > Does this fix the Windows bug repor
Regards,
Kumar Rajeev Rastogi
unwanted_prototype.patch
Description: unwanted_prototype.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
; This is on purpose due to the rewording of the Message. In the first
> version the PID of the backend was missing.
>
> Thanks for the review!
>
Now patch looks fine to me. I am marking this as "Ready for Committer".
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
warning C4133:
'=' : incompatible types - from 'LWLockPadded *' to 'LWLock *'
1>.\src\backend\postmaster\postmaster.c(5856) : warning C4133: '=' :
incompatible types - from 'LWLock *' to 'LWLockPadded *'
Attached is the patch with the fix.
Thanks
2:54, KONDO Mitsumasa
> > <mailto:kondo.mitsum...@lab.ntt.co.jp>> wrote:
> > >> Rebased patch is attached.
> > >
> > > Does this fix the Windows bug reported by Kumar on 20/11/2013 ?
> Sorry, I was misunderstanding. First name of Mr. Rajeev Ra
avior as the meaning of message will be
list of all processes already holding the lock and processes waiting in queue
and
position of self process in wait-list. In above example, it will indicate that
process Y in on top of wait list.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
generic trap system.
I shall propose a better approach for this.
4. Send committing clients, a WARNING if they have committed a synchronous
transaction and we are in degraded mode.
5. Please add more if I am missing something.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sen
ase value will get tricky.
> Wrapping could probably be used as well, instead.
>
> > The number of times each cache line can be invalidated is bounded by
> > 8.
>
> Hm.. good point.
>
We are also planning to implement CSN based snapshot.
So I am curious to know whether any further development is happening on this.
If not then what is the reason?
Am I missing something?
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
apitalization and
> punctuation to match.
>
> Hm, I hope I fixed it in this version of the patch.
>
> > Lastly, is this information that we want to be shipping to clients?
> > Perhaps from a security standpoint that's not such a wise idea, and
> > errdetail_lo
hould change message to give all meaning i.e. which process
is owning lock and
Which process is already in queue.
2. Can we give a better name to new variable 'buf1'?
3. Do we need to take performance reading to see if any impact?
4. Do we require documentation?
Thanks and
suggestion. It really avoid one
level of copy.
I have seen that the similar mechanism is used in many places where
join_path_components() is called. So I think it should be OK to use in our case
also.
I have made the necessary changes for the same.
I have attached the c
lable?
>Or is there something else also which needs to be done along with
>above 2 points to make it possible.
Since there is not WAL written for ALTER SYSTEM SET command,
then
it should be able to handle this command even though sync
replica is
tandby is restaring, you
> probably want to wait instead of degrading.
I think if we support to have some external SQL-callable functions as Heikki
suggested to degrade instead of auto-degrade then user can handle at-least some
of the above scenarios if not all based on their experience and observation.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lready connected to it before going to
>standalone mode, if it continues to send data then I think naming it
> as
>'enable_standalone_master' is not good.
Yes we can change name to something more appropriate, some of them are:
1. enable_async_master
2. sync_standalon
being done for executable file.
Attached is the patch with the fix.
Please provide your opinion.
I will add this to Jan 2014 CommitFest.
Thanks and Regards,
Kumar Rajeev Rastogi
pgctl_win32service_rel_dbpath.patch
Description: pgctl_win32service_rel_dbpath.patch
--
Sent via pgsql-hackers mailing list
On 12th December 2013, Rajeev Rastogi Wrote:
>On 9th December, Amit Khandelkar wrote:
>>1. slashcopyissuev1.patch :- This patch fixes the \COPY issue.
>>You have removed the if condition in this statement, mentioning that it is
>>always true now:
>>-
On 12 December 2013, Heikki Linnakangas Wrote:
> Further Review of this patch:
>
> I have done few more cosmetic changes in your patch, please find
> the updated patch attached with this mail.
> Kindly check once whether changes are okay.
> >>>
> >>> Changes are fine.
if you were expecting any other test cases?
>I don't think we need to do any doc changes, because the doc already mentions
>that COPY should show the COUNT tag, and does not mention anything specific to
>client-side COPY.
OK.
Please provide you opinion, based on which I shall prepare new patch and share
the same.
Thanks and Regards,
Kumar Rajeev Rastogi
Please find the attached two separate patches:
1. slashcopyissuev1.patch :- This patch fixes the \COPY issue.
2. initialcopyissuev1_ontopofslashcopy.patch : Fix for "COPY table FROM
STDIN/STDOUT doesn't show count tag".
Thanks and Regards,
Kumar Rajeev Rastogi
slashco
es are okay.
> >
> > Changes are fine. Thanks you.
>
> I have uploaded the latest patch in CF app and marked it as Ready For
> Committer.
Thanks a lot.
Thanks and Regards,
Kumar Rajeev Rastogi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o control file.
> >> b. if you carefully look at original link
> >> (http://www.postgresql.org/message-id/1283277511-sup-2...@alvh.no-
> >> ip.org),
> >> these values are not getting displayed in pg_control values
> section.
> >>
> >>
xt (In second section ), you can
> remove all text after that point.
Done.
> 3.
> ! printf(_(" -n no update, just show extracted control
> values (for testing) and to be reset values of parameters(if
> given)\n")); I find this line too long and elaborative
On 27 November 2013, Naoya Anzai wrote:
> Hi, Rajeev
>
> > > I tested the latest patch. My observation is:
> > > If we give relative data directory path while registering the
> > > service, then service start fails.
> > > But same works if the data directory is absolute path.
> > >
> > > Loo
pass them as their copyStream parameter
>depending upon whether it is
>first cycle or not.
OK. I have changed as per your suggestion.
Also I had removed the below line
if (copystream == pset.cur_cmd_source)
from the function handleCopyIn in my last patc
1 - 100 of 118 matches
Mail list logo
