ocumentation in the patch indicates that
this patch will only fire Update statement level triggers which is
odd.
Note in docs about Insert On Conflict
"Note that with an INSERT with an ON CONFLICT DO UPDATE clause, both
INSERT and UPDATE statement level trigger will be fired.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e?
Basically, if there is no matching partition, then move it to default partition.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar wrote:
> On 11 May 2017 at 17:23, Amit Kapila wrote:
>> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar
>> wrote:
>>> On 4 March 2017 at 12:49, Robert Haas wrote:
>>>> On Thu, Mar 2, 2017 at 11:53 AM, Amit K
On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar wrote:
> On 11 May 2017 at 17:24, Amit Kapila wrote:
>> Few comments:
>> 1.
>> Operating directly on partition doesn't allow update to move row.
>> Refer below example:
>> create table t1(c1 int) partition b
On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote:
> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar
> wrote:
>> On 11 May 2017 at 17:24, Amit Kapila wrote:
>>> Few comments:
>>> 1.
>>> Operating directly on partition doesn't allow update to move ro
up with something doable without a big
architecture change.
What is your take on this point now?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
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, May 12, 2017 at 10:49 AM, Amit Khandekar wrote:
> On 12 May 2017 at 08:30, Amit Kapila wrote:
>> On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar
>> wrote:
>
>> If we try to compare it with the non-partitioned update,
>> there also it is internally a delet
think of defining separate portable hash functions which can be
used for the purpose of hash partitioning?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ql.org/message-id/CAFiTN-tkX6gs-jL8VrPxg6OG9VUAKnObUq7r7pWQqASzdF5OwA%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
perations, I think we hold it over multiple
kernel calls.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
just
end the query execution. Also, even if it is okay, there doesn't seem
to be a way by which a parallel worker can communicate the error back
to master backend, rather it will just exit silently which is not
right.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb
as well document instead that we don't
> currently support routing tuples with NULL values in the partition key
> through a range-partitioned table and so NULL values cause error.
>
Can't we allow NULL to get inserted into the partition (leaf
partition) if the user uses the
27;t this cause the hash indexes to be invalided in the old cluster
> rather than the new one?
>
oops. copy-paste. It passed in my testing because I have not used any
different options (like port number) for old or new server.
> This might need a visit from pgindent in one or two places, too.
>
I have run pgindent before sending the previous version, but will
again verify the same.
I will send an updated patch once we agree on above points.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, May 16, 2017 at 3:26 PM, Amit Langote
wrote:
> On 2017/05/16 4:29, Robert Haas wrote:
>> On Mon, May 15, 2017 at 9:12 AM, Amit Kapila wrote:
>>> Can't we allow NULL to get inserted into the partition (leaf
>>> partition) if the user uses the partition name
On Tue, May 16, 2017 at 5:14 PM, Robert Haas wrote:
> On Tue, May 16, 2017 at 7:31 AM, Amit Kapila wrote:
>
>> I will send an updated patch once we agree on above points.
>
> Sounds good.
>
Attached patch addresses all the comments as discussed.
--
With Regards,
Amit
uential Scan patch and I think
some other databases uses some similar technique for this problem.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ay be wrong, but the execution state initialization
> routines are written with the assumption that all the workers start
> simultaneously?
>
No such assumptions, workers started later can also join the execution
of the query.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.en
> delete and can change the row multiple time and defining such
> behaviour can be complicated.
>
If we have to go by this theory, then the option you have preferred
will still execute BR triggers for both delete and insert, so input
row can still be changed twice.
--
With Regards,
Amit Ka
On Mon, May 15, 2017 at 5:28 PM, Robert Haas wrote:
> On Fri, May 12, 2017 at 3:07 AM, Amit Kapila wrote:
>> I agree with you that it might not be straightforward to make it work,
>> but now that earliest it can go is v11, do we want to try doing
>> something other tha
t; commands in a symmetric manner.
>
+1. Why not similar behavior for any other statements executed in
this module by do_sql_command?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 17, 2017 at 5:17 PM, Robert Haas wrote:
> On Wed, May 17, 2017 at 6:29 AM, Amit Kapila wrote:
>> I think we can do this even without using an additional infomask bit.
>> As suggested by Greg up thread, we can set InvalidBlockId in ctid to
>> indicate such an
On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar wrote:
> On Wed, May 17, 2017 at 3:15 PM, Amit Kapila wrote:
>>> Earlier I thought that option1 is better but later I think that this
>>> can complicate the situation as we are firing first BR update then BR
>>> delete a
shown any noticeable
improvement. I am aware of all this because I and Dilip were offlist
involved in brainstorming ideas with Rafia to improve the speed of
Gather. I think it might have been better to show the results of
ideas that didn't work out, but I guess Rafia hasn't shared thos
On Sat, May 20, 2017 at 2:24 AM, Robert Haas wrote:
> On Tue, May 16, 2017 at 9:25 AM, Amit Kapila wrote:
>> On Tue, May 16, 2017 at 5:14 PM, Robert Haas wrote:
>>> On Tue, May 16, 2017 at 7:31 AM, Amit Kapila
>>> wrote:
>>>> I will send an upda
On Thu, May 18, 2017 at 7:56 PM, Robert Haas wrote:
> On Wed, May 17, 2017 at 6:57 AM, Amit Kapila wrote:
>> +1. Why not similar behavior for any other statements executed in
>> this module by do_sql_command?
>
> The other cases are not quite the same situation. It woul
On Wed, May 17, 2017 at 9:43 PM, Remi Colinet wrote:
>
> 2017-05-13 14:38 GMT+02:00 Amit Kapila :
>>
>> On Wed, May 10, 2017 at 10:10 PM, Remi Colinet
>> wrote:
>> >
>> > Parallel queries can also be monitored. The same mecanism is used to
>> >
On Sun, May 21, 2017 at 5:26 AM, Bruce Momjian wrote:
> On Fri, May 19, 2017 at 04:54:27PM -0400, Robert Haas wrote:
>> On Tue, May 16, 2017 at 9:25 AM, Amit Kapila wrote:
>> > On Tue, May 16, 2017 at 5:14 PM, Robert Haas wrote:
>> >> On Tue, May 16, 2017 at 7:31
eme, but only to benefit
> index-only scans? Applied to a hash index, that might offer another useful
> kind of multicolumn support, which otherwise seems limited to queries
> where you have the exact values of all indexed columns.
>
Agreed, but even if we have any such syntax, makin
On Mon, May 22, 2017 at 2:54 PM, Rafia Sabih
wrote:
> On Wed, May 17, 2017 at 2:57 PM, Amit Kapila wrote:
>> On Tue, May 16, 2017 at 2:14 PM, Ashutosh Bapat
>> wrote:
>>> On Mon, May 15, 2017 at 9:23 PM, Robert Haas wrote:
>>>
>>> Also, looking at the
KEND
builds). I think it makes sense to have retry mechanism for
EXEC_BACKEND builds, so done that way in the patch. Yet another point
which needs some thought is for reattach operation, before retrying do
we want to reserve the shm by using VirtualAllocEx?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
win_shm_retry_reattach_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 24, 2017 at 2:47 PM, Amit Khandekar wrote:
> On 18 May 2017 at 16:52, Amit Kapila wrote:
>> On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar wrote:
>>> On Wed, May 17, 2017 at 3:15 PM, Amit Kapila
>>> wrote:
>>>>> Earlier I thought that opt
On Wed, May 24, 2017 at 8:14 PM, Amit Kapila wrote:
> On Wed, May 24, 2017 at 2:47 PM, Amit Khandekar
> wrote:
>>
>> By now, majority of the opinions have shown that they do not favour
>> two triggers getting fired on a single update. Amit, do you consider
>&
On Wed, May 24, 2017 at 6:59 PM, Michael Paquier
wrote:
> On Tue, May 23, 2017 at 8:14 AM, Amit Kapila wrote:
>> So it seems both you and Tom are leaning towards some sort of retry
>> mechanism for shm reattach on Windows. I also think that is a viable
>> option to nega
I will change
the patch to use 100 retries unless people have other opinions.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 25, 2017 at 8:01 PM, Tom Lane wrote:
> Amit Kapila writes:
>> Yes, I also share this opinion, the shm attach failures are due to
>> randomization behavior, so sleep won't help much. So, I will change
>> the patch to use 100 retries unless people have other
On Fri, May 26, 2017 at 5:30 AM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila
>> Yes, I also share this opinion, the shm attach failures are due to
>> randomization behavior, so
gt;
Yeah, I think this is quite suspicious. This seems to indicate that
not all WAL records are replicated before the switchover. What is the
value of "synchronous_commit" you are using? I think you somehow need
to ensure before switchover that all the WAL is replicated to ensure
this is not a setup problem.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
elPlan that might help you in
your work.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, May 27, 2017 at 10:18 PM, Vladimir Borodin wrote:
>
> 26 мая 2017 г., в 21:39, Amit Kapila написал(а):
>
> I think you somehow need
> to ensure before switchover that all the WAL is replicated to ensure
> this is not a setup problem.
>
>
> Well, actually cl
On Mon, May 29, 2017 at 11:20 AM, Amit Khandekar wrote:
> On 24 May 2017 at 20:16, Amit Kapila wrote:
>> On Wed, May 24, 2017 at 8:14 PM, Amit Kapila wrote:
>>> Apart from above, there is one open issue [1]
>>>
>>
>> Forget to mention the li
control exists but is broken or unknown version; ignoring it
>
This appears to be an expected error as you are trying to use a
version of binaries that doesn't match the version stored in
pg_control. What makes you think above is a valid usage and should
pass?
--
With Regards,
Am
On Fri, May 26, 2017 at 8:21 PM, Magnus Hagander wrote:
>
> On Fri, May 26, 2017 at 8:24 AM, Michael Paquier
> wrote:
>>
>> On Fri, May 26, 2017 at 8:20 AM, Amit Kapila
>> wrote:
>> > I think the real question here is, shall we backpatch this fix or we
>
On Mon, May 29, 2017 at 3:20 PM, tushar wrote:
> On 05/29/2017 03:10 PM, Amit Kapila wrote:
>>
>> What makes you think above is a valid usage and should
>> pass?
>
> with earlier versions ,for instance - v.96 v/s v9.5 ,pg_resetwal was giving
> pg_control values
On Mon, May 29, 2017 at 9:30 PM, Tom Lane wrote:
> Amit Kapila writes:
>> I think this happens due to commit
>> f82ec32ac30ae7e3ec7c84067192535b2ff8ec0e which renames pg_xlog to
>> pg_wal. It does take care of making some of the modules like
>> pg_basebackup to
ionality, it should be added as a separate patch as it has its
own set of problems that needs to be solved.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
d.
>
> However, in that case if I understand correctly GetOldestXmin()
> actually returns latestCompletedXid + 1 as follows;
>
Isn't there another gotcha in above part of the comment, shouldn't it
say rel != NULL? AFAICS, when rel is NULL, it considers all databases
not only cu
he
parallel mode, it will act as a safeguard.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 1, 2017 at 9:34 PM, Andres Freund wrote:
> On 2017-06-01 21:23:04 +0530, Amit Kapila wrote:
>> On a related note, I think it might be better to have an
>> IsInParallelMode() check in this case as we have at other places.
>> This is to ensure that if this command i
a new thread.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
do batched
writes in shm queue to avoid the shm queue communication overhead) in
a similar way.
[1] -
https://www.postgresql.org/message-id/CAOGQiiMwhOd5-iKZnizn%2BEdzZmB0bc3xa6rKXQgvhbnQ29zCJg%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
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, Jun 2, 2017 at 6:38 PM, Robert Haas wrote:
> On Fri, Jun 2, 2017 at 9:01 AM, Amit Kapila wrote:
>> Your reasoning sounds sensible to me. I think the other way to attack
>> this problem is that we can maintain some local queue in each of the
>> workers when th
o understand the code in the way it is
currently written, but I can invert the check if you find it is easier
to read and understand that way.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 1, 2017 at 10:16 PM, Andres Freund wrote:
> On 2017-06-01 21:37:56 +0530, Amit Kapila wrote:
>> On Thu, Jun 1, 2017 at 9:34 PM, Andres Freund wrote:
>> > On 2017-06-01 21:23:04 +0530, Amit Kapila wrote:
>> >> On a related note, I think
On Fri, Jun 2, 2017 at 7:20 PM, Petr Jelinek
wrote:
> On 02/06/17 15:37, Amit Kapila wrote:
>>
>> No, it is to avoid calling free of memory which is not reserved on
>> retry. See the comment:
>> + * On the first try, release memory region reservation that was ma
I decided to forbid referencing columns by numbers for tables, because those
> numbers could contain gaps. Also, I forbid altering statistics target for
> non-expression index columns, because it has no effect.
>
In order to avoid losing track of this patch, I think it is better to
add it in
On Sun, Jun 4, 2017 at 10:11 AM, Tom Lane wrote:
> Amit Kapila writes:
>> In order to avoid losing track of this patch, I think it is better to
>> add it in open items list for 10.
>
> This is an entirely new feature, not a bug fix, and thus certainly not an
> open item f
On Sat, Jun 3, 2017 at 9:34 PM, Andres Freund wrote:
> Hi,
>
> On 2017-06-03 17:40:08 +0530, Amit Kapila wrote:
>> The standard_planner check is sufficient to not generate parallel
>> plans for such statements, but it won't prevent if such commands
>> (which s
On Mon, Jun 5, 2017 at 4:00 AM, Tom Lane wrote:
> Amit Kapila writes:
>> Okay, I have added the comment to explain the same. I have also
>> modified the patch to adjust the looping as per your suggestion.
>
> I took a quick look at this, and it seems rather beside the po
) on
the argument of code simplicity, but it sounds slightly odd behavior.
> But I think we want to wait for other's
> opinion because it is quite understandable that two triggers firing on
> the same partition sounds odd.
>
Yeah, but I think we have to rely on docs in this case as behavior is
not intuitive.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 1, 2017 at 3:25 AM, Robert Haas wrote:
> On Mon, May 29, 2017 at 5:26 AM, Amit Kapila wrote:
>>> But I think, we can also take step-by-step approach even for v11. If
>>> we agree that it is ok to silently do the updates as long as we
>>> document the beh
On Mon, Jun 5, 2017 at 9:15 AM, Tom Lane wrote:
> Amit Kapila writes:
>
>> I think the same problem can happen during reattach as well.
>> Basically, MapViewOfFileEx can fail to load image at predefined
>> address (UsedShmemSegAddr).
>
> Once we've successfully
On Mon, Jun 5, 2017 at 4:58 PM, Magnus Hagander wrote:
> On Mon, Jun 5, 2017 at 1:16 PM, Amit Kapila wrote:
>>
>> On Mon, Jun 5, 2017 at 9:15 AM, Tom Lane wrote:
>> > Amit Kapila writes:
>> >
>> >> I think the same problem can happen during reatt
On Mon, Jun 5, 2017 at 7:26 PM, Tom Lane wrote:
> Amit Kapila writes:
>> Sure. I think it is slightly tricky because specs don't say clearly
>> how ASLR can impact the behavior of any API and in my last attempt I
>> could not reproduce the issue.
>
>> I can tr
On Tue, Jun 6, 2017 at 11:54 PM, Robert Haas wrote:
> On Mon, Jun 5, 2017 at 2:51 AM, Amit Kapila wrote:
>>> Greg/Amit's idea of using the CTID field rather than an infomask bit
>>> seems like a possibly promising approach. Not everything that needs
>>> b
itional risk of postmaster startup
> failure.
>
I think it won't create an additional risk, because the idea is that
if we fail to map the shm segment at a predefined address, then we
will allow the system to choose the initial address as we are doing
now. So, it can reduce chances of do
cause a problem.
>
> Another idea is that the commit in question is managing to corrupt
> BackgroundWorkerList somehow.
>
I don't think so because this problem has been reported previously as
well [1][2] even before the commit in question.
[1] -
https://www.postgresql.org/messag
ng the same,
then we can request the author to post a rebased version if it doesn't
apply.
[1] -
https://www.postgresql.org/message-id/CAD__OuiwEi5sHe2wwQCK36Ac9QMhvJuqG3CfPN%2BOFCMb7rdruQ%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
bunch of cosmetic fixes, plus I
> adjusted things so that do_sql_command() is more interruptible. I
> tested it manually and it seems to work OK. I'll commit and
> back-patch this version, barring objections or further suggestions for
> improvement.
>
No objections from me, update
On Thu, Jun 8, 2017 at 1:33 AM, Robert Haas wrote:
> On Wed, Jun 7, 2017 at 5:46 AM, Amit Kapila wrote:
>> As far as I understand, it is to ensure that for deleted rows, nothing
>> more needs to be done. For example, see the below check in
>> ExecUpdate/ExecDelete.
>
r fixing
> corrupted pages
> or is there a better way not to loose data?
>
I haven't looked in detail, but it sounds slightly risky proposition
to manipulate the tuples by writing C functions of the form you have
in your code. I would have preferred some way to avoid this problem
by e
data files due to which the WAL has not been
replayed on replicas? If so, why the pg_control file is copied, it's
size shouldn't have changed?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Thu, Jun 8, 2017 at 10:40 PM, Robert Haas wrote:
> On Thu, Jun 8, 2017 at 7:01 AM, Amit Kapila wrote:
>> On Thu, Jun 8, 2017 at 1:33 AM, Robert Haas wrote:
>>> On Wed, Jun 7, 2017 at 5:46 AM, Amit Kapila wrote:
>>>> As far as I understand, it is to ensure
("saved metadata info of %d blocks", num_blocks)));
It doesn't seem like a good idea to log this info at each dump
interval. How about making this as a DEBUG1 message?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsq
On Fri, Jun 9, 2017 at 7:48 PM, Amit Khandekar wrote:
> On 9 June 2017 at 19:10, Amit Kapila wrote:
>> On Thu, Jun 8, 2017 at 10:40 PM, Robert Haas wrote:
>>> On Thu, Jun 8, 2017 at 7:01 AM, Amit Kapila wrote:
>>>>
>>>> I think before doing above
On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin wrote:
>
> 8 июня 2017 г., в 17:03, Amit Kapila написал(а):
>
> On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sarafannikov
> wrote:
>
>
> Why didn't rsync made the copies on master and replica same?
>
>
> Bec
ocknum);
+
+ if (write(fd, buf, buflen) < buflen)
+ {
+ int save_errno = errno;
+
+ CloseTransientFile(fd);
+ unlink(transient_dump_file_path);
+ errno = save_errno;
+ ereport(ERROR,
+ (errcode_for_file_access(),
+ errmsg("could not write to file \"%s\": %m",
+ transient_dump_file_path)));
+ }
I
On Mon, Jun 12, 2017 at 9:01 PM, Vladimir Borodin wrote:
>
> 12 июня 2017 г., в 13:19, Amit Kapila написал(а):
>
> On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin wrote:
>
>
> 8 июня 2017 г., в 17:03, Amit Kapila написал(а):
>
> On Thu, Jun 8, 2017 at 6:49 PM, Dm
d to start/stop the new
> server since pg_upgrade will do that safely already.
>
!
! Also, if upgrading standby servers, change wal_level
! to replica in the postgresql.conf file on
! the new cluster.
I think it is better to indicate that this is required for the master
On Wed, Jun 14, 2017 at 8:44 PM, Bruce Momjian wrote:
> On Wed, Jun 14, 2017 at 07:45:17PM +0530, Amit Kapila wrote:
>> > Now, it seems we later added a doc section early on that talks about
>> > "Verify standby servers" so I have moved the wal_level section into t
t we are seeing in
this case.
[1] -
https://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t to screw memcmp optimization we have in
this function, so do this ICU specific checking after memcmp check.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ss
was running: select stringu1::int2 from tenk1 where unique1 = 1;
2017-06-13 16:45:02.652 EDT [59404dec.2d9c:8] LOG: terminating any
other active server processes
Error "could not map dynamic shared memory segment" is due to query
"EXPLAIN .. SELECT * FROM tenk1" and
On Wed, Aug 16, 2017 at 5:04 PM, Robert Haas wrote:
> On Wed, Aug 16, 2017 at 7:23 AM, Amit Kapila wrote:
>> On Tue, Aug 15, 2017 at 7:15 PM, Robert Haas wrote:
>>> On Sat, Aug 12, 2017 at 9:18 AM, Amit Kapila
>>> wrote:
>>>> I think skipping a generati
On Mon, Aug 21, 2017 at 1:44 PM, Haribabu Kommi
wrote:
>
>
> Thanks for adding more details. It is easy to understand.
>
> I marked the patch as ready for committer in the commitfest.
>
Thank you.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Mon, Aug 21, 2017 at 12:58 PM, Haribabu Kommi
wrote:
>
> On Sun, Aug 13, 2017 at 5:17 PM, Amit Kapila
> wrote:
>>
>>
>> Also, it is quite possible that some of the storage Am's don't even
>> want to return bool as a parameter from HeapTupleSatisfies*
On Mon, Aug 21, 2017 at 3:15 PM, Simon Riggs wrote:
> On 21 August 2017 at 10:08, Amit Kapila wrote:
>
>> Thoughts?
>
> This seems like a very basic problem for parallel queries.
>
> The problem seems to be that we are calculating the cost of the plan
> rather
On Tue, Aug 22, 2017 at 2:28 PM, Ashutosh Sharma wrote:
> On Sat, Aug 19, 2017 at 11:37 AM, Amit Kapila wrote:
>> On Fri, Aug 11, 2017 at 6:51 PM, Ashutosh Sharma
>> wrote:
>>>>
>>>> 7.
>>>> _hash_kill_items(IndexScanDesc scan)
>>>
On Tue, Aug 22, 2017 at 7:24 PM, Ashutosh Sharma wrote:
> On Tue, Aug 22, 2017 at 3:55 PM, Amit Kapila wrote:
>
> Okay, I got your point now. I think, currently in _hash_kill_items(),
> if an overflow page is pinned we do not check if it got modified since
> the last read or
>
On Wed, Aug 23, 2017 at 11:05 AM, Haribabu Kommi
wrote:
>
>
> On Mon, Aug 21, 2017 at 7:25 PM, Amit Kapila
> wrote:
>>
>> On Mon, Aug 21, 2017 at 12:58 PM, Haribabu Kommi
>> wrote:
>> >
>> > On Sun, Aug 13, 2017 at 5:17 PM, Amit Kapila
>>
ink this was required in some initial versions
of gather node patch where we were thinking of having a single node
(instead of what we have now that Gather node and beneath there will
be partial scan node) to perform parallel scans.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://w
ed
> to need a dependency on the parent Gather or GatherMerge's rescan param
> --- and the planner will now bitch if a parallel_aware plan node is not
> under any such Gather. Is this reasonable?
I think so.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 28, 2017 at 6:01 PM, Tom Lane wrote:
> Amit Kapila writes:
>> With this change, it is quite possible that during rescans workers
>> will not do any work.
>
> Um, what's different about that than before?
>
Earlier, we perform the rescan of all the
On Mon, Aug 28, 2017 at 6:34 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Mon, Aug 28, 2017 at 6:01 PM, Tom Lane wrote:
>>> Um, what's different about that than before?
>
>> Earlier, we perform the rescan of all the nodes before ExecProcNode,
>> so wor
state of all the nodes below
gather at that place, otherwise, it will be more or less like we are
forcing rescan of each node. I think there we can reset the shared
parallel state of parallel-aware nodes (or anything related) and then
allow rescan to reset the master backend specific
On Wed, Aug 30, 2017 at 2:43 AM, Robert Haas wrote:
> On Tue, Jul 4, 2017 at 12:33 AM, Amit Kapila wrote:
>> I have updated the patch to support wait events and moved it to upcoming CF.
>
> This patch doesn't apply any more, but I made it apply with a hammer
> and then di
On Tue, Aug 29, 2017 at 10:05 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Tue, Aug 29, 2017 at 8:32 AM, Robert Haas wrote:
>>> There's already ExecParallelReinitialize, which could be made to walk
>>> the nodes in addition to what it does already, but I d
s.
>
I am able to reproduce this without involving session authorization
guc as well. One needs to drop the newly created role from another
session, then also we can see the same error.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hacker
On Mon, Aug 21, 2017 at 2:40 PM, Amit Kapila wrote:
> On Mon, Aug 21, 2017 at 1:44 PM, Haribabu Kommi
> wrote:
>>
>>
>> Thanks for adding more details. It is easy to understand.
>>
>> I marked the patch as ready for committer in the commitfest.
>>
R
ormance tests.
> OK, these tests seem to show that this is still working. Committed,
> again. Let's hope this attempt goes better than the last one.
>
Thanks for committing.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers m
.
I am not sure whether we need to bother about this, but I thought it
might help in choosing the approach to fix this problem.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
901 - 1000 of 3368 matches
Mail list logo
