Hi all
I was jotting notes about this last sleepless night, and was really glad
to see the suggestion of enabling RLS on a table being a requirement for
OR-style quals suggested in the thread when I woke.
The only sane way to do OR-ing of multiple rules is to require that
tables be switched to de
Attached is a WIP patch for the following:
/*
* postgresPlanForeignModify
* Plan an insert/update/delete operation on a foreign table
*
* Note: currently, the plan tree generated for UPDATE/DELETE will always
* include a ForeignScan that retrieves ctids (using SELECT FOR UPDATE)
* and t
Ok, I was able to figure out that when strings contained 'spaces',
PostgreSQL appends them with double quotes.
On Tue, Jul 8, 2014 at 12:04 PM, Ashoke wrote:
> As a follow-up question,
>
> I found some of the varchar column types, in which the histogram_bounds
> are not being surrounded in doub
Over here ->
http://www.postgresql.org/message-id/6351.1404663...@sss.pgh.pa.us Tom
noted that create_unique_path did not check for set returning functions.
Tom Wrote:
> I notice that create_unique_path is not paying attention to the question
> of whether the subselect's tlist contains SRFs or vol
On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane wrote:
> David Rowley writes:
> > On Mon, Jul 7, 2014 at 4:15 AM, Tom Lane wrote:
> >> I poked around to see if we didn't have some code already for that, and
> >> soon found that not only do we have such code
> (equality_ops_are_compatible)
> >> but act
> I don't know enough about XML/XPATH to know if this is a good idea or not,
>
Actually currently because of the namespace problem, xpath() returns wrong
result (even worse: invalid xml!). So this patch corrects the behavior of
xpath() to the correct one.
> but I did go read the documentation of
From: "Amit Kapila"
On Fri, Jul 4, 2014 at 7:29 PM, MauMau wrote:
[Hypothesis]
Why does the connection processing emit WAL?
Probably, it did page-at-a-time vacuum during access to pg_database and
pg_authid for client authentication. src/backend/access/heap/README.HOT
describes:
I agree wit
From: "Rajeev rastogi"
As of now there is no solution for this in PostgreSQL but I had submitted a
patch "Standalone synchronous master" in
9.4 2014-01 CommitFest, which was rejected because of some issues. This
patch was meant to degrade the synchronous
level of master, if all synchronous sta
From: "Tom Lane"
problem, the user might not realize he's got one until he starts to wonder
why autovac/autoanalyze aren't working.
In autovacuum.c, autovacuum workers avoid waiting for the standby by doing:
/*
* Force synchronous replication off to allow regular maintenance even if
* we ar
From: "Tom Lane"
Andres Freund writes:
On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
Well, see the comment that explains why the logic is like this now:
I think we should 'simply' make sequences assign a toplevel xid - then
we can get rid of that special case in RecordTransactionCommit().
On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra wrote:
> I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1)
> once the table is built and there's free space in work_mem. The patch
> mentioned above makes implementing this possible / rather simple.
Another idea would be to start wit
From: "Asif Naeem"
Other than my pervious comments, patch looks good to me. Thanks.
Thanks for reviewing. I understood that your previous comment was to
suggest copying the desired DLLs directly from Release/Debug folder to bin.
But I'm afraid it cannot be done cleanly... CopySolutionOutpu
On 8 Červenec 2014, 14:49, Robert Haas wrote:
> On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra wrote:
>> I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1)
>> once the table is built and there's free space in work_mem. The patch
>> mentioned above makes implementing this possible /
On Sat, Jul 5, 2014 at 12:46 AM, Abhijit Menon-Sen wrote:
> At 2014-07-02 15:51:08 -0700, p...@heroku.com wrote:
>>
>> Attached revision factors in everyone's concerns here, I think.
>
> Is anyone planning to review Peter's revised patch?
I have been doing some functional tests, and looked quickl
2014-07-06 14:19 GMT+09:00 Stephen Frost :
> Kaigai,
>
> * Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
>> > Can you clarify where this is coming from..? It sounds like you're
>> > referring to an existing implementation and, if so, it'd be good to get
>> > more information on how that works exactl
On Tue, Jul 8, 2014 at 9:35 AM, Tomas Vondra wrote:
> On 8 Červenec 2014, 14:49, Robert Haas wrote:
>> On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra wrote:
>>> I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1)
>>> once the table is built and there's free space in work_mem. The p
Ashutosh Bapat writes:
> On Mon, Jul 7, 2014 at 7:37 PM, Tom Lane wrote:
>> I doubt it. The extra code isn't the problem so much, it's the extra
>> planning cycles spent trying to make proofs that will usually fail.
>> What you propose will create a combinatorial explosion in the number
>> of pr
David Rowley writes:
> I think we should probably include the logic to test for set returning
> functions into query_is_distinct_for.
It strikes me that there's only a problem if the SRF is in a tlist entry
that is not one of the DISTINCT or GROUP BY columns, respectively. It
may not be worth th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
is there any hint to tell pgxs to compile with gcc -O0 (CFLAGS) ?
regards
geohas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTvA4AAAoJEJFGMlQe7wR/6PAIAIy6619E9
On Tue, Jul 08, 2014 at 11:19:31AM -0400, Tom Lane wrote:
> Moshe Jacobson writes:
>
> > Seeing that there is only one output column, and that the results are
> > grouped by this output column, it seems to me that the optimizer should not
> > even look at the rest of the tables.
>
> The GROUP BY
geohas writes:
> is there any hint to tell pgxs to compile with gcc -O0 (CFLAGS) ?
I tend to use
make PROFILE=-O0
which relies on knowing that PG's make rules append $(PROFILE) to CFLAGS.
Alternatively you could just override CFLAGS:
make CFLAGS="whatever"
but this requires kn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you Tom!
make CFLAGS=-O0 was it.
now gdb doesn't print .
regards
On 08/07/14 17:45, Tom Lane wrote:
> geohas writes:
>> is there any hint to tell pgxs to compile with gcc -O0 (CFLAGS) ?
>
> I tend to use
>
> make PROFILE=-O0
>
> which
On 8 Červenec 2014, 16:16, Robert Haas wrote:
> On Tue, Jul 8, 2014 at 9:35 AM, Tomas Vondra wrote:
>> Maybe. I'm not against setting NTUP_PER_BUCKET=1, but with large outer
>> relations it may be way cheaper to use higher NTUP_PER_BUCKET values
>> instead of increasing the number of batches (resu
On 07/08/2014 17:53, geohas wrote:
> make CFLAGS=-O0 was it.
>
> now gdb doesn't print .
If you're using GCC 4.8 or later, consider using it with -Og for that
kind of builds.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
Hi,
On Tue, Jul 8, 2014 at 6:58 AM, Michael Paquier
wrote:
> 2) Checking process goes through all the existing columns of a
> relation even a difference of 1 with some other column(s) has already
> been found. As we try to limit the number of hints returned, this
> seems like a waste of resources
On Tue, Jul 8, 2014 at 12:06 PM, Tomas Vondra wrote:
> On 8 Červenec 2014, 16:16, Robert Haas wrote:
>> On Tue, Jul 8, 2014 at 9:35 AM, Tomas Vondra wrote:
>>> Maybe. I'm not against setting NTUP_PER_BUCKET=1, but with large outer
>>> relations it may be way cheaper to use higher NTUP_PER_BUCKET
Re: Noah Misch 2014-06-08 <20140608135713.ga525...@tornado.leadboat.com>
> Here's an update that places the socket in a temporary subdirectory of /tmp.
> The first attached patch adds NetBSD mkdtemp() to libpgport. The second,
> principal, patch uses mkdtemp() to implement this design in pg_regres
On Sat, Jul 5, 2014 at 10:52 AM, Tom Lane wrote:
> Amit Kapila writes:
>> Please find the patch attached to address the above concern. I have
>> updated docs, so that users can be aware of such behaviour.
>
> I'm in the camp that says that we need to do something about this, not
> just claim tha
On 07/08/2014 10:07 AM, Robert Haas wrote:
> I haven't looked at the code in this area too carefully, but it seems
> to me like the flow ought to be:
>
> 1. Read all of the config files and determine what the final value
> present in each config file is.
> 2. *Then*, in a second pass, enforce requ
On Thu, Jun 26, 2014 at 4:26 PM, Andreas Karlsson wrote:
> On 06/24/2014 03:20 AM, Jeff Janes wrote:
>
>> I've tried your 0001 patch, reflecting this refactoring, on Linux and it
>> caused 'make check' to hang at 'starting postmaster'.
>>
>
> I found the bug in the code, and I have attached the a
On 07/06/2014 01:27 AM, Christoph Berg wrote:
> Another could be that during initdb all the uncommented settings be
>> written to postgresql.auto.conf file rather than to postgresql.conf.
>> I think we can do this by changing code in initdb.c->setup_config().
>> This will ensure that unless user is
On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote:
> Re: Noah Misch 2014-06-08 <20140608135713.ga525...@tornado.leadboat.com>
> > Here's an update that places the socket in a temporary subdirectory of /tmp.
> > The first attached patch adds NetBSD mkdtemp() to libpgport. The second,
>
Re: Noah Misch 2014-07-08 <20140708174125.ga1884...@tornado.leadboat.com>
> On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote:
> > Re: Noah Misch 2014-06-08 <20140608135713.ga525...@tornado.leadboat.com>
> > > Here's an update that places the socket in a temporary subdirectory of
> >
On 8.7.2014 19:00, Robert Haas wrote:
> On Tue, Jul 8, 2014 at 12:06 PM, Tomas Vondra wrote:
>> On 8 Červenec 2014, 16:16, Robert Haas wrote:
>>
>>> Right, I think that's clear. I'm just pointing out that you get
>>> to decide: you can either start with a larger NTUP_PER_BUCKET and
>>> then reduce
Hi,
here's my review for this patch.
Generally, the patch addresses a real need, tables often only turn
out to be desired as unlogged if there are performance problems in
practice, and the other way round changing an unlogged table to logged
is way more involved manually than it could be with thi
On Tue, Jul 8, 2014 at 6:35 AM, Tomas Vondra wrote:
> On 8 Červenec 2014, 14:49, Robert Haas wrote:
> > On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra wrote:
> >> I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1)
> >> once the table is built and there's free space in work_mem. T
On Tue, Jul 8, 2014 at 08:21:48PM +0200, Christoph Berg wrote:
> Re: Noah Misch 2014-07-08 <20140708174125.ga1884...@tornado.leadboat.com>
> > On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote:
> > > Re: Noah Misch 2014-06-08 <20140608135713.ga525...@tornado.leadboat.com>
> > > > Here
Peter Geoghegan wrote:
> > 6) Sometimes no hints are returned... Even in simple cases like this one:
> > =# create table foo (aa int, bb int);
> > CREATE TABLE
> > =# select ab from foo;
> > ERROR: 42703: column "ab" does not exist
> > LINE 1: select ab from foo;
> >^
> > LOCATION
On Tue, Jul 8, 2014 at 1:42 PM, Alvaro Herrera wrote:
>> That's because those two candidates come from a single RTE and have an
>> equal distance -- you'd see both suggestions if you joined two tables
>> with each candidate, assuming that each table being joined didn't
>> individually have the sam
On Tue, Jul 8, 2014 at 1:55 PM, Peter Geoghegan wrote:
> I was worried about the common case where a
> column name is misspelled that would otherwise be ambiguous, which is
> why that shows a HINT while the single RTE case doesn't
To be clear - I mean a HINT with two suggestions rather than just
On 8.7.2014 21:53, Jeff Janes wrote:
> On Tue, Jul 8, 2014 at 6:35 AM, Tomas Vondra wrote:
>>
>> Maybe. I'm not against setting NTUP_PER_BUCKET=1, but with large
>> outer relations it may be way cheaper to use higher NTUP_PER_BUCKET
>> values instead of increasing the number of batches (resulting
Hi,
Thinking about this a bit more, do we really need to build the hash
table on the first pass? Why not to do this:
(1) batching
- read the tuples, stuff them into a simple list
- don't build the hash table yet
(2) building the hash table
- we have all the tuples in a simple list, b
David Rowley writes:
> On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane wrote:
>> I'm a bit skeptical as to whether testing for that case is actually worth
>> any extra complexity. Do you have a compelling use-case? But anyway,
>> if we do want to allow it, why does it take any more than adding a check
Yes. Can you please take a look at Win_lib_bin.patch I shared earlier ?, I
think it is or similar approach will be appropriate. Thanks.
Regards,
Muhammad Asif Naeem
On Tue, Jul 8, 2014 at 5:53 PM, MauMau wrote:
> From: "Asif Naeem"
>
> Other than my pervious comments, patch looks good to me.
Asif Naeem wrote:
> Yes. Can you please take a look at Win_lib_bin.patch I shared earlier ?, I
> think it is or similar approach will be appropriate. Thanks.
I think the suggestion by Peter Eisentraut upthread was pretty
reasonable -- the Makefiles are already aware that they are building a
shared
On 9 July 2014 09:27, Tom Lane wrote:
> David Rowley writes:
> > On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane wrote:
> >> I'm a bit skeptical as to whether testing for that case is actually
> worth
> >> any extra complexity. Do you have a compelling use-case? But anyway,
> >> if we do want to all
David Rowley writes:
> On 9 July 2014 09:27, Tom Lane wrote:
>> On review it looks like analyzejoins.c would possibly benefit from an
>> earlier fast-path check as well.
> Do you mean for non-subqueries? There already is a check to see if the
> relation has no indexes.
Oh, sorry, that was a typ
On 09/07/14 05:13, Josh Berkus wrote:
On 07/06/2014 01:27 AM, Christoph Berg wrote:
Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing code in initdb.c->setup_config().
This
I've encountered a corrupt pg_control file on my 9.4 development
cluster. I've mostly been using the cluster for changeset extraction /
slony testing.
This is a 9.4 (currently commit 6ad903d70a440e + a walsender change
discussed in another thread) but would have had the initdb done with an
Steve Singer writes:
> I've encountered a corrupt pg_control file on my 9.4 development
> cluster. I've mostly been using the cluster for changeset extraction /
> slony testing.
> This is a 9.4 (currently commit 6ad903d70a440e + a walsender change
> discussed in another thread) but would ha
On 07/08/2014 10:14 PM, Tom Lane wrote:
Steve Singer writes:
I've encountered a corrupt pg_control file on my 9.4 development
cluster. I've mostly been using the cluster for changeset extraction /
slony testing.
This is a 9.4 (currently commit 6ad903d70a440e + a walsender change
discussed in
Steve Singer writes:
> On 07/08/2014 10:14 PM, Tom Lane wrote:
>> There's no obvious reason to think that this pg_control file is corrupt
>> on its own terms, but the pg_controldata version you're using expects
>> the 942 layout. The fact that the server wasn't complaining about this
>> suggests
On Tue, Jul 8, 2014 at 11:59 PM, Tom Lane wrote:
>
> No, ALTER SYSTEM is there now and it needs to work right in its first
> release. I will go fix this if nobody else does.
I am planing to provide an initial patch for this issue in a day or so, hope
that is not too late.
With Regards,
Amit Kap
On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood
wrote:
> On 09/07/14 05:13, Josh Berkus wrote:
>>> Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing code in initdb
Amit Kapila writes:
> On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood
> wrote:
>> Yes, but even well behaved users will see this type of error, because
>> initdb uncomments certain values (ones that are dead certs for being
>> changed via ALTER SYSTEM subsequently like shared_buffers), and then -
>
On Mon, Jun 30, 2014 at 8:33 PM, Pavel Stehule wrote:
>
>
>
> 2014-06-30 13:01 GMT+02:00 Abhijit Menon-Sen :
>
>> At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote:
>> >
>> > +
>> > + Print a failed SQL commands to standard error output. This is
>> > + equivalent to setti
On Tue, Jul 8, 2014 at 7:57 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Mon, Jul 7, 2014 at 7:37 PM, Tom Lane wrote:
> >> I doubt it. The extra code isn't the problem so much, it's the extra
> >> planning cycles spent trying to make proofs that will usually fail.
> >> What you propose
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> I was jotting notes about this last sleepless night, and was really glad
> to see the suggestion of enabling RLS on a table being a requirement for
> OR-style quals suggested in the thread when I woke.
Thanks for your thoughts and input!
> T
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> What I'd like to implement is adjustment of query like:
> SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS)
> AND (quals by extension-1) AND ... AND (quals by extension-N);
> I never mind even if qualifiers in the
On Wed, Jul 9, 2014 at 5:56 AM, Peter Geoghegan wrote:
> On Tue, Jul 8, 2014 at 1:55 PM, Peter Geoghegan wrote:
> > I was worried about the common case where a
> > column name is misspelled that would otherwise be ambiguous, which is
> > why that shows a HINT while the single RTE case doesn't
>
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> If you're going to have predicates be table-level and access grants be
> table-level, then what's the value in having policies? You could just
> do:
>
> ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING quals;
Yes, this would be po
On Wed, Jul 9, 2014 at 1:49 AM, Peter Geoghegan wrote:
> > 4) This is not nice, could it be possible to remove the stuff from
> varlena.c?
> > +/* Expand each Levenshtein distance variant */
> > +#include "levenshtein.c"
> > +#define LEVENSHTEIN_LESS_EQUAL
> > +#include "levenshtein.c"
> > +#unde
2014-07-09 15:07 GMT+09:00 Stephen Frost :
> KaiGai,
>
> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>> What I'd like to implement is adjustment of query like:
>> SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS)
>> AND (quals by extension-1) AND ... AND (quals by exte
On Tue, Jul 8, 2014 at 11:10 PM, Michael Paquier
wrote:
> Showing up to 2 hints is fine as it does not pollute the error output with
> perhaps unnecessary messages. That's even more protective than for example
> git that prints all the equidistant candidates. However I can't understand
> why it do
On Tue, Jul 8, 2014 at 11:25 PM, Michael Paquier
wrote:
>> So there'd be one variant within core and one within
>> contrib/fuzzystrmatch? I don't think that's an improvement.
>
> No. The main difference between varstr_leven_less_equal and varstr_leven is
> the use of the extra argument max_d in th
65 matches
Mail list logo
