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
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
e know if any issue or I am missing something.
Thanks and Regards,
Kumar Rajeev Rastogi
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
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
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
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
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
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
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
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 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
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 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
(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
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
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
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
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
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
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
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
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
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
; 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
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
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
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
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
.
> > 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
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
, 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
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
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
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
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;
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
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
the final result from server get printed before
clearing the result.
Please find the patch for the same and let me know your suggestions.
Thanks and Regards,
Kumar Rajeev Rastogi
copydefect.patch
Description: copydefect.patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On 21 October 2013 20:48, Robert Haas wrote:
>On Fri, Oct 18, 2013 at 7:37 AM, Rajeev rastogi
>wrote:
>> From the following mail, copy behaviour between stdin and normal file
>> having some inconsistency.
>>
>>
>> http://www.postgresql.org/message-
Thanks and Regards,
Kumar Rajeev Rastogi
pg_resetxlogsection.patch
Description: pg_resetxlogsection.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 Fri, 08 November 2013 09:47
> On Tue, Nov 5, 2013 at 3:20 PM, Rajeev rastogi
> wrote:
> > On execution of pg_resetxlog using the option -n
> >
> > 1. It will display values in two section.
> >
> > 2. First section wil
every command read but it will add extra cost for each query execution.
Any comments?
Thanks and Regards,
Kumar Rajeev Rastogi
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
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
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
_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
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
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
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
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
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
e because of which this issue
has not yet been observed.
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 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
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
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
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
> > 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
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
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 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.
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
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:
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
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
ference to
SPI_execute i.e. I will mention that count has same interpretation as in
SPI_execute.
3. SPI_execp: Here we can give just reference to SPI_execute i.e. I will
mention that count has same interpretation as in SPI_execute.
Please provide your feedback.
Thanks and Regards,
Kumar Rajeev Ras
to decide whether synchronous
standby has gone down. i.e. only after expiry of
wal_sender_timeout, the master will switch from sync mode to standalone mode.
Please provide your opinion or any other expectation out of this patch.
I will add the same to November commitFest.
Thanks and Regards,
Ku
On 18 November 2013, Amit Khandekar wrote:
>> On 18 October 2013 17:07, Rajeev rastogi
>> mailto:rajeev.rast...@huawei.com>> wrote:
>>From the following mail, copy behaviour between stdin and normal file having
>>some inconsistency.
>>
>
On 18 November 2013, Amit Khandekar wrote:
>> On 18 October 2013 17:07, Rajeev rastogi
>> mailto:rajeev.rast...@huawei.com>> wrote:
>>From the following mail, copy behaviour between stdin and normal file having
>>some inconsistency.
>>
>
On 19 November 2013, Amit Khandekar wrote:
>On 18 November 2013 18:00, Rajeev rastogi
>mailto:rajeev.rast...@huawei.com>> wrote:
>>On 18 November 2013, Amit Khandekar wrote:
> >>Please find the patch for the same and let me know your s
ies cleanly to master HEAD.
2. No Compilation Warning.
3. It works as per the patch expectation.
One suggestion:
Instead of using sizeof(cmdLine),
a. Can't we use strlen (hence small 'for' loop).
b. Or use memmove to move one byte.
Thanks and Regards,
Kumar Rajeev Rastogi
time *
avtime));
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
am;
> success = SendQuery(query.data);
> *override_file = save_file;
>But the way SendQuery() itself processes the results and prints them, is
>conflicting with the above.
>So I think it is best to solve this as a different issue, and we should , for
>this
then same can be used to reset value in SendQuery
or ProcessResult.
Please let me know which approach is OK or if any other approach suggested.
Based on feedback I shall prepare the new patch and share the same.
Thanks and Regards,
Kumar Rajeev Rastogi
On Sat, Nov 9, 2013, Amit Kapila wrote
> On Fri, Nov 8, 2013 at 10:37 AM, Rajeev rastogi
> mailto:rajeev.rast...@huawei.com>> wrote:
> > On Fri, 08 November 2013 09:47
> >
> >> On Tue, Nov 5, 2013 at 3:20 PM, Rajeev rastogi
> >> mailto:raj
es like
./psql -d postgres -c "\copy tbl to
'/home/rajeev/9.4gitcode/install/bin/data/temp.txt'; copy tbl from stdin;"
Inside the function ProcessResult, we check that if it is the second cycle and
result status is COPY OUT or IN, then we reset the value of
_psqlSettings-&
But same works if the data directory is absolute path.
Looks like an existing issue. May be we need to internally convert
relative data path to absolute.
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
n flag as well, otherwise this utility will have 2 format's to
> display values?
Yes you are right. Now printing the values in two section in two cases:
a. -n is given or
b. If we had to guess and -f not given.
Please let know your opinion.
Thanks and Regards,
Kumar Rajeev
On 25 November 2013, Rajeev Rastogi Wrote:
> > > One suggestion:
> > > Instead of using sizeof(cmdLine),
> > > a. Can't we use strlen (hence small 'for' loop).
> > > b. Or use memmove to move one byte.
> >
> > I looked at this pa
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
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
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
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.
> >>
> >>
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
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
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
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.
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:
>>-
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 118 matches
Mail list logo
