Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Fri, Sep 30, 2016 at 04:23:13PM +1300, Thomas Munro wrote: > On Thu, Sep 29, 2016 at 6:19 PM, David Fetter wrote: > > On Thu, Sep 29, 2016 at 11:12:11AM +1300, Thomas Munro wrote: > >> On Mon, Sep 26, 2016 at 5:11 PM, Thomas Munro > >> wrote: >

Re: [HACKERS] Commit fest 2017-01 will begin soon!

On Tue, Dec 27, 2016 at 12:41 PM, Michael Paquier wrote: > There are still a couple of days to register patches! So if you don't > want your fancy feature to be forgotten, please add it in time to the > CF app. Speaking of which, I am going to have a low bandwidth soon

Re: [HACKERS] Make pg_basebackup -x stream the default

On Sat, Dec 31, 2016 at 9:24 PM, Magnus Hagander wrote: > On Tue, Dec 20, 2016 at 11:53 PM, Michael Paquier > wrote: >> Recovery tests are broken by this patch, the backup() method in >> PostgresNode.pm uses pg_basebackup -x: >> sub backup >> { >>

[HACKERS] Fixing pgbench's logging of transaction timestamps

pgbench's -l option is coded using inappropriate familiarity with the contents of struct instr_time. I recall complaining about that when the code went in, but to little avail. However, it needs to be fixed if we're to switch over to using clock_gettime() as discussed in the gettimeofday thread,

Re: [HACKERS] safer node casting

I wrote: > Just to bikeshed a bit ... would "castNode" be a better name? Um ... -ENOCAFFEINE. Never mind that bit. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] proposal: session server side variables

2016-12-31 18:46 GMT+01:00 Fabien COELHO : > >DROP VARIABLE super_secret; >>>CREATE VARIABLE super_secret ...; >>> >> >> But you don't do it in functions - these variables are persistent - you >> don't create it or drop inside functions. The content is secure, so you

Re: [HACKERS] safer node casting

Peter Eisentraut writes: > I propose a macro castNode() that combines the assertion and the cast, > so this would become > RestrictInfo *rinfo = castNode(RestrictInfo, lfirst(lc)); Seems like an OK idea, but I'm concerned by the implied multiple evaluations,

Re: [HACKERS] proposal: session server side variables

> > If you do not have expectations, then all is fine. > > (1) Having some kind of variable, especially in interactive mode, allows to >>> manipulate previous results and reuse them later, without having to >>> resort >>> to repeated sub-queries or to retype non trivial values. >>> >>> Client side

Re: [HACKERS] proposal: session server side variables

DROP VARIABLE super_secret; CREATE VARIABLE super_secret ...; But you don't do it in functions - these variables are persistent - you don't create it or drop inside functions. The content is secure, so you don't need to hide this variable against other. ISTM that you are still missing

Re: [HACKERS] proposal: session server side variables

Hello Craig, As for "slow", I have just tested overheads with pgbench, comparing a direct arithmetic operation (as a proxy to a fast session variable consultation) to constant returning plpgsql functions with security definer and security invoker, on a direct socket connection, with prepared

Re: [HACKERS] proposal: session server side variables

2016-12-31 17:51 GMT+01:00 Fabien COELHO : > > unexpectedly, that would be missed by a PL/pgSQL analysis tool... There is >>> no miracle. >>> >> >> No - metadata, in my design, are persistent - like tables - so you don't >> calculate so any functions can drop a variables. The

[HACKERS] safer node casting

There is a common coding pattern that goes like this: RestrictInfo *rinfo = (RestrictInfo *) lfirst(lc); Assert(IsA(rinfo, RestrictInfo)); (Arguably, the Assert should come before the cast, but I guess it's done this way out of convenience.) (Not to mention the other common coding

Re: [HACKERS] cast result of copyNode()

Peter Eisentraut writes: > In order to reduce the number of useless casts and make the useful casts > more interesting, here is a patch that automatically casts the result of > copyNode() back to the input type, if the compiler supports something > like typeof(),

Re: [HACKERS] proposal: session server side variables

unexpectedly, that would be missed by a PL/pgSQL analysis tool... There is no miracle. No - metadata, in my design, are persistent - like tables - so you don't calculate so any functions can drop a variables. The deployment of secure variables is same like table deployment. No dynamic there.

Re: [HACKERS] Add doc advice about systemd RemoveIPC

Magnus Hagander writes: > I still think that some wording in the direction of the fact that the > majority of all users won't actually have this problem is the right thing > to do (regardless of our previous history in the area as pointed out by > Craig) +1. The

Re: [HACKERS] tab complete regress tests

On 12/31/16 4:09 AM, Pavel Stehule wrote: > now the code in tabcomplete become large part of psql. Is there some > possibility to write regress tests? I started on that a while ago with some Perl Expect module. The use of the module was a bit cumbersome, but it worked OK. The problem is that

Re: [HACKERS] tab complete regress tests

Em sáb, 31 de dez de 2016 às 07:11, Pavel Stehule escreveu: > Hi > > now the code in tabcomplete become large part of psql. Is there some > possibility to write regress tests? > > I found only this link > > >

[HACKERS] Replication/backup defaults

Cycling back to this topic again, but this time at the beginning of a CF. Here's an actual patch to change: wal_level=replica max_wal_senders=10 max_replication_slots=20 Based on feedback from last year (

Re: [HACKERS] Add doc advice about systemd RemoveIPC

On Sat, Dec 31, 2016 at 6:30 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/30/16 3:59 AM, Magnus Hagander wrote: > > I wonder if I missed part of the discussions around this, so maybe my > > understanding of the cases where this occurs is wrong, but isn't it the > > case

Re: [HACKERS] identity columns

Updated patch with some merge conflicts resolved and some minor bug fixes. Vitaly's earlier reviews were very comprehensive, and I believe I have fixed all the issues that have been pointed out, so just double-checking that would be helpful at this point. I still don't have a solution for

Re: [HACKERS] Supporting huge pages on Windows

On Wed, Sep 28, 2016 at 2:26 AM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > > On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki > >

Re: [HACKERS] port of INSTALL file generation to XSLT

On Sat, Dec 31, 2016 at 6:57 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > A further step toward getting rid of the DSSSL tool chain requirement, > here is a patch to change the generation of the text INSTALL file to use > XLST and Pandoc. > > The change to Pandoc is not

Re: [HACKERS] Make pg_basebackup -x stream the default

On Tue, Dec 20, 2016 at 11:53 PM, Michael Paquier wrote: > On Tue, Dec 20, 2016 at 10:38 PM, Fujii Masao > wrote: > > On Mon, Dec 19, 2016 at 7:51 PM, Vladimir Rusinov > wrote: > >> The server must also be configured with

Re: [HACKERS] Make pg_basebackup -x stream the default

On Tue, Dec 20, 2016 at 2:38 PM, Fujii Masao wrote: > On Mon, Dec 19, 2016 at 7:51 PM, Vladimir Rusinov > wrote: > > > > On Sat, Dec 17, 2016 at 2:37 PM, Magnus Hagander > > wrote: > >> > >> Attached is an updated patch that does

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Sat, Dec 3, 2016 at 1:38 AM, Haribabu Kommi wrote: > Moved to next CF with "waiting on author" status. Unfortunately it's been a bit trickier than I anticipated to get the interprocess batch file sharing and hash table shrinking working correctly and I don't yet have

[HACKERS] tab complete regress tests

Hi now the code in tabcomplete become large part of psql. Is there some possibility to write regress tests? I found only this link http://stackoverflow.com/questions/22795767/how-to-test-python-readline-completion Regards Pavel

[HACKERS] logical decoding of two-phase transactions

Here is resubmission of patch to implement logical decoding of two-phase transactions (instead of treating them as usual transaction when commit) [1] I’ve slightly polished things and used test_decoding output plugin as client. General idea quite simple here: * Write gid along with