TAMP('2016-06-13 99:99:99', '-MM-DD HH24:MI:SS');
>> SELECT TO_TIMESTAMP('2016-02-30 15:43:36', '-MM-DD HH24:MI:SS');
>
>
>I attached second patch "0002-to-timestamp-validation-v2.patch". With it
>PostgreSQL perform additional c
On Friday, August 19, 2016 12:42 AM, Robert Haas wrote:
>On Wed, Aug 17, 2016 at 10:35 AM, amul sul wrote:
>
>
>> Hmm. I haven't really looked into the code, but with applying both patches
>> it looks precisely imitate Oracle's behaviour. Thanks.
>
>
hecks for date and time. But as I wrote
>there is another patch in the thread "to_date_valid()" wich differs from
>this patch.
@community : I am not sure what to do with this patch, should we keep it as
separate enhancement?
Regards,
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
+ prev_type;
Regards,
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
wing line:
>>
>> 256 + prev_type;
>
>
>You are right. I assigned to prev_type NODE_TYPE_SPACE to be able to
>execute such query:
>
>
>SELECT to_timestamp('---2000JUN', ' MON');
>
>
>Will be it a proper behaviour
gt;>>
>>> Will be it a proper behaviour?
>>
>>
>>
>> Looks good to me, no one will complain if something working on PG but not
>> on Oracle.
>
>
> Thanks. I've created the entry in https://commitfest.postgresql.org/10/713/
> . You can add
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Note for committer : There are unnecessary files (cube_1.out, cu
On Fri, Sep 16, 2016 at 10:01 PM, Artur Zakirov
wrote:
> On 25.08.2016 13:26, amul sul wrote:
>>>
>>> Thanks. I've created the entry in
>>> https://commitfest.postgresql.org/10/713/
>>> . You can add yourself as a reviewer.
>>>
>>
>&
On Fri, Oct 6, 2017 at 5:35 PM, Jesper Pedersen
wrote:
> Hi Amul,
>
> Could you rebase on latest master ?
>
Sure will post that soon, but before that, I need to test hash partitioning
with recent partition-wise join commit (f49842d1ee), thanks.
Regards,
Amul
--
Sent via pgsql-hackers mailing
On Sat, Oct 7, 2017 at 5:22 PM, amul sul wrote:
> On Fri, Oct 6, 2017 at 5:35 PM, Jesper Pedersen
> wrote:
>> Hi Amul,
>>
>> Could you rebase on latest master ?
>>
>
> Sure will post that soon, but before that, I need to test hash partitioning
> with recent
On Mon, Oct 9, 2017 at 5:51 PM, Ashutosh Bapat
wrote:
> On Mon, Oct 9, 2017 at 4:44 PM, amul sul wrote:
>
Thanks Ashutosh for your review, please find my comment inline.
>
>> 0002 few changes in partition-wise join code to support
>> hash-partitioned table as we
On Tue, Oct 10, 2017 at 3:32 PM, amul sul wrote:
> On Mon, Oct 9, 2017 at 5:51 PM, Ashutosh Bapat
> wrote:
>> On Mon, Oct 9, 2017 at 4:44 PM, amul sul wrote:
>>
>
> Thanks Ashutosh for your review, please find my comment inline.
>
>>
>>> 0002 few chan
On Tue, Oct 10, 2017 at 3:42 PM, Ashutosh Bapat
wrote:
> On Tue, Oct 10, 2017 at 3:32 PM, amul sul wrote:
>
>>> +hash_part? true : key->parttypbyval[j],
>>> +key->parttyplen[j]);
>>> pa
On Thu, Oct 12, 2017 at 6:31 AM, Robert Haas wrote:
> On Tue, Oct 10, 2017 at 7:07 AM, amul sul wrote:
>> How about the attached patch(0003)?
>> Also, the dim variable is renamed to natts.
>
> I'm not sure I believe this comment:
>
> +/*
> +
On Fri, Oct 13, 2017 at 3:00 AM, Andres Freund wrote:
> On 2017-10-12 17:27:52 -0400, Robert Haas wrote:
>> On Thu, Oct 12, 2017 at 4:20 PM, Andres Freund wrote:
>> >> In other words, it's not utterly fixed in stone --- we invented
>> >> --load-via-partition-root primarily to cope with circumstan
On Tue, Oct 24, 2017 at 5:00 PM, Andres Freund wrote:
> On 2017-10-24 12:43:12 +0530, amul sul wrote:
>> I tried to get suggested SMHasher[1] test result for the hash_combine
>> for 32-bit and 64-bit version.
>>
>> SMHasher works on hash keys of the form {0}, {0,1}
On Tue, Oct 31, 2017 at 9:54 AM, Robert Haas wrote:
> On Mon, Oct 30, 2017 at 5:52 PM, amul sul wrote:
>> Actually, int4[] is also inappropriate type as we have started using a 64bit
>> hash function. We need something int8[] which is not available, so that I
>> have us
On Thu, Nov 2, 2017 at 1:35 PM, Robert Haas wrote:
> On Wed, Nov 1, 2017 at 3:46 PM, amul sul wrote:
>> Although partition constraints become more simple, there isn't any
>> performance
>> gain with 0005 patch. Also I am little skeptic about logic in 0005 where
Hi Dilip,
v6 patch:
42 + /*
43 +* Estimate number of hashtable entries we can have within
maxbytes. This
44 +* estimates the hash cost as sizeof(PagetableEntry).
45 +*/
46 + nbuckets = maxbytes /
47 + (sizeof(PagetableEntry) + sizeof(Pointer) + sizeof(Pointer));
It too
On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote
wrote:
> On 2017/11/06 14:32, David Rowley wrote:
>> On 6 November 2017 at 17:30, Amit Langote wrote:
>>> On 2017/11/03 13:32, David Rowley wrote:
On 31 October 2017 at 21:43, Amit Langote wrote:
[]
>
> Attached updated set of patches, includin
On Fri, Nov 10, 2017 at 4:41 AM, Robert Haas wrote:
> On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote:
>> Fixed in the 0003 patch.
>
> I have committed this patch set with the attached adjustments.
>
Thanks a lot for your support & a ton of thanks to all reviewer.
Regard
On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson wrote:
> Hello all,
>
> Here is the updated patch which is rebased over v10 of Amit Langote's
> path towards faster pruning patch [1]. It modifies the PartScanKeyInfo
> struct to hold expressions which is then evaluated by the executor to
> fetch the c
On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote:
> Artur Zakirov writes:
>> - now DCH_cache_getnew() is called after parse_format(). Because now
>> parse_format() can raise an error and in the next attempt
>> DCH_cache_search() could return broken cache entry.
>
> I started looking at your 0001-t
good to me, code in v6 does not differ much
from v4 patch. Ready for committer review. Thanks !
Regards,
Amul Sul
The new status of this patch is: Ready for Committer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi
,
selectDumpableExtension() function skip
s dump of
built-in extensions in case of binary-upgrade only,
why not in normal
dump
?
Can't we assume those will already be installed in the target database
at restore
?
Thanks
&
Regards,
Amul
On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas wrote:
> On Thu, Oct 27, 2016 at 2:11 AM, amul sul wrote:
>> selectDumpableExtension() function skip
>> s dump of
>> built-in extensions in case of binary-upgrade only,
>> why not in normal
>> dump
>> ?
&
On 31 Oct 2016 6:48 pm, "Tom Lane" wrote:
>
> amul sul writes:
> > On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas
wrote:
> >> There's a comment in dumpExtension() that explains it.
>
> > Let me explain the case I'm trying to tackle. I have two o
Hi Guillaume,
With your v2 patch, -B options working as expected but --no-blobs
options is still unrecognized, this happens is because of you have
forgot to add entry for 'no-blobs' in long_options[] array.
Apart from this concern patch looks good to me. Thanks
Regards,
Amul
--
Sent via pgsql
Kindly ignore this, i've added this note to original thread.
Sorry for noise.
Regards,
Amul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
PostgreSQL also relies on the
operating system cache, it is unlikely that an allocation of more than
I may be wrong here, would like know your and/or community's thought
on this. Thanks.
Regards,
Amul Sul
The new status of this patch is: Waiting on Author
--
Sent via pgsql-hackers ma
g this paragraph either, I'll leave the
decision to committer.
> I'll change the status to needs review.
The new status of this patch is: Ready for Committer
Regards,
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Patch v6 looks good to me, passing to committer.
Thanks !
The n
On Tue, Feb 28, 2017 at 8:03 PM, Yugo Nagata wrote:
> Hi all,
>
> Now we have a declarative partitioning, but hash partitioning is not
> implemented yet. Attached is a POC patch to add the hash partitioning
> feature. I know we will need more discussions about the syntax and other
> specifications
On Wed, Mar 1, 2017 at 3:50 PM, Yugo Nagata wrote:
> []
>
> I Agree that it is unavoidable partitions number in modulo hashing,
> > but we can do in other hashing technique. Have you had thought about
> > Linear hashing[1] or Consistent hashing[2]? This will allow us to
> > add/drop
> >
On Fri, Mar 3, 2017 at 5:00 PM, Greg Stark wrote:
> On 2 March 2017 at 13:03, amul sul wrote:
> > create table foo (a integer, b text) partition by hash (a);
> > create table foo1 partition of foo with (modulus 4, remainder 0);
> > create table foo2 partition of foo with (m
Hi,
While working on the another patch, I came across the case where
I need an auto generated partition for a mutil-column range partitioned
table having following range bound:
PARTITION p1 FROM (UNBOUNDED, UNBOUNDED) TO (10, 10)
PARTITION p2 FROM (10, 10) TO (10, UNBOUNDED)
PARTITION p3 FROM
On Fri, Jun 23, 2017 at 6:58 AM, Amit Langote
wrote:
> On 2017/06/22 20:48, amul sul wrote:
>> Hi,
>>
>> While working on the another patch, I came across the case where
>> I need an auto generated partition for a mutil-column range partitioned
>> t
On Fri, Jun 23, 2017 at 10:11 AM, Yugo Nagata wrote:
> On Tue, 6 Jun 2017 13:03:58 +0530
> amul sul wrote:
>
>
>> Updated patch attached.
>
> I looked into the latest patch (v13) and have some comments
> althogh they might be trivial.
>
Thanks for your review.
On Fri, Jun 23, 2017 at 11:19 AM, Yugo Nagata wrote:
> On Fri, 23 Jun 2017 13:41:15 +0900
> Yugo Nagata wrote:
>
>> On Tue, 6 Jun 2017 13:03:58 +0530
>> amul sul wrote:
>>
>>
>> > Updated patch attached.
>>
>> I looked into the latest patch
On Wed, Jul 5, 2017 at 4:50 PM, Dilip Kumar wrote:
> On Mon, Jul 3, 2017 at 4:39 PM, amul sul wrote:
>> Thanks to catching this, fixed in the attached version.
>
> Few comments on the latest version.
>
Thanks for your review, please find my comment inline:
> 0001 looks
Attaching newer patches rebased against the latest master head. Thanks !
Regards,
Amul
0001-Cleanup_v6.patch
Description: Binary data
0002-hash-partitioning_another_design-v16.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Tue, Aug 8, 2017 at 6:18 PM, Rushabh Lathia wrote:
> Thanks Rajkumar for testing and reporting this.
>
>
> It seems like with we set the numParents and parents only for the
> dumpable objects (flagInhTables()). Current patch relies on the numParents
> and parents to get the root partition Table
On Fri, Aug 18, 2017 at 8:49 AM, Robert Haas wrote:
> On Wed, Aug 16, 2017 at 5:34 PM, Robert Haas
> wrote:
> > Attached is a quick sketch of how this could perhaps be done (ignoring
> > for the moment the relatively-boring opclass pushups).
>
> Here it is with some relatively-boring opclass pus
On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote:
>I spent some time today looking at these patches. It seems like there
>is some more work still needed here to produce something committable
>regardless of which way we go, but I am inclined to think that Amul's
>patch is a better basis for wor
On Tue, May 2, 2017 at 9:33 PM, Rahila Syed wrote:
> Please find attached updated patch with review comments by Robert and Jeevan
> implemented.
>
Patch v8 got clean apply on latest head but server got crash at data
insert in the following test:
-- Create test table
CREATE TABLE test ( a int, b d
Hi,
Current pg_dump --exclude-table option excludes partitioned relation
and dumps all its child relations and vice versa for --table option, which
I think is incorrect.
In this case we might need to explore all partitions and exclude or include
from dump according to given pg_dump option, attach
On Tue, May 9, 2017 at 3:51 PM, Ashutosh Bapat
wrote:
> On Tue, May 9, 2017 at 2:59 PM, Amit Langote
> wrote:
>> Hi Amul,
>>
>> On 2017/05/09 16:13, amul sul wrote:
>>> Hi,
>>>
>>> Current pg_dump --exclude-table option excludes partitioned rela
On Wed, May 10, 2017 at 6:04 PM, Ashutosh Bapat
wrote:
> On Wed, May 3, 2017 at 6:39 PM, amul sul wrote:
>> On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote:
>>
>>>
>>> This is not yet a detailed review - I may be missing things, and
>>> review and co
On Thu, May 11, 2017 at 9:32 PM, Dilip Kumar wrote:
> On Wed, May 3, 2017 at 6:39 PM, amul sul wrote:
>> On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote:
>>
>>>I spent some time today looking at these patches. It seems like there
>>>is some more work still
On Fri, May 12, 2017 at 10:39 PM, Ashutosh Bapat
wrote:
> On Fri, May 12, 2017 at 6:08 PM, amul sul wrote:
>> Hi,
>>
>> Please find the following updated patches attached:
>>
>> 0001-Cleanup.patch : Does some cleanup and code refactoring required
>> for
On Sat, May 13, 2017 at 12:11 PM, Dilip Kumar wrote:
> On Fri, May 12, 2017 at 6:08 PM, amul sul wrote:
>> Hi,
>>
>> Please find the following updated patches attached:
>
> I have done some testing with the new patch, most of the cases worked
> as per the expecta
On Wed, May 10, 2017 at 10:13 PM, Robert Haas wrote:
> On Wed, May 10, 2017 at 8:34 AM, Ashutosh Bapat
> wrote:
>> Hash partitioning will partition the data based on the hash value of the
>> partition key. Does that require collation? Should we throw an error/warning
>> if
>> collation is specif
On Mon, May 15, 2017 at 9:13 PM, Robert Haas wrote:
> On Mon, May 15, 2017 at 6:57 AM, amul sul wrote:
>>> Collation is only relevant for ordering, not equality. Since hash
>>> opclasses provide only equality, not ordering, it's not relevant here.
>>> I'm
On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat
wrote:
[...]
>>>
>>> +if (key->strategy == PARTITION_STRATEGY_HASH)
>>> +{
>>> +ndatums = nparts;
>>> +hbounds = (PartitionHashBound **) palloc(nparts *
>>> +
>>> sizeof(PartitionHashBound *));
>>> +
On Tue, May 16, 2017 at 1:17 PM, Ashutosh Bapat
wrote:
> Hi,
> Here's patch with some cosmetic fixes to 0002, to be applied on top of 0002.
>
Thank you, included in v6 patch.
Regards,
Amul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On Tue, May 16, 2017 at 3:30 PM, amul sul wrote:
> On Tue, May 16, 2017 at 1:02 PM, Ashutosh Bapat
> wrote:
> [...]
>>>>
>>>> +if (key->strategy == PARTITION_STRATEGY_HASH)
>>>> +{
>>>> +ndatums = nparts
On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar wrote:
> On Tue, May 16, 2017 at 4:22 PM, amul sul wrote:
>> v6 patch has bug in partition oid mapping and indexing, fixed in the
>> attached version.
>>
>> Now partition oids will be arranged in the ascending order of ha
On Wed, May 17, 2017 at 11:11 AM, Ashutosh Bapat
wrote:
> On Wed, May 17, 2017 at 12:04 AM, amul sul wrote:
>> On Tue, May 16, 2017 at 10:00 PM, Dilip Kumar wrote:
>>> On Tue, May 16, 2017 at 4:22 PM, amul sul wrote:
>>>> v6 patch has bug in partition oid mapp
On Wed, May 17, 2017 at 6:54 PM, Ashutosh Bapat
wrote:
[...]
>
> Comments on the tests
> +#ifdef USE_ASSERT_CHECKING
> +{
> +/*
> + * Hash partition bound stores modulus and remainder at
> + * b1->datums[i][0] and b1->datums[i][1] position respectively.
On Fri, May 19, 2017 at 10:35 PM, Robert Haas wrote:
> On Fri, May 19, 2017 at 5:32 AM, amul sul wrote:
>> Updated patch attached. 0001-patch rebased against latest head.
>> 0002-patch also incorporates code comments and error message changes
>> as per Robert's
On Mon, May 22, 2017 at 2:23 PM, amul sul wrote:
>
> Updated patch attached. Thanks a lot for review.
>
Minor fix in the document, PFA.
Regards,
Amul
0002-hash-partitioning_another_design-v12.patch
Description: Binary data
0001-Cleanup_v4.patch
Description: Binary data
--
Sent
Hi Dilip,
Thanks for review.
On Sat, Jun 3, 2017 at 6:54 PM, Dilip Kumar wrote:
> On Thu, May 25, 2017 at 9:59 AM, amul sul wrote:
>> On Mon, May 22, 2017 at 2:23 PM, amul sul wrote:
>>>
>>> Updated patch attached. Thanks a lot for review.
>>>
>> Mino
On Wed, Jun 7, 2017 at 2:08 AM, Jeevan Ladhe
wrote:
[...]
>>
>> The code in check_default_allows_bound() to check whether the default
>> partition
>> has any rows that would fit new partition looks quite similar to the code
>> in
>> ATExecAttachPartition() checking whether all rows in the table be
On Wed, Jun 7, 2017 at 10:30 AM, Jeevan Ladhe
wrote:
>
>
>> IIUC, default partition constraints is simply NOT IN (> other sibling partitions>).
>> If constraint on the default partition refutes the new partition's
>> constraints that means we have overlapping partition, and perhaps
>> error.
>
>
>
On Wed, May 17, 2017 at 10:22 PM, Robert Haas wrote:
[...]
> I committed this with fixes for those issues, plus I renamed the macro
> to partition_bound_accepts_nulls, which I think is more clear.
>
partition_bound_accepts_nulls() will alway yield true for a range
partitioning case, because in Rel
On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas wrote:
> On Fri, Aug 18, 2017 at 1:12 PM, amul sul wrote:
> > I have a small query, what if I want a cache entry with extended hash
> > function instead standard one, I might require that while adding
> > hash_array_extended f
On Tue, Aug 22, 2017 at 5:44 PM, amul sul wrote:
> On Fri, Aug 18, 2017 at 11:01 PM, Robert Haas
> wrote:
>
>> On Fri, Aug 18, 2017 at 1:12 PM, amul sul wrote:
>> > I have a small query, what if I want a cache entry with extended hash
>> > function instead s
On Tue, Aug 29, 2017 at 11:48 PM, Robert Haas wrote:
> On Tue, Aug 22, 2017 at 8:14 AM, amul sul wrote:
> > Attaching patch 0002 for the reviewer's testing.
>
> I think that this 0002 is not something we can think of committing
> because there's no guarantee that ha
On Wed, Aug 30, 2017 at 9:05 PM, Robert Haas wrote:
> On Wed, Aug 30, 2017 at 10:43 AM, amul sul wrote:
> > Thanks for the suggestion, I have updated 0002-patch accordingly.
> > Using this I found some strange behaviours as follow:
> >
> > 1) standard and extended
I've updated patch to use an extended hash function (Commit #
81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning.
Regards,
Amul
On Thu, Jul 27, 2017 at 5:11 PM, amul sul wrote:
> Attaching newer patches rebased against the latest master head. Thanks !
>
> Regards,
&
On Fri, Sep 1, 2017 at 8:01 AM, Robert Haas wrote:
> On Thu, Aug 31, 2017 at 8:40 AM, amul sul wrote:
> > Fixed in the attached version.
>
> I fixed these up a bit and committed them. Thanks.
>
> I think this takes care of adding not only the infrastructure but
> suppo
On Thu, May 18, 2017 at 9:13 AM, Amit Kapila
wrote:
> 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 Inval
On Fri, Sep 8, 2017 at 6:45 AM, Robert Haas wrote:
> On Mon, Sep 4, 2017 at 6:38 AM, amul sul wrote:
> > I've updated patch to use an extended hash function (Commit #
> > 81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning.
>
> Committed 0001 after notic
On Mon, Sep 11, 2017 at 5:30 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > On Mon, Sep 11, 2017 at 4:17 AM, Ashutosh Bapat
> > wrote:
> > >> Rebased 0002 against this commit & renamed to 0001, PFA.
> > >
> > > Given that we have default partition support now, I am wondering
> > > whether ha
On Sun, Sep 10, 2017 at 8:47 AM, Amit Kapila
wrote:
> On Fri, Sep 8, 2017 at 4:51 PM, amul sul wrote:
> > On Thu, May 18, 2017 at 9:13 AM, Amit Kapila
> > wrote:
> >>
> >> On Wed, May 17, 2017 at 5:17 PM, Robert Haas
> >> wrote:
> >
On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen wrote:
> Hi Amul,
>
> On 09/08/2017 08:40 AM, amul sul wrote:
>
>> Rebased 0002 against this commit & renamed to 0001, PFA.
>>
>>
> This patch needs a rebase.
>
>
Thanks for your note.
Attached is
On Fri, Sep 15, 2017 at 4:30 AM, Thom Brown wrote:
> On 14 September 2017 at 09:58, amul sul wrote:
> > On Wed, Sep 13, 2017 at 7:43 PM, Jesper Pedersen
> > wrote:
> >>
> >> Hi Amul,
> >>
> >> On 09/08/2017 08:40 AM, amul sul wrote:
> &
Patch 0007:
1:
400 + /*
401 +* XXX: might be worthwhile to only handle oid sysattr, to
reduce
402 +* overhead - it's the most common key.
403 +*/
IMHO, let fix that as well. I tested this by fixing (see the attach patch)
but does
not found much gain on my local cento
On Wed, Sep 20, 2017 at 9:27 PM, Amit Khandekar
wrote:
> On 20 September 2017 at 00:06, Robert Haas wrote:
> > On Fri, Sep 15, 2017 at 7:25 AM, Amit Khandekar
> wrote:
> >> [ new patch ]
>
86 - (event == TRIGGER_EVENT_UPDATE &&
!trigdesc->trig_update_after_row))
87 + (e
On Fri, Sep 22, 2017 at 11:47 AM, Andres Freund wrote:
> Hi,
>
> On 2017-09-20 18:26:50 +0530, amul sul wrote:
> > Patch 0007:
>
> Other than these concern, patch looks pretty reasonable to me.
>
> I'd appreciate if you could have a look at the new version as
On Wed, Sep 27, 2017 at 6:09 AM, Amit Langote wrote:
> On 2017/09/27 1:51, Robert Haas wrote:
> > On Tue, Sep 26, 2017 at 10:57 AM, Jesper Pedersen
> > wrote:
> >> One could advocate (*cough*) that the hash partition patch [1] should be
> >> merged first in order to find other instances of where
On Mon, Sep 18, 2017 at 8:55 PM, Jesper Pedersen wrote:
> On 09/15/2017 02:30 AM, amul sul wrote:
>
>> Attached rebased patch, thanks.
>>
>>
> While reading through the patch I thought it would be better to keep
> MODULUS and REMAINDER in caps, if CREATE TAB
Hi All,
Attaching POC patch that throws an error in the case of a concurrent update
to an already deleted tuple due to UPDATE of partition key[1].
In a normal update new tuple is linked to the old one via ctid forming
a chain of tuple versions but UPDATE of partition key[1] move tuple
from one pa
On Thu, Sep 28, 2017 at 11:24 AM, Amit Langote
wrote:
> On 2017/09/27 22:41, Jesper Pedersen wrote:
>> On 09/27/2017 03:05 AM, amul sul wrote:
>>>>> Attached rebased patch, thanks.
>>>>>
>>>>>
>>>> While reading through the patch
On Wed, Sep 13, 2017 at 4:24 PM, amul sul wrote:
>
>
> On Sun, Sep 10, 2017 at 8:47 AM, Amit Kapila
> wrote:
>>
>> On Fri, Sep 8, 2017 at 4:51 PM, amul sul wrote:
>> > On Thu, May 18, 2017 at 9:13 AM, Amit Kapila
>> > wrote:
>> >&g
errdetail_internal("%s",
GUC_check_errdetail_string) : 0,
I have basic questions,
1. Condition testing of GUC_check_errdetail_string or other GUC_* is needed,
even if we resting it?
2. Can I pass hint message in above ereport(), how?
Thanks in advance !
Regards,
Amul Sul
resql$ psql postgres
I installed from HEAD(ae5266f25910d6e084692a7cdbd02b9e52800046)
I failed to reproduce it, do I missing something?
Regards,
Amul Sul
ame -a
Linux amul 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
Regards,
Amul Sul
is scope
Do i missing something?
Thanks & regards,
Amul Sul
again and again.
Instead of this, can we add loop in Client code, so it can keep trying to
connection request?
in a way, we client terminal wont hangup by throwing *The connection to the
server was lost. Attempting reset: Failed. !*
Regards,
Amul Sul
--
Sent via pgsql-hackers ma
o. This is very rare case, and won't have any affect in
production.
Initially, IMO, I thought no harm if PSQL client wait for few seconds till
server recovered properly and ready to accept connection.
Any way, I will follow-up your suggestion.
Thank you for sharing your concerns an
>"ctags" and "etags" be part of postgres source tree and its generate some
output inside them, so I think we must ignore it.
+1
Regards,
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
aster
* master
3. Then you want to checkout to REL9_3_STABLE , and pull the all changes
pointing to master?
4. while actual happened then want to create branch REL9_3_STABLE?
Is this way?
Regards
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
fusion of user to export USE_PGXS as follow
ifndef USE_PGXS
top_builddir = ../..
makefile_global = $(top_builddir)/src/Makefile.global
ifeq "$(wildcard $(makefile_global))" ""
USE_PGXS = 1
endif
/* remaining code as it is */*
Regards,
Amul Sul
--
Sent via pgsql-hackers mai
p
validation of existing data as well as mark check constraint valid, when we
have assurance that modified/added constraint are valid.
Comments? Thoughts?
Regards,
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
AINT
>command at a time of their choosing.
This could be time consuming operation for big table, If I am pretty much sure
that my constraint will be valid, simply I could set both flag(initially_valid
& skip_validation) to true.
Regards,
Amul Sul
--
Sent via pgsql-
date existing data.
Now, if we have two flag, which can separately use for there respective
purpose, then why do you think that it is not readable?
>As Marko points out that would be actually a new
>SQL-level feature that requires much more than changing that line.
May be yes.
Regards
r thoughts and/or suggestions.
Thanks,
Amul Sul
transformCheckConstraints-function-to-overrid-not-valid.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 Thursday, 10 December 2015 8:22 AM, Amit Langote
> wrote:
>You forgot to put braces around the if block.
Does this really required?
Regards,
Amul Sul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
1761).
>Oops, forget the second one.
No issue, first one make sense.
Updated patch is attached.
Thanks & Regards,
Amul Sul
transformCheckConstraints-function-to-overrid-not-valid_V2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
1 - 100 of 138 matches
Mail list logo
