On Mon, Mar 26, 2018 at 4:17 PM, Michael Paquier
wrote:
> On Mon, Mar 26, 2018 at 11:28:41AM +0900, Kyotaro HORIGUCHI wrote:
> > At Sun, 25 Mar 2018 22:27:09 +1100, Haribabu Kommi <
> kommi.harib...@gmail.com> wrote in wna+nve_ypukzbdaqrmut9...@mail.gmail.com>
> >> On Sun, Mar 25, 2018 at 12:56
On Thu, 22 Mar 2018 16:53:15 +0300
Dmitry Ivanov wrote:
> Hi David,
>
> I'd like to take over from Victor. I'll post a revised version of the
> patch in a couple of days.
>
Hi Dmitry,
Recently I worked with the old version of the patch and found a bug.
So, I think it is better to notify you
On Fri, Mar 23, 2018 at 08:01:53PM +0100, Magnus Hagander wrote:
> On Fri, Mar 23, 2018 at 7:58 PM, Andres Freund wrote:
>> I'm inclined to just ask them to stop running the animals on that
>> branch. There are no pre-existing users on 9.3 ppc64le, and new
>> customers hopefully won't move to 9.3.
On Sun, Mar 25, 2018 at 09:33:38PM -0400, Peter Eisentraut wrote:
> On 3/21/18 22:38, Michael Paquier wrote:
>> At least on Linux it is possible to rely on sync_file_range which is
>> called via pg_flush_data, so it seems to me that we ought to roughly
>> keep the loop working on FLUSH_DISTANCE, an
On Sun, Mar 25, 2018 at 11:27:31PM -0400, Stephen Frost wrote:
> AdvanceXLInsertBuffer() does quite a bit, so I'm a bit surprised to see
> this simply removing that call, you're confident there's nothing done
> which still needs doing..?
Have a look at BKP_REMOVABLE then. This was moved to page h
On Mon, Mar 26, 2018 at 11:28:41AM +0900, Kyotaro HORIGUCHI wrote:
> At Sun, 25 Mar 2018 22:27:09 +1100, Haribabu Kommi
> wrote in
>> On Sun, Mar 25, 2018 at 12:56 AM, Michael Paquier
>> wrote:
> As the commit message of 50cb21f70, the function is intended not
> to return NULL in order to preve
2018-03-25 18:02 GMT+02:00 Pavel Stehule :
>
>
> 2018-03-25 15:21 GMT+02:00 Fabien COELHO :
>
>>
>>
>> Hello Pavel,
>>
>> [...]
>>> it is correct. Default format is aligned, that doesn't use fieldsep.
>>>
>>
>> My comment is that currently fieldsep is kind of a variable, the value of
>> which
At Sun, 25 Mar 2018 22:15:52 +0900, "MauMau" wrote in
> And thank you for your review. All modifications are done.
Thank you for the new version. I marked this as "Ready for
Committer" with one change.
- Windows requires this since different versions (MT/non-MT and
DEBUG/RELEASE?) of CRT ar
On Sun, Mar 25, 2018 at 8:11 PM, Craig Ringer wrote:
> As others have noted, you'll want to find a way to handle this in the least
> SSL-implementation-specific manner possible. IMO if it can't work with
> OpenSSL, Windows's SSL implementation and OS X's SSL framework it's a
> non-starter.
+1.
>
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 03/18/18 19:28, Daniel Gustafsson wrote:
> > It seems expensive to regex over BLCKSZ, but it’s probably the safest option
> > and it’s not a performance critical codepath. Feel free to whack the test
> > patch over the head with the a
On 24 March 2018 at 03:01, Andres Freund wrote:
> Hi,
>
> On 2018-03-23 14:33:25 -0400, Tom Lane wrote:
> > func_cxt = AllocSetContextCreate(TopMemoryContext,
> > "PL/pgSQL function context",
> > ALLOCSET_DEFAULT_SIZES)
On 24 March 2018 at 02:33, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-03-23 18:05:38 +, Vladimir Sitnikov wrote:
> >> For instance, I assume statament cache is stored in some sort of a hash
> >> table, so there should be a way to enumerate it in a programmatic way.
> Of
> >> course
On 26 March 2018 at 06:00, Damir Simunic
wrote:
> > - Overhead for all clients. It may be tiny, but it needs to be
> > measured and that cost needs to be weighed against the benefits.
> > Maybe a cache miss in the context of a network connection is
> > negligible, but we do need to know.
>
>
On 2018/03/24 9:23, Alvaro Herrera wrote:
> I made a bunch of further edits and I think this v10 is ready to push.
> Before doing so I'll give it a final look, particularly because of the
> new elog(ERROR) I added. Post-commit review is of course always
> appreciated.
>
> Most notable change is b
At Sun, 25 Mar 2018 22:27:09 +1100, Haribabu Kommi
wrote in
> On Sun, Mar 25, 2018 at 12:56 AM, Michael Paquier
> wrote:
>
> > On Sat, Mar 24, 2018 at 01:49:28AM +1100, Haribabu Kommi wrote:
> > > Here I attached the updated patch that returns either the connected
> > > host/hostaddr
> > > or
Greetings,
* David Rowley (david.row...@2ndquadrant.com) wrote:
> On 16 March 2018 at 13:46, Tomas Vondra wrote:
> > I've done more testing on this patch, and I haven't found any new issues
> > with it, so PFA I'm marking it as ready for committer.
>
> Great! Many thanks for the review.
I read
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Mar 08, 2018 at 10:15:11AM +0900, Michael Paquier wrote:
> > Other than that the patch looks in pretty good shape to me.
>
> The regression tests of file_fdw are blowing up because of an error
> string patch 2 changes.
Fixed in
On 3/23/18 13:16, Bruce Momjian wrote:
> Also, it would be nice if users could easily know if pg_upgrade is going
> to use COW or not because it might affect whether they choose --link or
> not. Right now it seems unclear how a user would know. Can we have
> pg_upgrade --check perhaps output some
On 3/21/18 22:38, Michael Paquier wrote:
> At least on Linux it is possible to rely on sync_file_range which is
> called via pg_flush_data, so it seems to me that we ought to roughly
> keep the loop working on FLUSH_DISTANCE, and replace the calls of
> read/write by copy_file_range. copyfile is on
On Sun, Mar 25, 2018 at 11:32 AM, Andrew Dunstan
wrote:
> On Sun, Mar 25, 2018 at 3:55 AM, Tom Lane wrote:
>> I noticed that doing pgindent with the current typedefs list available
>> from the buildfarm caused a lot of havoc in what had been stable code.
>> Looking into the reasons, it seems that
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sat, Mar 24, 2018 at 11:14:34PM -0400, Tom Lane wrote:
> > Stephen Frost writes:
> >> I don't completely buy off on the argument that having these #define's
> >> would make it easier for forks (we've had quite a few folks fork PG, but
I have just released version 7 of the PostgreSQL Buildfarm client.
As well as a few fairly minor bug fixes, it contains the following features:
. skip doing the pg_upgrade test in the TestUpgrade module if TAP
tests are configured and there is a src/bin/pg_upgrade/t directory
. add a --check-warn
On 25 March 2018 at 23:43, David Rowley wrote:
> With the attached applied, I'm happy to mark the patch as ready for
> committer, however, Petr is also signed up to review, so will defer to
> him to see if he has any comments before altering the commitfest app's
> state.
Petr won't have time to l
On Sun, Mar 25, 2018 at 9:13 PM, David Rowley
wrote:
> On 25 March 2018 at 20:09, David Rowley wrote:
>> On 15 March 2018 at 21:33, Andrew Dunstan
>> wrote:
>>> rebased and mostly indented patch version attached.
>>
>> Thanks. I've attached a version of this which applies, builds and
>> passes t
> On 25 Mar 2018, at 19:42, David Fetter wrote:
>
> On Sat, Mar 24, 2018 at 06:52:47PM +0100, Damir Simunic wrote:
>> Hello hackers,
>>
>> I’d like to propose the implementation of new wire protocol using http2
>> framing.
>
> Welcome to the PostgreSQL community! This is a very interesting i
On Thu, Mar 22, 2018 at 11:16:30AM -0700, legrand legrand wrote:
> Reading other pg_stat_statements threads on this forum, there are also activ
> developments to add:
> - planing duration,
> - first date,
> - last_update date,
> - parameters for normalized queries,
> - ...
> as described in
> http:
Tom>One concrete objection to the above is it'd obscure hierarchical
relationships in the context tree,
What is the problem with relationships? Context names are aligned as well
provided 8192 is justified to 6-7-8-9 (you pick) characters.
Tom>But given the lack of previous complaints
1) Here it
On Sun, Mar 25, 2018 at 02:28:29PM -0400, Tom Lane wrote:
> Arthur Zakirov writes:
> > If all dictionaries will be shareable then this view could be removed.
> > Unfortunately I think it can't help with leaked segments, I didn't find
> > a way to iterate dshash entries. That's why pg_ts_shared_dic
On Sun, Mar 25, 2018 at 12:18:10AM -0400, Tom Lane wrote:
> My thought was (a) the ROLLBACK case is ok, because the next use of
> the dictionary will reload it, and (b) the reload-concurrently-with-
> DROP case is annoying, because indeed it leaks, but the window is small
> and it probably won't be
On 3/21/18 17:14, Bossart, Nathan wrote:
> Here is an updated set of patches that use the newly proposed approach
> for avoiding division-by-zero errors in pg_resetwal.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Traini
Arthur Zakirov writes:
> On Sat, Mar 24, 2018 at 04:56:36PM -0400, Tom Lane wrote:
>> * And that leads us to not particularly need a view telling which
>> dictionaries are loaded, either. It's just an implementation detail
>> that users don't need to worry about.
> If all dictionaries will be sh
Vladimir Sitnikov writes:
> Tom>Well, as I said, you can do anything you want now in an extension.
> That is true. However it basically means "everybody who cares to
> troubleshoot the memory use of a production system should install an
> extension".
If you're interested in capturing memory usag
Tom>Well, as I said, you can do anything you want now in an extension.
That is true. However it basically means "everybody who cares to
troubleshoot the memory use of a production system should install an
extension".
Should
https://wiki.postgresql.org/wiki/Developer_FAQ#Examining_backend_memory_us
On Sat, Mar 24, 2018 at 06:52:47PM +0100, Damir Simunic wrote:
> Hello hackers,
>
> I’d like to propose the implementation of new wire protocol using http2
> framing.
Welcome to the PostgreSQL community! This is a very interesting idea.
Please send a patch to this mailing list on this thread.
Vladimir Sitnikov writes:
>> While I didn't do anything about it here, I think it'd likely be a
>> good idea for MemoryContextStats printout to truncate the context ID
>> strings at 100 characters or so
> It would be great if there was an option to show full sql.
Well, as I said, you can do anyt
It looks much better.
>While I didn't do anything about it here, I think it'd likely be a
>good idea for MemoryContextStats printout to truncate the context ID
>strings at 100 characters or so
It would be great if there was an option to show full sql.
For instance, current statistics is not sorte
2018-03-25 15:21 GMT+02:00 Fabien COELHO :
>
>
> Hello Pavel,
>
> [...]
>>>
>> it is correct. Default format is aligned, that doesn't use fieldsep.
>>
>
> My comment is that currently fieldsep is kind of a variable, the value of
> which is displayed and reliable wrt commands executed afterwards, a
John Naylor writes:
> -I shortened the data example in the README so it would comfortably
> fit on two lines. Spreading it out over three lines doesn't match
> what's in the data files. It's valid syntax, but real data is
> formatted to at most two lines (See rewrite_dat.pl. Hmm, maybe I
> should
Hello Pavel,
[...]
it is correct. Default format is aligned, that doesn't use fieldsep.
My comment is that currently fieldsep is kind of a variable, the value of
which is displayed and reliable wrt commands executed afterwards, and the
proposed approach changes that by adding a new "defau
From: Kyotaro HORIGUCHI
The objective of this patch looks reasonable and this doesn't
affect ecpg applications except for the problematic case that
happens only on Windows. So the points here are only the
documentation, the new function name and the how we should place
the new defintion.
I think
Hi all,
While looking at pg_rewind code, I have been surprised to find that the
final fsync done on the target's data folder is done using initdb -S via
a system() call. This is in my opinion overcomplicated because we have
a dedicated API in fe_utils able to do a fsync on a data folder, called
f
Hm, I took a look on both thread about patch and it seems to me now it's
overcomplicated. With recently committed enhancements of pgbench (\if,
\when) it becomes close to impossible to retry transation in case of
failure. So, initial approach just to rollback such transaction looks
more attra
On 3/21/18, Tom Lane wrote:
> The attached is just one incremental patch on top of your v11 series.
> I couldn't think of an easy way to migrate the changes back into the
> most relevant diffs of your series, so I didn't try.
I've applied your changes to the v12 patch series (attached), but I
hop
On Sun, Mar 25, 2018 at 12:56 AM, Michael Paquier
wrote:
> On Sat, Mar 24, 2018 at 01:49:28AM +1100, Haribabu Kommi wrote:
> > Here I attached the updated patch that returns either the connected
> > host/hostaddr
> > or NULL in case if the connection is not established.
> >
> > I removed the retu
Hello Doug,
Updated the patch to not do the #undef
pgbench11-ppoll-v11.patch attached.
Patch applies. Do not forget to regenerate configure to test...
I've compiled and run with both ppoll & select options without issues.
Two quite minor style comment (at least 2 instances):
if (cond) re
On 25 March 2018 at 20:09, David Rowley wrote:
> On 15 March 2018 at 21:33, Andrew Dunstan
> wrote:
>> rebased and mostly indented patch version attached.
>
> Thanks. I've attached a version of this which applies, builds and
> passes the regression tests on current master.
>
> Some conflicts were
On Sun, Mar 25, 2018 at 06:45:08AM +0200, Tomas Vondra wrote:
> FWIW this is where the view listing dictionaries loaded into shared
> memory would be helpful - you'd at least know there's a dictionary,
> wasting memory.
Unfortunately, It seems that this view can't help in listing leaked
segments.
On Sat, Mar 24, 2018 at 04:56:36PM -0400, Tom Lane wrote:
> Arthur Zakirov writes:
> > [ v10 patch versions ]
Thank you for the review, Tom!
Tomas Vondra wrote:
> Tom Lane wrote:
>> * I cannot imagine a use-case for setting max_shared_dictionaries_size
>> to anything except "unlimited". If it's
On Sat, Mar 24, 2018 at 11:14:34PM -0400, Tom Lane wrote:
> Stephen Frost writes:
>> I don't completely buy off on the argument that having these #define's
>> would make it easier for forks (we've had quite a few folks fork PG, but
>> how many of them have actually changed "base"?) and I'm on the
49 matches
Mail list logo
