On 16 April 2016 at 04:27, Tom Lane wrote:
> Robert Haas writes:
>> I definitely agree that the current output is messed up, but I'm not
>> sure your proposed output is much better. I wonder if it shouldn't
>> say something like:
David Rowley writes:
> On 16 April 2016 at 04:27, Tom Lane wrote:
>> +1 for the latter, if we can do it conveniently. I think exposing
>> the names of the aggregate implementation functions would be very
>> user-unfriendly, as nobody but us
I made an unfortunate oversight in the logical decoding timeline following
code: it doesn't work for logical decoding from the walsender, because I
left the glue code required out of the final cut of the patch.
The reason the new src/test/recovery/ tests don't notice this is that using
Pgbench allows -f and -S combinations together where the doc says that -S
effectively uses the internal select-only script.
Is it okay to assume that -f is disregarded here? Or are they run in
round-robin fashion (although then, how does it know which read-only part
of my script to run?) or
> Second, I don't think it will improve and become performant without
> exposure to a wider audience.
Huh? The issue is a relatively simple to spot architectural issue
(taking a single exclusive lock during snapshot acquiration which only
needs shared locks otherwise) - I don't see how any input
On Thu, Apr 14, 2016 at 8:05 AM, Andres Freund wrote:
> On 2016-04-14 07:59:07 +0530, Amit Kapila wrote:
> > What you want to see by prewarming?
> Prewarming appears to greatly reduce the per-run variance on that
> machine, making it a lot easier to get meaningful results.
As part of the work I did on timeline following for logical decoding I
mapped out the various code paths relating to timeline following in Pg.
It's surprisingly complex (to me), with lots of completely separate logic
for each different
On Fri, Apr 15, 2016 at 1:59 AM, Alexander Korotkov <
> On Thu, Apr 14, 2016 at 5:35 AM, Andres Freund wrote:
>> On 2016-04-14 07:59:07 +0530, Amit Kapila wrote:
>> > What you want to see by prewarming?
>> Prewarming appears to greatly
On 4/16/16 4:44 PM, Noah Misch wrote:
> The key judgment to finalize here is whether it's okay to release this feature
> given its current effect, when enabled, on performance. That is more
> controversial than the potential ~2% regression for old_snapshot_threshold=-1.
> Alvaro and
## Terence Ferraro (terencejferr...@gmail.com):
> At the moment, if a user has multiple applications on a single machine
> connecting with different SSL certificates, each process must be launched
> by a different logical user and the certificates placed within that user's
> home directory (and
Here's an interesting scenario I happened across recently.
If you have a single line in the pg_hba.conf:
hostssl all all 0.0.0.0/0 md5
Attempting to log in with an incorrect password results in an
error message about there not being a pg_hba.conf entry for the
Reading carefully, the
On Tue, Apr 12, 2016 at 9:53 AM, Teodor Sigaev wrote:
> With pending cleanup patch backend will try to get lock on metapage with
> ConditionalLockPage. Will it interrupt autovacum worker?
Correct, ConditionalLockPage should not interrupt the autovacuum worker.
I'm not sure if this may be of any utility value to anyone else, but, the
attached patch enables an environment variable to be provided to libpq to
specify where to find the SSL certificate/key files used for a secure
At the moment, if a user has multiple applications on a single
Kevin Grittner writes:
> On Wed, Mar 30, 2016 at 3:26 PM, Alvaro Herrera
>> Kevin Grittner wrote:
>>> On Wed, Mar 30, 2016 at 2:22 PM, Alvaro Herrera
>>> I said that we should change BufferGetPage into
On 17 April 2016 at 21:24, Fabien COELHO wrote:
> For the future 9.6, scripts options are cumulatives, so -f & -S can be
> Indeed, for the <= 9.5 it seems that some options are silently ignores,
> when combining -S/-f, only the last one is kept, it should be
On Thu, Apr 07, 2016 at 03:50:47PM -0400, Stephen Frost wrote:
> I'm planning to continue going over the patch tomorrow morning with
> plans to push this before the feature freeze deadline.
> --- a/src/test/regress/expected/rolenames.out
> +++ b/src/test/regress/expected/rolenames.out
On Sun, Apr 17, 2016 at 5:15 PM, Tom Lane wrote:
> Kevin Grittner writes:
>> On Wed, Mar 30, 2016 at 3:26 PM, Alvaro Herrera>
>>> Kevin Grittner wrote:
On Wed, Mar 30, 2016 at 2:22 PM, Alvaro Herrera
On Mon, Apr 18, 2016 at 9:52 AM, Kevin Grittner wrote:
> On Sun, Apr 17, 2016 at 5:15 PM, Tom Lane wrote:
>> Kevin Grittner writes:
>>> On Wed, Mar 30, 2016 at 3:26 PM, Alvaro Herrera>
On Sun, Apr 17, 2016 at 08:04:03PM -0400, Noah Misch wrote:
> On Thu, Apr 07, 2016 at 03:50:47PM -0400, Stephen Frost wrote:
> > I'm planning to continue going over the patch tomorrow morning with
> > plans to push this before the feature freeze deadline.
> > ---
On 04/15/2016 02:04 PM, Robert Haas wrote:
> Peter, are you going to look into this further? This is on the open
> items list, but there seems to be nothing that can be done about it by
> anyone other than, maybe, you.
I don't know if it's worth tracking this as an open item and thus
Tom Lane wrote:
> After struggling with back-patching a GIN bug fix, I wish to offer up the
> considered opinion that this was an impressively bad idea. It's inserted
> 450 or so pain points for back-patching, which we will have to deal with
> for the next five years. Moreover, I do not believe
At Sat, 16 Apr 2016 12:50:30 +0530, Amit Kapila wrote
On 18 April 2016 at 12:11, David Rowley
> this is not helping me much as I don't really understand why
> pg_statistic need to be frozen?
Yeah, in particular it's not clear to me why pg_upgrade goes to such
efforts to freeze everything when it copies
On 2016/04/15 18:48, Ashutosh Bapat wrote:
> With the new set of patches, I am getting following warnings but no
> compilation failures. Patches apply smoothly.
> partition.c:1216:21: warning: variable ‘form’ set but not used
On Mon, Apr 18, 2016 at 12:05 PM, Noah Misch wrote:
> On Sun, Apr 17, 2016 at 08:04:03PM -0400, Noah Misch wrote:
>> On Thu, Apr 07, 2016 at 03:50:47PM -0400, Stephen Frost wrote:
>> > I'm planning to continue going over the patch tomorrow morning with
>> > plans to push this
Hello, now the synchronous_standby_names can teach to ensure more
then one synchronous standbys. But the doc for it seems assuming
only one synchronous standby.
> There is no mechanism to enforce uniqueness. In case of
> duplicates one of the matching standbys will be considered as
I'd been wondering why a VACUUM FREEZE is performed during pg_upgrade,
so I opened up the code to see if that would help me determine why
I'm confronted with a comment, which states;
* We do freeze after analyze so pg_statistic is also frozen. template0 is
* not frozen here, but data
On Mon, Apr 18, 2016 at 12:31 PM, Peter Eisentraut wrote:
> I don't know if it's worth tracking this as an open item and thus
> kind-of release blocker if no one else has the problem. But I
> definitely still have it. My initial suspicion was that this had
> something to do
For the future 9.6, scripts options are cumulatives, so -f & -S can be
Indeed, for the <= 9.5 it seems that some options are silently ignores,
when combining -S/-f, only the last one is kept, it should be warned about.
Thanks Fabien, for confirming about the missing warning.
On Fri, Apr 15, 2016 at 6:56 PM, Magnus Hagander wrote:
> The documentation says that the default value is 128Kb on Linux, but the
> code says it's 256Kb.
> Not sure which one is correct, but the other one should be updated :) I'm
> guessing it's a copy/paste mistake in the
On Tue, Apr 05, 2016 at 05:50:18PM -0400, Stephen Frost wrote:
> I'll be doing more testing, review and clean-up (there are some
> whitespace only changes in the later patches that really should be
> included in the earlier patches where the code was actually changed)
> tonight with plans to push
On Tue, Apr 5, 2016 at 12:11 AM, Artur Zakirov wrote:
> There is a duplicated word in indexam.sgml. The patch is attached.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to
At Fri, 15 Apr 2016 17:36:57 +0900, Masahiko Sawada
> >> How about if we do all the parsing stuff in temporary context and then copy
> >> the results using TopMemoryContext? I don't think it
On 2016/04/15 18:46, Ashutosh Bapat wrote:
> 3. PartitionKeyData contains KeyTypeCollInfo, whose contents can be
> obtained by calling functions exprType, exprTypemod on partexprs. Why do we
> need to store that information as a separate member?
There was no KeyTypeCollInfo in early days
Mail list logo