Re: [HACKERS] pgbench - allow backslash continuations in \set expressions

FWIW, I looked a bit further and concluded that probably psqlscan.l doesn't need to be modified; so likely you could do this across all of pgbench's commands without touching psql. That might be an acceptable compromise for now, though I still think that as soon as we have this for pgbench,

Re: [HACKERS] Add support for restrictive RLS policies

Stephen, I looked through this in a little more detail and I found one other issue: the documentation for the system catalog table pg_policy and the view pg_policies needs to be updated to include the new columns that have been added. Other than that, it all looks good to me, subject to the

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_splitbucket_guts

On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich wrote: > Amit Kapila writes: > >> How should I connect to this database? If I use the user fdw >> mentioned in pg_hba.conf (changed authentication method to trust in >> pg_hba.conf), it says the user doesn't exist. Can you

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_splitbucket_guts

Amit Kapila writes: > How should I connect to this database? If I use the user fdw > mentioned in pg_hba.conf (changed authentication method to trust in > pg_hba.conf), it says the user doesn't exist. Can you create a user > in the database which I can use? There is also a superuser "postgres"

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Fri, Dec 2, 2016 at 9:50 AM, Michael Paquier wrote: > On Wed, Nov 30, 2016 at 7:53 PM, Amit Kapila wrote: >>> + * Switch segment only when WAL has done some progress since the >> + * > last time a segment has switched because of a timeout.

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

On Wed, Nov 16, 2016 at 08:45:20PM +, Christian Ullrich wrote: > * Noah Misch wrote: > > I prefer the simplicity of abandoning the cache (patch 4), if it > > performs decently. Would you compare the performance of patch 1, > > patches 1+2+3, and patches 1+2+4? This should measure the right

Re: [HACKERS] Parallel execution and prepared statements

> I think if we don't see any impact then we should backpatch this > patch. However, if we decide to go some other way, then I can provide > a separate patch for back branches. BTW, what is your opinion? I could not find anything on backporting guidelines in the wiki but my opinion would be to

[HACKERS] Better support for symlinks on Windows...

Hi all. I just bumped into the following post: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#IAHXCu04bDmrrhxi.97 But... That's still Windows-specific as it uses a non-POSIX routine CreateSymbolicLink():

Re: [HACKERS] [COMMITTERS] pgsql: Add max_parallel_workers GUC.

Robert Haas writes: > On Dec 2, 2016, at 5:45 PM, Tom Lane wrote: >> Might work. We've had very bad luck with GUC variables with >> interdependent defaults, but maybe the user-visible knob could be a >> percentage of max_connections or something like

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

On Fri, Dec 2, 2016 at 3:11 AM, Andres Freund wrote: > Hm. I'm more than a bit doubful about this approach. Shouldn't we just > *always* do this as part of expression evaluation, instead of > special-casing for seqscans? That make sense, we can actually do this as part of

Re: [HACKERS] patch: function xmltable

Pavel Stehule wrote: > 2016-12-02 23:25 GMT+01:00 Alvaro Herrera : > > This is looking much better now, but it still needs at least the > > following changes. > > > > First, we need to fix is the per_rowset_memcxt thingy. I think the way > > it's currently being used

Re: [HACKERS] Logical Replication WIP

I massaged the temporary replication slot patch a bit. I changed the column name in pg_stat_replication_slots from "persistent" to "temporary" and flipped the logical sense, so that it is consistent with the creation commands. I also adjusted some comments and removed some changes in

Re: [HACKERS] [COMMITTERS] pgsql: Use latch instead of select() in walreceiver

On 12/1/16 8:50 PM, Michael Paquier wrote: > + if (rc & WL_POSTMASTER_DEATH) > + exit(1); > Hmm. We have always been very careful about not leaving immediately > from libpqwalreceiver.c which is an independent shared library so as > the WAL receiver can take cleanup

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Nov 7, 2016 at 8:28 PM, Peter Geoghegan wrote: > What do we need to teach pg_restore about parallel CREATE INDEX, if > anything at all? Could this be as simple as a blanket disabling of > parallelism for CREATE INDEX from pg_restore? Or, does it need to be > more

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

Peter Geoghegan wrote: > On Mon, Nov 7, 2016 at 8:28 PM, Peter Geoghegan wrote: > > What do we need to teach pg_restore about parallel CREATE INDEX, if > > anything at all? Could this be as simple as a blanket disabling of > > parallelism for CREATE INDEX from pg_restore? Or,

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sat, Dec 3, 2016 at 5:45 PM, Alvaro Herrera wrote: > I don't think a patch must necessarily consider all possible uses that > the new feature may have. If we introduce parallel index creation, > that's great; if pg_restore doesn't start using it right away, that's >

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sat, 2016-12-03 at 18:37 -0800, Peter Geoghegan wrote: > On Sat, Dec 3, 2016 at 5:45 PM, Alvaro Herrera com> wrote: > > > > I don't think a patch must necessarily consider all possible uses > > that > > the new feature may have.  If we introduce parallel index

Re: [HACKERS] Document how to set up TAP tests for Perl 5.8.8

On Mon, Nov 21, 2016 at 11:58:34AM +0800, Craig Ringer wrote: > Updated docs patch. Since configure checks for 5.8.0 that's what's > specified. Anyone who wants to argue about the actual version we > _should_ target can do so elsewhere, all I'm interested in is what we > _do_ officially target so

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

2016-12-03 8:16 GMT+01:00 Fabien COELHO : > > Hello, > > My guess is that something comparable to where pgbench is would be a >> reasonable target --- not least because I think we should strive to >> reduce unnecessary differences between psql and pgbench metalanguages. >> >>