Re: [HACKERS] pg_recvlogical --endpos

On 22 November 2016 at 16:52, Okano, Naoki wrote: > On Monday, November 21, 2016 1:08 PM Craig Ringer wrote: >> I've updated the patch for this. It's already posted on the logical >> decoding timeline following thread, so I'll avoid repeating it here. >> >>

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, Nov 29, 2016 at 3:14 PM, Robert Haas wrote: > On Tue, Nov 29, 2016 at 2:19 PM, Kuntal Ghosh > wrote: >> On Thu, Nov 24, 2016 at 5:46 PM, Mithun Cy >> wrote: >>> I have taken this suggestion now renamed

Re: [HACKERS] Contains and is contained by operators of inet datatypes

Robert Haas writes: > On Mon, Nov 21, 2016 at 7:57 AM, Andreas Karlsson wrote: >> I like the patch because it means less operators to remember for me as a >> PostgreSQL user. And at least for me inet is a rarely used type compared to >> hstore, json and

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Wed, Nov 23, 2016 at 2:47 PM, Thomas Munro wrote: > Actually I meant that at T2 the btree is exactly same as it was at T1, > but the order of the values has changed according to the comparator > (for example, because a collation definition changed when you

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/29/2016 05:25 PM, David Steele wrote: On 11/29/16 5:08 PM, Andrew Dunstan wrote: On 11/29/2016 03:07 PM, Fabien COELHO wrote: I cannot remember a language with elseif* variants, and I find them quite ugly, so from an aethetical point of view I would prefer to avoid that... On the

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/29/16 5:08 PM, Andrew Dunstan wrote: > > On 11/29/2016 03:07 PM, Fabien COELHO wrote: >> >> >> I cannot remember a language with elseif* variants, and I find them >> quite ugly, so from an aethetical point of view I would prefer to >> avoid that... On the other hand having an "else if"

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On 11/29/2016 03:07 PM, Fabien COELHO wrote: I cannot remember a language with elseif* variants, and I find them quite ugly, so from an aethetical point of view I would prefer to avoid that... On the other hand having an "else if" capability makes sense (eg do something slightly different

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Tue, Nov 29, 2016 at 2:19 PM, Kuntal Ghosh wrote: > On Thu, Nov 24, 2016 at 5:46 PM, Mithun Cy wrote: >> I have taken this suggestion now renamed target_server_type to >> target_session_attrs with possible 2 values "read-write", "any".

Re: [HACKERS] XactLockTableWait doesn't set wait_event correctly

On Tue, Nov 29, 2016 at 4:56 PM, Simon Riggs wrote: > New (9.4) XactLockTableWait() sets the reason for the wait, so that if > we emit a log message then it will produce a log message to say its > not waiting on a transaction, its waiting on a lock. > > Nice. log_lock_waits

Re: [HACKERS] move collation import to backend

Andres Freund writes: > On 2016-11-29 12:16:37 -0500, Peter Eisentraut wrote: >> Required to avoid compiler warning about missing prototype. > It seems not to be project style to have prototypes in the middle of the > file... I agree. Please put that in builtins.h, if you

Re: [HACKERS] Exclude pg_largeobject form pg_dump

2016-11-29 17:12 GMT+01:00 Stephen Frost : > Guillaume, Amul, > > * Amul Sul (sula...@gmail.com) wrote: > > The following review has been posted through the commitfest application: > > make installcheck-world: tested, passed > > Implements feature: tested, passed > >

Re: [HACKERS] GiST support for UUIDs

I wrote: > I'm kind of inclined to change uuid_parts_distance to just convert > a given pg_uuid_t to "double" and then apply penalty_num(), as is > done in gbt_macad_penalty. Pushed with that change and some other mostly-cosmetic tweaking. One not too cosmetic fix was that gbt_uuid_union was

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Thu, Nov 24, 2016 at 5:46 PM, Mithun Cy wrote: > I have taken this suggestion now renamed target_server_type to > target_session_attrs with possible 2 values "read-write", "any". > May be we could expand to "readonly" and "prefer-readonly" in next patch > proposal.

Re: [BUGS] [HACKERS] object_classes array is broken, again

Alvaro Herrera wrote: > Jaimin Pan wrote: > > Hi all, > > > > How about this patch. I believe it will never missing someone and be > > detected while compiling. > > Hmm, yeah this looks like something that's worth considering going > forward. I can't think of any reason not to do this. Perhaps

Re: [HACKERS] move collation import to backend

On 2016-11-29 12:16:37 -0500, Peter Eisentraut wrote: > On 11/12/16 10:38 AM, Andres Freund wrote: > >>/* > >> * Also forbid matching an any-encoding entry. This test of course is > >> not > >> * backed up by the unique index, but it's not a problem since we don't > >> * support

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Corey, I agree that the boolean tests available should be *very* simple, and all of the weight of complex calculation should be put in SQL, like we do with \gset Yes. I propose those be: \if STRING : true if STRING evaluates to true via ParseVariableBool, empty means false Yep.

[HACKERS] [PATCH] Add diff directives to gitattributes

Hi hackers, Attached is a patch which adds diff= directives to .gitattributes for C, Perl and (X|SG)ML files. This makes word diffs and the function indicator in the diff chunk header and more useful. >From 57d7d4ec5b94783bf68b2959128e33c28547a6b8 Mon Sep 17 00:00:00 2001 From:

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

> > > Hmmm. Would you have an example use case that could not be done simply > with the previous ifs? cpp did that end ended up with a single if in the > end. I think this is what you're asking for... $ cat not_defined.sql select :'foo'; $ psql postgres --no-psqlrc -f not_defined.sql --set

Re: [HACKERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013

* Michael Paquier wrote: > On Wed, Nov 16, 2016 at 12:45 PM, Christian Ullrich > wrote: >> I also did a debug build with 1+2+4 that came in at 84 μs/iteration. > > Moved to next CF. Christian, perhaps this patch should have an extra > round of reviews? It is significantly

Re: [HACKERS] UNDO and in-place update

On Tue, Nov 29, 2016 at 8:21 AM, Amit Kapila wrote: > On Mon, Nov 28, 2016 at 11:01 PM, Robert Haas > wrote: > > On Sun, Nov 27, 2016 at 10:44 PM, Amit Kapila > wrote: > >> On Mon, Nov 28, 2016 at 4:50 AM, Robert Haas

Re: [HACKERS] pg_hba_file_settings view patch

On Tue, Nov 22, 2016 at 9:46 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > It could be because of some un-initialised variable, which is > initialized appropriately by default on your machine but not on my > machine. I first applied your pg_hba_rules... patch, ran regression. >

Re: [HACKERS] Parallel execution and prepared statements

Amit Kapila wrote: >> But with Tobias' complete patch "make installcheck-world" succeeds. > > Okay. I have looked into patch proposed and found that it will > resolve the regression test problem (Create Table .. AS Execute). I > think it is slightly prone to breakage if tomorrow we implement

Re: [HACKERS] make default TABLESPACE belong to target table.

On Mon, Nov 28, 2016 at 6:19 PM, Amit Kapila wrote: > On Sat, Nov 26, 2016 at 9:46 PM, Tom Lane wrote: >> >> If we just did points 1 and 2 then a bool GUC would suffice. I'm >> not sure how to handle all three cases cleanly. We could define >>

[HACKERS] EvalPlanQual() doesn't follow LockTuple() pattern

src/backend/access/heap/README.tuplock says we do this... LockTuple() XactLockTableWait() mark tuple as locked by me UnlockTuple() only problem is we don't... because EvalPlanQualFetch() does this XactLockTableWait() LockTuple() If README.tuplock's reasons for the stated lock order is correct

[HACKERS] XactLockTableWait doesn't set wait_event correctly

New (9.4) XactLockTableWait() sets the reason for the wait, so that if we emit a log message then it will produce a log message to say its not waiting on a transaction, its waiting on a lock. Nice. log_lock_waits works great. New (9.6) wait_event code is not correctly set. In ProcSleep() we set

Re: [HACKERS] Parallel execution and prepared statements

On Tue, Nov 29, 2016 at 4:40 PM, Albe Laurenz wrote: > Amit Kapila wrote: >>> But with Tobias' complete patch "make installcheck-world" succeeds. >> >> Okay. I have looked into patch proposed and found that it will >> resolve the regression test problem (Create Table ..

Re: [HACKERS] commitfest 2016-11 status summary

Hi All, The commitfest status summary after four weeks of progress: Needs review: 48 Waiting on author: 25 Ready for Commiter: 12 Commited: 36 Moved to next CF: 15 Rejected: 5 Returned with feedback: 6 TOTAL: 147 Overall progress of completion - 42% week-1 progress of completion - 9% week-2

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

2016-11-29 8:44 GMT+01:00 Fabien COELHO : > > Hello, > > I think it's really time we seriously considered adding some flow >>> control logic, though. >>> >> >> Yeah, maybe. I'd be interested to see a fully worked out proposal >> for that. >> > > I agree that designing a

Re: [HACKERS] Parallel execution and prepared statements

On Fri, Nov 18, 2016 at 9:01 PM, Albe Laurenz wrote: > Amit Kapila wrote: >> Can you once test by just passing CURSOR_OPT_PARALLEL_OK in >> PrepareQuery() and run the tests by having forc_parallel_mode=regress? >> It seems to me that the code in the planner is changed for

Re: [HACKERS] Declarative partitioning - another take

On 2016/11/17 20:27, Amit Langote wrote: > On 2016/11/16 4:21, Robert Haas wrote: >> Have you done any performance testing on the tuple routing code? >> Suppose we insert a million (or 10 million) tuples into an >> unpartitioned table, a table with 10 partitions, a table with 100 >> partitions, a

Re: [HACKERS] make default TABLESPACE belong to target table.

Amit Kapila writes: > Another point to think in this regard is what if tomorrow somebody > requests something similar for Create Materialized View? Isn't it > better to introduce a GUC default_tablespace_parent or > default_parent_tablespace? That's exactly what I have in mind :) -- Sent via

Re: [HACKERS] Contains and is contained by operators of inet datatypes

> I do not like this bit from the original post: > > EH> The patch removes the recently committed SP-GiST index support for the > EH> existing operator symbols to give move reason to the users to use the > EH> new symbols. I reverted this part. The new version of the patch is attached.

Re: [HACKERS] pg_hba_file_settings view patch

Here's backtrace and some debugging information Program terminated with signal 11, Segmentation fault. #0 0x007f96cd in shm_mq_sendv (mqh=0x121e998, iov=0x7ffc9b7b79f0, iovcnt=2, nowait=1 '\001') at shm_mq.c:357 357Assert(mq->mq_sender == MyProc); (gdb) where #0

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On Sat, Nov 26, 2016 at 4:48 PM, Tom Lane wrote: > Haribabu Kommi writes: > > Currently the casting is supported from macaddr to macaddr8, but not the > > other way. This is because, not all 8 byte MAC addresses can be converted > > into 6 byte

Re: [HACKERS] XactLockTableWait doesn't set wait_event correctly

On Tue, Nov 29, 2016 at 6:26 AM, Simon Riggs wrote: > New (9.4) XactLockTableWait() sets the reason for the wait, so that if > we emit a log message then it will produce a log message to say its > not waiting on a transaction, its waiting on a lock. > > Nice. log_lock_waits

Re: [HACKERS] [PATCH] Add diff directives to gitattributes

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Attached is a patch which adds diff= directives to .gitattributes for C, > Perl and (X|SG)ML files. This makes word diffs and the function > indicator in the diff chunk header and more useful. Could you provide some examples

Re: [HACKERS] patch: function xmltable

2016-11-30 2:40 GMT+01:00 Craig Ringer : > On 30 November 2016 at 05:36, Pavel Stehule > wrote: > > > The problem is in unreserved keyword "PASSING" probably. > > Yeah, I think that's what I hit when trying to change it. > > Can't you just

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

David Fetter writes: > On Tue, Nov 29, 2016 at 01:10:06PM +0100, Fabien COELHO wrote: >> If there is a negative condition syntax, I would slightly prefer \ifnot to >> \if_not or worse \unless. I would disaprove strongly of \unless because it >> looses the clear symmetry with a

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On Mon, Nov 28, 2016 at 2:01 PM, Michael Paquier wrote: > On Thu, Nov 24, 2016 at 11:15 PM, Andreas Karlsson wrote: >> Never mind, I had not fetched the latest master. Once I had done so these >> tests were both broken in my rebased branch and in the

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Tuesday, November 22, 2016, Robert Haas wrote: > On Fri, Nov 18, 2016 at 3:23 PM, Peter Eisentraut > > wrote: > > On 11/17/16 12:30 AM, Tsunakawa, Takayuki wrote: > >> No, I'm not recommending a higher value, but just

Re: [HACKERS] Parallel bitmap heap scan

On Fri, Nov 25, 2016 at 6:55 PM, Dilip Kumar wrote: > I have changed the design to directly make it based on DSA instead of using > DHT. > In new version we no longer use DHT. Instead, of that I have made some > change in simplehash[1], so that it can allow external

Re: [HACKERS] pg_recvlogical --endpos

On Wednesday, November 30, 2016 10:34 AM Craig Ringer wrote: >On 30 November 2016 at 09:18, Okano, Naoki > wrote: >> >> On November 29, 2016 at 5:03 PM Craig Ringer wrote: >>> Would it be better rephrased as "--endpos can only be used with --start" ? >>

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Tue, Nov 29, 2016 at 01:10:06PM +0100, Fabien COELHO wrote: > If there is a negative condition syntax, I would slightly prefer \ifnot to > \if_not or worse \unless. I would disaprove strongly of \unless because it > looses the clear symmetry with a closing \fi. I take it \sselnu is right out.

Re: [HACKERS] Random number generation, take two

On Tue, Nov 29, 2016 at 10:02 PM, Heikki Linnakangas wrote: > Ok, here's my second attempt at refactoring random number generation. > Previous attempt crashed and burned, see > https://www.postgresql.org/message-id/e1bw3g3-0003st...@gemulon.postgresql.org. > This addresses the

Re: [HACKERS] pg_recvlogical --endpos

On November 29, 2016 at 5:03 PM Craig Ringer wrote: > Would it be better rephrased as "--endpos can only be used with --start" ? OK. I think this phrase is better than the previous phrase. >> The patch should allow --endpos to work with --create-slot. > > How? It doesn't make sense with

Re: [HACKERS] pg_recvlogical --endpos

On 30 November 2016 at 09:18, Okano, Naoki wrote: > > On November 29, 2016 at 5:03 PM Craig Ringer wrote: >> Would it be better rephrased as "--endpos can only be used with --start" ? > OK. I think this phrase is better than the previous phrase. > >>> The patch should

Re: [HACKERS] patch: function xmltable

On 30 November 2016 at 05:36, Pavel Stehule wrote: > The problem is in unreserved keyword "PASSING" probably. Yeah, I think that's what I hit when trying to change it. Can't you just parenthesize the expression to use operators like || etc? If so, not a big deal.

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Wed, Nov 30, 2016 at 1:44 AM, Robert Haas wrote: >On Tue, Nov 29, 2016 at 2:19 PM, Kuntal Ghosh wrote: >> I was doing some testing with the patch and I found some inconsistency >> in the error message. > Hmm, maybe the query buffer is

Re: [HACKERS] GiST support for UUIDs

On Tue, Nov 29, 2016 at 1:13 PM, Tom Lane wrote: > Pushed with that change and some other mostly-cosmetic tweaking. Thank you for addressing all those issues, Tom! I tested some exclusion constraints that are interesting to me, and everything seems to be working well. --

Re: [HACKERS] [PATCH] Add diff directives to gitattributes

On Wed, Nov 30, 2016 at 5:16 AM, Tom Lane wrote: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >> Attached is a patch which adds diff= directives to .gitattributes for C, >> Perl and (X|SG)ML files. This makes word diffs and the function >> indicator

[HACKERS] Random number generation, take two

Ok, here's my second attempt at refactoring random number generation. Previous attempt crashed and burned, see https://www.postgresql.org/message-id/e1bw3g3-0003st...@gemulon.postgresql.org. This addresses the issues pointed out in that thread. The goals are: * Have a pg_strong_random()

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Pavel, Now, the psql statements are designed do nothing in syntax error. I am not sure about be more strict in this case. I see strong advantages - but it can be little bit different than current behave. Indeed, an error on a conditional construct should stop the script, which is

[HACKERS] tiny psql doc inconsistency

Hello, While reading the documentation, I noticed an tiny inconsistency at the end of: https://www.postgresql.org/docs/devel/static/app-psql.html testdb=> SELECT first, second, first > 2 AS gt2 FROM my_table; first | second | ge2 ---++- 1 | one| f

Re: [HACKERS] tiny psql doc inconsistency

Fabien, * Fabien COELHO (coe...@cri.ensmp.fr) wrote: > While reading the documentation, I noticed an tiny inconsistency at > the end of: > > https://www.postgresql.org/docs/devel/static/app-psql.html > > testdb=> SELECT first, second, first > 2 AS gt2 FROM my_table; > first | second |

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote: > But I realized that doing it this way is simple enough; > and furthermore, in any platforms where int is 8 bytes (ILP64), this > would automatically allow for 63-bit-sized stringinfos On such platforms there's the next problem that we can't send COPY rows through

Re: [HACKERS] Proposal for changes to recovery.conf API

On 14 November 2016 at 15:50, Robert Haas wrote: > On Sat, Nov 12, 2016 at 11:09 AM, Andres Freund wrote: >> I'm very tempted to rename this during the move to GUCs > ... >> Slightly less so, but still tempted to also rename these. They're not >>

Re: [HACKERS] Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

On 22 November 2016 at 17:49, Kyotaro HORIGUCHI wrote: >> > Yeah, I definitely don't think it's as simple as just using >> > procsignal_sigusr1_handler as-is. I expect we'd likely create a new >> > global IsWalSender and ignore some RecoveryConflictInterrupt

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Tom, But really, \fi is something that could only be loved by a certain academic breed of hackers. Ah ah:-) I'll take that as a compliment:-) I'd go for \endif, probably. That still doesn't relate well with \unless, so +1 for \if, \ifnot, \else, and \endif. Ok, that is a clear

Re: [HACKERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013

On Tue, Nov 29, 2016 at 08:45:13PM +0100, Christian Ullrich wrote: > * Michael Paquier wrote: > > > On Wed, Nov 16, 2016 at 12:45 PM, Christian Ullrich > > wrote: > >> I also did a debug build with 1+2+4 that came in at 84 μs/iteration. > > > > Moved to next CF. Christian,

Re: [HACKERS] Compiler warnings

* Stephen Frost (sfr...@snowman.net) wrote: > diff --git a/src/backend/utils/cache/plancache.c > b/src/backend/utils/cache/plancache.c > new file mode 100644 > index 884cdab..b5d97c8 > *** a/src/backend/utils/cache/plancache.c > --- b/src/backend/utils/cache/plancache.c > ***

Re: [HACKERS] Dynamic shared memory areas

More review: + * For large objects, we just stick all of the allocations in fullness class + * 0. Since we can just return the space directly to the free page manager, + * we don't really need them on a list at all, except that if someone wants + * to bulk release everything allocated using this

Re: [HACKERS] Tackling JsonPath support

On Mon, Nov 28, 2016 at 10:37 PM, Pavel Stehule wrote: > > > 2016-11-29 7:34 GMT+01:00 Christian Convey : > >> On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule >> wrote: >> >>> ​​ >>> We now support XPath function -

Re: [HACKERS] Tackling JsonPath support

On Tue, Nov 29, 2016 at 05:18:17PM +0100, Petr Jelinek wrote: > Just to add to this, the SQL/JSON proposals I've seen so far, and what > Oracle, MSSQL and Teradata chose to implement already is basically > subset of jsonpath (some proposals/implementations also include > lax/strict prefix keyword

Re: [HACKERS] Thinko in set_rel_consider_parallel()

Amit Langote writes: > The following looks like a thinko, which fixed in attached: > -Oid proparallel = func_parallel(... > +charproparallel = func_parallel(... Pushed, thanks. regards, tom

[HACKERS] Compiler warnings

Greetings, Not sure if anyone else has been seeing these, but I'm getting a bit tired of them. Neither is a live bug, but they also seem pretty simple to fix. The attached patch makes both of these warnings go away. At least for my common build, these are the only warnings that are thrown.

Re: [HACKERS] Patch to implement pg_current_logfile() function

Hi Gilles, On Sun, 27 Nov 2016 21:54:46 +0100 Gilles Darold wrote: > I've attached the v15 of the patch that applies your changes/fixes ... Per the following: On Mon, 21 Nov 2016 13:17:17 -0500 Robert Haas wrote: > It would really be much

Re: [HACKERS] Tackling JsonPath support

On 29/11/16 07:37, Pavel Stehule wrote: > > > 2016-11-29 7:34 GMT+01:00 Christian Convey >: > > On Mon, Nov 28, 2016 at 9:28 PM, Pavel Stehule > >wrote: > >

Re: [HACKERS] Exclude pg_largeobject form pg_dump

Guillaume, Amul, * Amul Sul (sula...@gmail.com) wrote: > 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

Re: [HACKERS] Tackling JsonPath support

On 29/11/16 17:28, Nico Williams wrote: > On Tue, Nov 29, 2016 at 05:18:17PM +0100, Petr Jelinek wrote: >> Just to add to this, the SQL/JSON proposals I've seen so far, and what >> Oracle, MSSQL and Teradata chose to implement already is basically >> subset of jsonpath (some

Re: [HACKERS] Tackling JsonPath support

On Tue, Nov 29, 2016 at 8:18 AM, Petr Jelinek wrote: ... > Just to add to this, the SQL/JSON proposals I've seen so far, and what > Oracle, MSSQL and Teradata chose to implement already is basically > subset of jsonpath (some proposals/implementations also include >

Re: [HACKERS] move collation import to backend

On 11/12/16 10:38 AM, Andres Freund wrote: > E.g. what if previously present collations are now unavailable? You get an error message when you try to use the collation. I think that is a different class of problems. >> >> /* >> * Also forbid matching an any-encoding entry. This

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

> > My 0,02 €, which is just a personal opinion: > > I think that handling manually "!/not" would be worth the effort rather > than having two commands, especially if the boolean expression syntax may > be extended some day and the negative if would become obsolete. > > If there is a negative

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Mon, Nov 28, 2016 at 1:20 PM, Jim Nasby wrote: > On 11/28/16 11:53 AM, Joshua D. Drake wrote: > >> On 11/28/2016 11:40 AM, Jim Nasby wrote: >> >>> With current limits, the most bgwriter can do (with 8k pages) is 1000 >>> pages * 100 times/sec = 780MB/s. It's not hard

Re: [HACKERS] Improving RLS planning

On Mon, Nov 28, 2016 at 6:55 PM, Stephen Frost wrote: >> diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README >> [...] >> + Additional rules will be needed to support safe handling of join quals >> + when there is a mix of security levels among join quals;

Re: [HACKERS] GiST support for UUIDs

Chris Bandy writes: > [ btree_gist_uuid_8.patch ] Um ... is there a reason why the penalty logic in gbt_uuid_penalty() is completely unlike that for any other btree_gist module? As best I can tell from the (admittedly documentation-free) code elsewhere, the penalty ought

Re: [HACKERS] Improving RLS planning

Robert Haas writes: > On Mon, Nov 28, 2016 at 6:55 PM, Stephen Frost wrote: >> Are you thinking that we will be able to remove the cut-out in >> is_simple_subquery() which currently punts whenever an RTE is marked as >> security_barrier? That would

Re: [HACKERS] Improving RLS planning

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Nov 28, 2016 at 6:55 PM, Stephen Frost wrote: > >> diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README > >> [...] > >> + Additional rules will be needed to support safe handling of join quals

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Daniel Verite wrote: > If we consider what would happen with the latest patch on a platform > with sizeof(int)=8 and a \copy invocation like this: > > \copy (select big,big,big,big,big,big,big,big,.. FROM > (select lpad('', 1024*1024*200) as big) s) TO /dev/null > > if we put enough

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Mon, Nov 28, 2016 at 11:25 PM, Andres Freund wrote: > On 2016-11-28 09:55:00 -0500, Robert Haas wrote: >> I think we should go with this approach. I don't think it's a good >> idea to have the heapam layer know about executor slots. > > I agree that that's not pretty. > >>

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Thu, Nov 24, 2016 at 7:16 AM, Mithun Cy wrote: > On Wed, Nov 23, 2016 at 10:19 PM, Catalin Iacob > wrote: >On Tue, Nov 22, 2016 at 8:38 AM, Tsunakawa, Takayuki > wrote: > >> If you want to connect to a

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Mon, Nov 28, 2016 at 11:17 PM, Dilip Kumar wrote: > Actually we want to call slot_getattr instead heap_getattr, because of > problem mentioned by Andres upthread and we also saw in test results. Ah, right. > Should we make a copy of HeapKeyTest lets say ExecKeyTest and