Remove ambiguity for jsonb_path_match() and jsonb_path_exists()
There are 2-arguments and 4-arguments versions of jsonb_path_match() and
jsonb_path_exists(). But 4-arguments versions have optional 3rd and 4th
arguments, that leads to ambiguity. In the same time 2-arguments versions are
needed on
Get rid of jsonpath_gram.h and jsonpath_scanner.h
Jsonpath grammar and scanner are both quite small. It doesn't worth complexity
to compile them separately. This commit makes grammar and scanner be compiled
at once. Therefore, jsonpath_gram.h and jsonpath_gram.h are no longer needed.
This commi
Refactor nbtree insertion scankeys.
Use dedicated struct to represent nbtree insertion scan keys. Having a
dedicated struct makes the difference between search type scankeys and
insertion scankeys a lot clearer, and simplifies the signature of
several related functions. This is based on a sugges
Make heap TID a tiebreaker nbtree index column.
Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequis
Consider secondary factors during nbtree splits.
Teach nbtree to give some consideration to how "distinguishing"
candidate leaf page split points are. This should not noticeably affect
the balance of free space within each half of the split, while still
making suffix truncation truncate away sign
Allow amcheck to re-find tuples using new search.
Teach contrib/amcheck's bt_index_parent_check() function to take
advantage of the uniqueness property of heapkeyspace indexes in support
of a new verification option: non-pivot tuples (non-highkey tuples on
the leaf level) can optionally be re-foun
On Wed, Mar 20, 2019 at 10:05 AM Peter Geoghegan wrote:
> Make heap TID a tiebreaker nbtree index column.
I see that this has caused SELinux test failures on rhinoceros (the
ddl test fails). It looks like the output order is affected by the
implementation details of nbtree, likely for some system
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 10:05 AM Peter Geoghegan wrote:
>> Make heap TID a tiebreaker nbtree index column.
> I see that this has caused SELinux test failures on rhinoceros (the
> ddl test fails). It looks like the output order is affected by the
> implementation details
Hi,
On 2019-03-20 11:00:06 -0700, Peter Geoghegan wrote:
> On Wed, Mar 20, 2019 at 10:05 AM Peter Geoghegan wrote:
> > Make heap TID a tiebreaker nbtree index column.
>
> I see that this has caused SELinux test failures on rhinoceros (the
> ddl test fails). It looks like the output order is affe
On Wed, Mar 20, 2019 at 11:08 AM Tom Lane wrote:
> The diffs all are related to the order of operations in a DROP OWNED BY
> command, so I think blaming SELinux is just blaming the messenger.
> This comes down to the point that we didn't do anything to ensure
> drop order stability in shdepend-dri
On Wed, Mar 20, 2019 at 11:09 AM Andres Freund wrote:
> FWIW, I just fix up the tests using the regression output from
> rhinoceros when that happens. Sometimes takes more than a single round,
> but it builds frequently enough...
I'll give that a go, provided Tom is okay with it.
--
Peter Geogh
On Wed, Mar 20, 2019 at 11:30 AM Peter Geoghegan wrote:
> Your work on test stability probably eliminated 98% of the problems.
> It's still early, but the buildfarm is mostly fine.
batfish just had a similar failure, this time in foreign_data -- two
lines of "DETAIL" output appear in opposite-of-
Restore RI trigger sanity check
I unnecessarily removed this check in 3de241dba86f because I
misunderstood what the final representation of constraints across a
partitioning hierarchy was to be. Put it back (in both branches).
Discussion: https://postgr.es/m/201901222145.t6wws6t6vrcu@alvherre.pg
Restore RI trigger sanity check
I unnecessarily removed this check in 3de241dba86f because I
misunderstood what the final representation of constraints across a
partitioning hierarchy was to be. Put it back (in both branches).
Discussion: https://postgr.es/m/201901222145.t6wws6t6vrcu@alvherre.pg
Suppress DETAIL output from a foreign_data test.
Unstable sort order related to changes to nbtree from commit dd299df8
can cause two lines of DETAIL output to be in opposite-of-expected
order. Suppress the output using the same VERBOSITY hack that is used
elsewhere in the foreign_data tests.
Not
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 11:30 AM Peter Geoghegan wrote:
>> Your work on test stability probably eliminated 98% of the problems.
>> It's still early, but the buildfarm is mostly fine.
> batfish just had a similar failure, this time in foreign_data -- two
> lines of "DETA
On Wed, Mar 20, 2019 at 1:46 PM Tom Lane wrote:
> In the meantime, would you mind cleaning this up:
>
> nbtxlog.c: In function 'btree_xlog_split':
> nbtxlog.c:269: warning: 'newitem' may be used uninitialized in this function
> nbtxlog.c:269: note: 'newitem' was declared here
> nbtxlog.c:271: warn
On Wed, Mar 20, 2019 at 1:46 PM Tom Lane wrote:
> Yeah. My opinion is that we should just qsort the list of targets
> during DROP OWNED and be done with this. I'll post a patch shortly.
Sounds good.
Barring any objections, I will get the buildfarm completely green
again shortly by adjusting th
Fix spurious compiler warning in nbtxlog.c.
Cleanup from commit dd299df8.
Per complaint from Tom Lane.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/3d0dcc5c7fb9cfc349d1b2d476a1c0c5d64522bd
Modified Files
--
src/backend/access/nbtree/nbtxlog.c | 8 ++
I wrote:
> Yeah. My opinion is that we should just qsort the list of targets
> during DROP OWNED and be done with this. I'll post a patch shortly.
Here's one way we could do this: add a flag to performMultipleDeletions
to invoke the sort. A small problem with it is that if we sort the
ObjectAdd
Add index_get_partition convenience function
This new function simplifies some existing coding, as well as supports
future patches.
Discussion: https://postgr.es/m/201901222145.t6wws6t6vrcu@alvherre.pgsql
Reviewed-by: Amit Langote, Jesper Pedersen
Branch
--
master
Details
---
https://gi
I wrote:
> A preliminary check-world run finds no places where the output changes,
> but I've not tried this with SELinux yet.
After trying it (against yesterday's sources) on my SELinux-capable
machine, I see no evidence that we need any output ordering changes
at all if we go this route. This i
On Wed, Mar 20, 2019 at 2:44 PM Tom Lane wrote:
> After trying it (against yesterday's sources) on my SELinux-capable
> machine, I see no evidence that we need any output ordering changes
> at all if we go this route. This is probably unsurprising considering
> that the old btree code used to pro
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 2:44 PM Tom Lane wrote:
>> After trying it (against yesterday's sources) on my SELinux-capable
>> machine, I see no evidence that we need any output ordering changes
>> at all if we go this route. This is probably unsurprising considering
>> that
Sort the dependent objects before deletion in DROP OWNED BY.
This finishes a task we left undone in commit f1ad067fc, by extending
the delete-in-descending-OID-order rule to deletions triggered by
DROP OWNED BY. We've coped with machine-dependent deletion orders
one time too many, and the new iss
I wrote:
> Will push a fix in a few minutes.
And done. Should be possible to revert 7d3bf73ac, if you wish.
regards, tom lane
On Wed, Mar 20, 2019 at 3:08 PM Tom Lane wrote:
> And done. Should be possible to revert 7d3bf73ac, if you wish.
Will do.
Thanks!
--
Peter Geoghegan
On Wed, Mar 20, 2019 at 3:11 PM Peter Geoghegan wrote:
> On Wed, Mar 20, 2019 at 3:08 PM Tom Lane wrote:
> > And done. Should be possible to revert 7d3bf73ac, if you wish.
>
> Will do.
Actually, I'm not sure why it would be fine to revert 7d3bf73ac now.
Might the problem actually be the order i
Add DNS SRV support for LDAP server discovery.
LDAP servers can be advertised on a network with RFC 2782 DNS SRV
records. The OpenLDAP command-line tools automatically try to find
servers that way, if no server name is provided by the user. Teach
PostgreSQL to do the same using OpenLDAP's suppor
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 3:11 PM Peter Geoghegan wrote:
>> On Wed, Mar 20, 2019 at 3:08 PM Tom Lane wrote:
>>> And done. Should be possible to revert 7d3bf73ac, if you wish.
> Actually, I'm not sure why it would be fine to revert 7d3bf73ac now.
> Might the problem actu
30 matches
Mail list logo
