rotection -fcf-protection
CFLAGS_SL = -fPIC
LDFLAGS = -Wl,--as-needed -L/usr/lib64 -L/usr/lib -L/usr/lib64 -Wl,--as-needed
-Wl,-rpath,'/usr/pgsql-16/lib',--enable-new-dtags
LDFLAGS_EX =
LDFLAGS_SL =
LIBS = -lpgcommon -lpgport -lselinux -lzstd -llz4 -lxslt -lxml2 -lpam -lssl
-lcrypto -lgssa
Hello All,
We are getting a segmentation fault which seems to be specific to pg16 on
redhat 8. Tested on pg14 and pg15 with no problems. Also tested with pg16 on
redhat 9 - no issues. The developer determined that it is specific to select
into a defined variable within a function. We have a
.com/questions/67559636/pgadmin4-nonetype-object-has-no-attribute-value/67570989#67570989)
in order to fix it, however the error remains. I'm out of options, hopefully
you know the answer.
I tried it with both PostgreSQL 11, 12 and 13. I'm using a windows 64 bit with
PgAdmin 4.
Kind
>
>
> > I've updated word_similarity_op(text,text) to be leakproof, and
> > pg_proc agrees it is. I'm assuming word_similarity_op() is equivalent to
> > <%, though I haven't found explicit confirmation. However, using
> > word_similarity() instead of <% on a 100k row table, without any RLS
> > invo
k row table, without any RLS
involved, doesn't make use of the index, while using <% does. Obviously,
adding the RLS doesn't make that any better. Any idea what might be the
cause?
On Tue, Aug 13, 2019 at 5:39 PM Stephen Frost wrote:
> Greetings,
>
> * Derek Hans (derek.h..
lso happens to fail. Should I expect to be able
to use any of these with RLS, large amounts of data and reasonable
performance?
Your description of leakproof (and the documentation I've found) makes it
sound like I'm not just hitting an isolated problem, but a general problem
with RLS tha
second, when using larger data sets and more fields getting
searched. The example is the simplest repro case I could create.
> regards, tom lane
>
--
*Derek*
+1 (415) 754-0519 | derek.h...@gmail.com | Skype: derek.hans
: (search ~~ '%yo'::text)"
> > " -> Bitmap Index Scan on search__gist (cost=0.00..4.48 rows=44
> width=0)"
> > "Index Cond: (search ~~ '%yo'::text)"
> >
> > I see the same behavior with more complex queries, swit
complex queries, switching to GIN index,
more complex RLS rules, using word_similarity instead of like, using full
text search and larger data sets (e.g. 100k rows). This is on PostgreSQL
v11.1 on Windows 10.
--
*Derek*
+1 (415) 754-0519 | derek.h...@gmail.com | Skype: derek.hans
Based on a reply to reporting this as a bug, moving rows out of foreign
partitions is not yet implemented so this is behaving as expected. There's
a mention of this limitation in the Notes section of the Update docs.
On Wed, Feb 27, 2019 at 6:12 PM Alvaro Herrera
wrote:
> On 2019-Feb-2
s!
On Fri, Feb 22, 2019 at 9:44 AM Derek Hans wrote:
> I've set up 2 instances of PostgreSQL 11. On instance A, I created a table
> with 2 local partitions and 2 partitions on instance B using foreign data
> wrappers, following https://pgdash.io/blog/postgres-11-sharding.html.
&g
ition to foreign partition
Is this the expected behavior? Am I missing something or configured
something incorrectly?
Thanks,
Derek
Tom.
Thanks so much for your response. Your theory appears to have been
correct, and it is working like a champ now.
Best,
Derek
On 10/1/2018 4:29 PM, Tom Lane wrote:
derek writes:
I am trying to populate/create a database with CREATE TABLE AS SELECT
like so:
CREATE TABLE test_table
. I am running
PostgreSQL 9.6 with PostGIS also for some spatial functionality.
Thanks,
Derek
14 matches
Mail list logo
