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.
>>
>> I'm not sure that I'm
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 I
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 creation,
> > that's great; if pg
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
> okay. You, or somebody els
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, does it need to be
>
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 sophisticated than that? I
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 actions.
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 ReplicationS
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
>
> 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
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 that.
> Seems like overkill. Let's just redu
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 expression
evaluation an
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 is rather ugly; it looks to
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():
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363866(v=v
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 create a user
>> in t
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 previ
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.
>>
>>> + if (GetProgressRecPtr() > last_switch_lsn)
>>
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"
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, use
19 matches
Mail list logo
