On Mon, Mar 18, 2024 at 3:33 PM Amit Langote
wrote:
> Himanshu,
>
> On Mon, Mar 18, 2024 at 4:57 PM Himanshu Upadhyaya
> wrote:
> > I have tested a nested case but why is the negative number allowed in
> subscript(NESTED '$.phones[-1]'COLUMNS), it should error out if the
I have tested a nested case but why is the negative number allowed in
subscript(NESTED '$.phones[-1]'COLUMNS), it should error out if the number
is negative.
‘postgres[170683]=#’SELECT * FROM JSON_TABLE(jsonb '{
‘...>’ "id" : "0.234567897890",
‘...>’ "name" : {
ept_id);
> json_exists
> -
> t
> (1 row)
>
> Does that make sense?
>
> Yes, got it. Thanks for the clarification.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
--
f
(1 row)
isn't it supposed to return "true" as json in input is matching with both
the condition dept_id and salary?
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
;
name | id
--+
JOHN DOE |
(1 row)
)
if it is not able to represent it to integer because of bigger input, it
should error out with a similar error message instead of leaving it empty.
Thoughts?
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
nt
error(in fact processes the JSON but returns it with empty data for "id"
field). I think second query should fail with a similar error.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
ers like
> StoreRelCheck(), and other related code, it would be more logical to
> put them immediately before the valid/invalid entries, to match the
> order of constraint properties in pg_constraint, and functions like
> CreateConstraintEntry().
>
> Fixed in V3 patch.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
g popping up now:
> CREATE TABLE tbl_new_3 (i int check(i<>0)) partition by range (i);
> CREATE FOREIGN TABLE ftbl_new_3 PARTITION OF tbl_new_3 FOR VALUES FROM
> (40) TO (50) server s1;
> postgres=# ALTER TABLE tbl_new_3 ADD CONSTRAINT tbl_new_3_chk
> CHECK(i<>1) DEFERRABLE;
> WARNING: unexpected pg_constraint record found for relation "tbl_new_3"
> ERROR: "ftbl_new_3" is a foreign table
> DETAIL: Foreign tables cannot have constraint triggers.
>
> Fixed in V3 patch.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
On Mon, Oct 2, 2023 at 8:31 PM Himanshu Upadhyaya <
upadhyaya.himan...@gmail.com> wrote:
V3 patch attached.
>
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
v3-0001-Implementation-of-CHECK-Constraint-to-make-it.patch
Description: Binary data
On Tue, Sep 12, 2023 at 2:56 PM vignesh C wrote:
> On Thu, 7 Sept 2023 at 17:26, Himanshu Upadhyaya
> wrote:
> >
> > Attached is v2 of the patch, rebased against the latest HEAD.
>
> Thanks for working on this, few comments:
> 1) "CREATE TABLE check_constr_tbl
stgres[1271421]=#’begin;
BEGIN
‘postgres[1271421]=#*’SET CONSTRAINTS ALL DEFERRED;
SET CONSTRAINTS
‘postgres[1271421]=#*’INSERT INTO tbl values (1);
INSERT 0 1
‘postgres[1271421]=#*’commit;
ERROR: 23514: new row for relation "tbl_1" violates check constraint
"tbl_chk_1"
DETAIL: Failing row contains (1).
SCHEMA NAME: public
TABLE NAME: tbl_1
CONSTRAINT NAME: tbl_chk_1
LOCATION: ExecConstraints, execMain.c:2077
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
Thanks for the review comments.
On Tue, Sep 12, 2023 at 2:56 PM vignesh C wrote:
> On Thu, 7 Sept 2023 at 17:26, Himanshu Upadhyaya
> wrote:
> >
> > Attached is v2 of the patch, rebased against the latest HEAD.
>
> Thanks for working on this, few comments:
> 1) &qu
ENUM name as "EnforceDeferredCheck" and member
as “CHECK_DEFERRED_YES”, “CHECK_DEFRRED_NO” and “CHECK_DEFERRED_EXISTING”.
Thoughts?
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
Attached is v2 of the patch, rebased against the latest HEAD.
Thanks,
Himanshu
From cf6057ebeffd026ae075ec43d573eca1164eff5b Mon Sep 17 00:00:00 2001
From: Himanshu Upadhyaya
Date: Thu, 7 Sep 2023 13:19:14 +0530
Subject: [PATCH v2] Implementation of "CHECK Constraint" to make it
--+--+
1001 | test | 1
(1 row)
Thanks,
Himanshu
On Fri, Jul 7, 2023 at 5:21 PM Dilip Kumar wrote:
> On Wed, Jul 5, 2023 at 3:08 PM Himanshu Upadhyaya
> wrote:
> >
> > Hi,
> >
> > Currently, there is no supp
patch.
thoughts?
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
From 1eb72b14a3a6914e893854508a071ae835d23245 Mon Sep 17 00:00:00 2001
From: Himanshu Upadhyaya
Date: Wed, 5 Jul 2023 14:54:37 +0530
Subject: [PATCH v1] Implementation of "CHECK Constraint" to mak
etItem(ctx.page,
next_lp);
next_xmin = HeapTupleHeaderGetXmin(next_htup);
if (!TransactionIdIsValid(curr_xmax) ||
!TransactionIdEquals(curr_xmax, next_xmin))
continue;
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
On Wed, Mar 8, 2023 at 7:30 PM Himanshu Upadhyaya <
upadhyaya.himan...@gmail.com> wrote:
Please find the v11 patch with all these changes.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
From f2b262e95fe07dddfec994f20a6d2e76bc12b410 Mon Sep 17 00:00:00 200
ises me, because the new test cases involve preparing a
> transaction, and by default max_prepared_transactions=0. So it seems
> to me (without testing) that this ought to be required. Did you test
> that it works without this setting?
>
> The value of 100 seems a bit excessive, though. Most TAP tests seem to use
> 10.
>
> We need this for prepare transaction, will change it to 10.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
On Wed, Feb 8, 2023 at 11:17 PM Robert Haas wrote:
> On Sun, Feb 5, 2023 at 3:57 AM Himanshu Upadhyaya
> wrote:
> > Thanks, yes it's working fine with Prepared Transaction.
> > Please find attached the v9 patch incorporating all the review comments.
>
> I don't know qui
On Tue, Jan 31, 2023 at 7:20 PM Robert Haas wrote:
> On Mon, Jan 30, 2023 at 8:24 AM Himanshu Upadhyaya
> wrote:
> > Before this we stop the node by "$node->stop;" and then only we progress
> to
> > manual corruption. This will abort all running/in-progress
Hi Hackers,
On Sun, Jan 22, 2023 at 8:48 PM Himanshu Upadhyaya <
upadhyaya.himan...@gmail.com> wrote:
>
> The test if (pred_in_progress || TransactionIdDidCommit(curr_xmin))
>> seems wrong to me. Shouldn't it be &&? Has this code been tested at
>> all? It doesn'
but I am not very
> convinced by initializers like OffsetNumber
> predecessor[MaxOffsetNumber] = {InvalidOffsetNumber}. That style is
> only correct because InvalidOffsetNumber happens to be zero. If it
> were up to me, I'd use memset to clear the predecessor array. I would
> not bulk initialize sucessor and lp_valid but make sure that the first
> loop always sets them, possibly by having the top of the loop set them
> to InvalidOffsetNumber and false initially and then letting code later
> in the loop change the value, or possibly in some other way.
>
> agree, will fix in my next patch
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
xid_commit_status, no?
>
>
> I think it will be good to pass NULL to get_xid_status like
"get_xid_status(curr_xmin, , NULL);" so that we can only check the xid
status at the time when it is actually required. This way we can avoid
checking xid status in cases when we simply 'continu
K_RELATION_COLS] = {0};
boolnulls[HEAPCHECK_RELATION_COLS] = {0};
HeapTuple tuple;
values[0] = Int64GetDatum(blkno);
values[1] = Int32GetDatum(offnum);"
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
ctx.offnum);
> > + pred_htup = (HeapTupleHeader) PageGetItem(ctx.page,
> pred_lp);
> > + pred_xmin = HeapTupleHeaderGetXmin(pred_htup);
> > +
> > + /*
> > + * If the predecesso
".
>
> I understand the problem with frozen tuples but don't understand the
concern with non-HOT chains,
could you please help with some explanation around it?
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
On Wed, Nov 16, 2022 at 12:41 PM Himanshu Upadhyaya <
upadhyaya.himan...@gmail.com> wrote:
>
>
>> > + }
>> > +
>> > + /* Loop over offsets and validate the data in the
>> predecessor array. */
>> > +
On Wed, Nov 16, 2022 at 11:23 PM Robert Haas wrote:
> On Wed, Nov 16, 2022 at 4:51 AM Himanshu Upadhyaya
> wrote:
> > yes, got it, have tried to test and it is giving false corruption in
> case of subtransaction.
> > I think a better way to have this check
you're right.
yes, got it, have tried to test and it is giving false corruption in case
of subtransaction.
I think a better way to have this check is, we need to check that if
pred_xmin is
aborted then current_xmin should be aborted only. So there is no way that we
validate corruption with in_progress txid.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
EAP_XMIN_INVALID,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE}",{})
4 | 1257 | 1258 | 2 | (0,5) | {"\\x0600","\\x0100"} |
("{HEAP_COMBOCID,HEAP_UPDATED,HEAP_HOT_UPDATED,HEAP_ONLY_TUPLE}",{})
5 | 1258 | 0 | 3 | (0,5) | {"\\x0700","\\x0100"} |
("{HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE}",{})
(5 rows)
>
> > + }
> > +
> > + /*
> > + * If the predecessor's xmin is not frozen, then
> current tuple's
> > + * shouldn't be either.
> > + */
> > + if (pred_xmin != FrozenTransactionId && curr_xmin
> == FrozenTransactionId)
> > + {
> > + report_corruption(,
> > +
> psprintf("unfrozen tuple was updated to produce a tuple at offset %u which
> is frozen",
> > +
> (unsigned) currentoffnum));
> > + }
>
> Can't we have a an update chain that is e.g.
> xmin 10, xmax 5 -> xmin 5, xmax invalid
>
> and a vacuum cutoff of 7? That'd preent the first tuple from being removed,
> but would allow 5 to be frozen.
>
> I think there were recent patches proposing we don't freeze in that case,
> but
> we'll having done that in the past
>
>
Not very sure about this, was trying with such case but found hard to
reproduce this.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
On Tue, Sep 20, 2022 at 6:43 PM Robert Haas wrote:
> On Tue, Sep 20, 2022 at 5:00 AM Himanshu Upadhyaya
> wrote:
> > Please find it attached.
>
> This patch still has no test cases. Just as we have test cases for the
> existing corruption checks, we should have tes
On Tue, Sep 27, 2022 at 1:35 AM Robert Haas wrote:
> On Sat, Sep 24, 2022 at 8:45 AM Himanshu Upadhyaya
> wrote:
> > Here our objective is to validate if both Predecessor's xmin and current
> Tuple's xmin are same then cmin of predecessor must be less than current
> Tuple's
5) |
{"\\x1774657374342020202020","\\x0100"} |
("{HEAP_HASVARWIDTH,HEAP_XMAX_INVALID,HEAP_UPDATED,HEAP_ONLY_TUPLE}",{})
In the above case Tuple 1->3->4 is inserted and updated by xid 971 and
tuple 4 is next update by xid 972, here t_cid of tuple 4 is
nto writing a proper commit
> message, editing the comments, etc. The easiest way of doing this is
> using `git am` and `git format-patch`.
>
> Please find it attached.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
From 3f3290ffb857117385f79f85aa599c588340924b
part for xmin and xmax. Now I think
that it will be good to have nested if, and have an inner if condition to
test xmax and xmin matching. This way we can retrieve and populate xmin and
xmax when it is actually required for the inner if condition.
I have changed this in the attached patch.
--
R
d (2)
> slightly changing the time at which we're first able to detect this
> form of corruption. I am inclined to prefer the simpler form of the
> test without TransactionIdIsInProgress() unless someone can say why we
> shouldn't go that route.
>
> Done, updated in the v3 patch.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
less the lp_valid checks passed for both of the offsets involved.
>
>
ok, I have introduced a new approach to first construct a successor array
and then loop over the successor array to construct a predecessor array.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
From
tus[rdoffnum] == LP_NOT_VALID)
continue;
"
thoughts?
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
k for a normal update?
+if (!HeapTupleHeaderIsHotUpdated(pred_htup) &&
> +HeapTupleHeaderIsHeapOnly(pred_htup) &&
> +HeapTupleHeaderIsHeapOnly(curr_htup))
> +{
> +report_corruption(,
> +
on of the patch.
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
From f3ae2f783a255109655cade770ebc74e01aef34c Mon Sep 17 00:00:00 2001
From: Himanshu Upadhyaya
Date: Thu, 18 Aug 2022 13:20:51 +0530
Subject: [PATCH v1] HOT chain validation in verify_heapam.
---
es containing
* literal namespace names, or NULL pointers to represent DEFAULT.
*/
typedef struct TableFunc
can we change the comment to "...such as XMLTABLE or JSON_TABLE."?
--
Regards,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
| "aaa" | ["aaa"]|
["aaa"] | ["aaa"]
+ [1, null, "2"] | [1, null, "2"] | [1, null, "2"] | [[1,
null, "2"]] | [[1, null, "2"]]
+ {"a": 1
On Thu, Dec 9, 2021 at 7:34 PM Himanshu Upadhyaya
wrote:
> 3)
> Is not that result of the two below queries should match because both are
> trying to retrieve the information from the JSON object.
>
> postgres=# SELECT JSON_OBJECT('track' VALUE '{
On Thu, Dec 16, 2021 at 3:06 AM Andrew Dunstan wrote:
>
>
> On 12/9/21 09:04, Himanshu Upadhyaya wrote:
> >
> >
> >
> > 4)
> > Are we intentionally allowing numeric keys in JSON_OBJECT but somehow
> > these are not allowed in ORACLE?
> > ‘
else if (have_json)
+ {
+ returning->typid = JSONOID;
+ returning->format->format = JS_FORMAT_JSON;
+ }
+ else
+ {
+ /* XXX TEXT is default by the
On Wed, Dec 1, 2021 at 7:56 PM Andrew Dunstan wrote:
>
> On 12/1/21 06:13, Himanshu Upadhyaya wrote:
> > Hi Andrew,
> >
> > The latest version (v59) is not applying on head.
> > Could you please help to rebase?
> >
> >
>
> (Please don't top-post
Hi Andrew,
The latest version (v59) is not applying on head.
Could you please help to rebase?
Thanks,
Himanshu
On Thu, Sep 16, 2021 at 8:23 PM Andrew Dunstan wrote:
>
> On 9/14/21 8:55 AM, Andrew Dunstan wrote:
> > On 9/2/21 2:50 PM, Andrew Dunstan wrote:
> >> On 5/18/21 3:22 PM, Andrew
Hi,
Trying to insert NULL value to the Identity column defined by "GENERATED BY
DEFAULT" is disallowed, but there can be use cases where the user would
like to have an identity column where manual NULL insertion is required(and
it should not error-out by Postgres).
How about having a new type
ok, understood.
Thanks Tom.
Regards,
Himanshu
On Sun, Aug 29, 2021 at 7:10 PM Tom Lane wrote:
> Himanshu Upadhyaya writes:
> > IMHO below query should replace "NULL" value for ID column with the
> > GENERATED IDENTITY value (should insert 1,10 for ID and ID1 resp
Hi,
It seems we have inconsistent behavior with the implementation of
"GENERATED BY DEFAULT AS IDENTITY" constraint on a table column.
Here we are not allowing(internally not replacing NULL with IDENTITY
DEFAULT) the "NULL" insertion into the table column.
postgres=# CREATE TABLE TEST_TBL_1(ID
n Fri, Aug 6, 2021 at 5:40 PM Himanshu Upadhyaya <
upadhyaya.himan...@gmail.com> wrote:
> Hi Sadhu,
>
>
> > The call to “pg_stat_reset“ does reset all the statistics data for
> > tables belonging to the current database but does not take care of
> > shared tables
Hi Sadhu,
> The call to “pg_stat_reset“ does reset all the statistics data for
> tables belonging to the current database but does not take care of
> shared tables e.g pg_attribute.
pg_attribute is not a shared catalog, is the mentioned scenario is also
applicable for few others tables?
I have
temporary object, I also agree here that it will not
actually cause
any issue because of xact lock but then from user perspective it seems
weird
when the same PREPARE TRANSACTION is working second time onwards, thoughts?
Thanks,
Himanshu
On Thu, Apr 8, 2021 at 7:43 PM Robert Haas wrote:
> On W
ect rather it's about
disallowing create transaction as it is referring to the temporary objects.
I have changed it with the exact error we get in those cases.
Please find attached the V2 patch.
Thanks,
Himanshu
On Wed, Apr 7, 2021 at 4:11 PM vignesh C wrote:
> On Tue, Apr 6, 2021 at
SPACE in MyXactFlags second run of “create
function..” Works and PREPARE TRANSACTION succeeds(but it should fail).
Please find attached the proposed patch to FIX this issue.
Thoughts?
Thanks,
Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From 6e2a6bdfb
nterprisedb.com
From 361b8aac87fb3d4e4c968555459f1cedec489440 Mon Sep 17 00:00:00 2001
From: Himanshu Upadhyaya
Date: Mon, 7 Sep 2020 16:48:22 +0530
Subject: [PATCH v1] FIX- for incorrect comment for UNKNOWN input type for
polymorphic arguments
---
src/backend/parser/parse_coerce.c | 2 +-
1 file changed, 1 inse
57 matches
Mail list logo
