pt extension that use them and allow
to see what are the autovacuum worker todo list, skipped tables and so on.
I'm not really sure about which information should be provided, so I'm
open to any suggestion to improve this.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/s
On 29/02/2016 20:20, Fabrízio de Royes Mello wrote:
>
> On Mon, Feb 29, 2016 at 3:04 PM, Julien Rouhaud
> mailto:julien.rouh...@dalibo.com>> wrote:
>>
>> On 04/06/2015 22:10, Guillaume Lelarge wrote:
>> > 2015-01-05 17:44 GMT+01:00 Guillaume Lel
On 01/03/2016 07:50, Michael Paquier wrote:
> On Tue, Mar 1, 2016 at 4:38 AM, Julien Rouhaud
> wrote:
>> On 29/02/2016 20:20, Fabrízio de Royes Mello wrote:
>>>
>>> On Mon, Feb 29, 2016 at 3:04 PM, Julien Rouhaud
>>> mailto:julien.rouh...@dalibo.com
On 01/03/2016 13:47, Fabrízio de Royes Mello wrote:
> On Tue, Mar 1, 2016 at 8:44 AM, Julien Rouhaud
> mailto:julien.rouh...@dalibo.com>> wrote:
>>
>> On 01/03/2016 07:50, Michael Paquier wrote:
>> > On Tue, Mar 1, 2016 at 4:38 AM, Julien Rouhaud
>> >
On 01/03/2016 20:29, Jim Nasby wrote:
> On 3/1/16 8:37 AM, Julien Rouhaud wrote:
>>> >
>>> >We understood (IMHO is an interesting idea) but as Michael said
>>> hooks is
>>> >for a general purpose. So can you demonstrate other use cases for this
>&
On 02/03/2016 07:30, Michael Paquier wrote:
> On Tue, Mar 1, 2016 at 11:37 PM, Julien Rouhaud wrote:
>> I'm not sure what are the fancy things that Michael had in mind with
>> exposing the private structure. Michael, was it something like having
>> the ability to change
On 03/03/2016 10:54, Kyotaro HORIGUCHI wrote:
> Hello,
>
> At Wed, 2 Mar 2016 17:48:06 -0600, Jim Nasby wrote
> in <56d77bb6.6080...@bluetreble.com>
>> On 3/2/16 10:48 AM, Julien Rouhaud wrote:
>>> Good point, I don't see a lot of information available wi
On 04/03/2016 23:34, Michael Paquier wrote:
> On Sat, Mar 5, 2016 at 6:52 AM, Julien Rouhaud
> wrote:
>> Very good suggestion.
>>
>> I think the most productive way to work on this is to start a wiki page
>> to summarize what's the available information,
On 10/03/2016 04:37, Petr Jelinek wrote:
> On 17/02/16 01:17, Julien Rouhaud wrote:
>>
>> Agreed, it's too obscure. Attached v4 fixes as you said.
>>
>
> Seems to be simple enough patch and works. However I would like
> documentation to say that the range i
could add a specific test for this case to spare a random() call, but
I fear it'd be overkill. Maybe it's better to document that the good way
to deactivate auto_explain is to set auto_explain.log_min_duration to -1.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pg
On 11/03/2016 15:11, Magnus Hagander wrote:
>
>
> On Fri, Mar 11, 2016 at 3:03 PM, Magnus Hagander <mailto:mag...@hagander.net>> wrote:
>
>
>
> On Fri, Mar 11, 2016 at 2:51 PM, Julien Rouhaud
> mailto:julien.rouh...@dalibo.com>> wrote:
&
That'd be more consistent.
>
> I like that idea. It seems like slightly better terminology.
>
I like it too. I also just noticed that I duplicated the var type by
mistake in the documentation :/
Attached patch fixes both.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.or
#x27;t be
> hard to review.
>
+ reason_wait = indexInfo->ii_ExclusionOps ?
+ XLTW_RecheckExclusionConstr : XLTW_InsertIndex;
Shouldn't it be set to XLTW_InsertIndexUnique instead?
Otherwise the patch seems ok to me.
> Thanks
>
--
Julien
On 15/03/2016 14:18, Stephen Frost wrote:
> * Julien Rouhaud (julien.rouh...@dalibo.com) wrote:
>> On 15/03/2016 03:30, Peter Geoghegan wrote:
>>> On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan wrote:
>>>> Attached patch fixes a bug reported privately by Step
hold GUC documentation, because I didn't really see a good
way to explain it. I'd e happy to improve it if needed. Also, to make
this parameter easier to tune for users, perhaps we could divide the
default value by 3 and use it as is in the first iteration in
create_parallel_path() ?
Als
On 16/03/2016 05:45, James Sewell wrote:
> On Wed, Mar 16, 2016 at 11:26 AM, Julien Rouhaud
> mailto:julien.rouh...@dalibo.com>>wrote:
>
>
> I'm not too familiar with parallel planning, but I tried to implement
> both in attached patch. I di
On 18/03/2016 00:56, Tom Lane wrote:
> Julien Rouhaud writes:
>> Shouldn't we also check "parallel_degree < max_worker_process" ?
>
>> There's no need to compute any further than that. I think the best fix
>> would be to add a CheckHook or Assign
On 16/03/2016 18:42, Robert Haas wrote:
> On Wed, Mar 16, 2016 at 1:23 PM, Julien Rouhaud
> wrote:
>> On 16/03/2016 17:55, Robert Haas wrote:
>>> On Wed, Mar 16, 2016 at 12:47 PM, Julien Rouhaud
>>> wrote:
>>>> Something like a "min_parallel_degr
On 16/03/2016 18:42, Robert Haas wrote:
> On Wed, Mar 16, 2016 at 1:23 PM, Julien Rouhaud
> wrote:
>> On 16/03/2016 17:55, Robert Haas wrote:
>>> On Wed, Mar 16, 2016 at 12:47 PM, Julien Rouhaud
>>> wrote:
>>>> Something like a "min_parallel_degr
On 17/03/2016 02:07, James Sewell wrote:
>
> On Thu, Mar 17, 2016 at 5:05 AM, Julien Rouhaud
> mailto:julien.rouh...@dalibo.com>> wrote:
>
>
> attached v3 drops the GUC part.
>
>
> This looks good good. I do think that some threshold control would be
>
On 17/03/2016 11:23, Julien Rouhaud wrote:
> On 17/03/2016 02:07, James Sewell wrote:
>>
>> On Thu, Mar 17, 2016 at 5:05 AM, Julien Rouhaud
>> mailto:julien.rouh...@dalibo.com>> wrote:
>>
>>
>> attached v3 drops the GUC part.
>>
>>
On 16/03/2016 17:55, Robert Haas wrote:
> On Wed, Mar 16, 2016 at 12:47 PM, Julien Rouhaud
> wrote:
>> Something like a "min_parallel_degree" then ?
>
> Why not just parallel_degree without any prefix? As in, when scanning
> this table in parallel, the rel
On 17/03/2016 12:21, David Rowley wrote:
> On 18 March 2016 at 00:13, Julien Rouhaud wrote:
>> With the current threshold, you need a table bigger than 8 MB to be able
>> to force parallel workers. I'm not sure there'll be benefits for
>> multiple workers on a
On 16/03/2016 17:16, Robert Haas wrote:
> On Tue, Mar 15, 2016 at 8:26 PM, Julien Rouhaud
> mailto:julien.rouh...@dalibo.com>> wrote:
>
> On 15/03/2016 21:12, Robert Haas wrote:
> > On Mon, Mar 14, 2016 at 9:25 PM, David Rowley
> > mailto:david.row...
that. It also makes sure that the chosen
parallel_degree won't be more than the relation's estimated number of pages.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/ref/create_table.sgml
b/doc/src/sgml/ref/create_table.sgml
index cd234db..80e
On 21/03/2016 20:38, Julien Rouhaud wrote:
> On 21/03/2016 05:18, James Sewell wrote:
>> OK cool, thanks.
>>
>> Can we remove the minimum size limit when the per table degree setting
>> is applied?
>>
>> This would help for tables with 2 - 1000 pages com
worker has built it's "TODO list", and after
> every (auto)vacuum.
The main issue I see with an event trigger based solution is that you'll
always have to create them and the needed objects on every database.
Another issue is that both of these approach are not intended to give
On 14/01/2016 01:30, David Rowley wrote:
> Many thanks for the thorough review!
>
And thanks for the patch and fast answer!
> On 12 January 2016 at 23:37, Julien Rouhaud <mailto:julien.rouh...@dalibo.com>> wrote:
>
>
> In identify_key_vars()
>
> +
On 14/01/2016 14:04, Geoff Winkless wrote:
> On 14 January 2016 at 11:19, Julien Rouhaud wrote:
>> + /* don't try anything unless there's two Vars */
>> + if (varlist == NULL || list_length(varlist) < 2)
>> +
On 14/01/2016 14:29, Geoff Winkless wrote:
> On 14 January 2016 at 13:16, Julien Rouhaud wrote:
>> You're absolutely right, but in this case the comment is more like a
>> reminder of a bigger comment few lines before that wasn't quoted in my mail
>
> Fair enough, a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/01/2016 23:05, David Rowley wrote:
> On 15 January 2016 at 00:19, Julien Rouhaud
> mailto:julien.rouh...@dalibo.com>>
> wrote:
>
>
> +* Technically we could look at UNIQUE indexes
On 15/01/2016 22:59, Jeff Janes wrote:
> On Sun, Jan 10, 2016 at 4:24 AM, Julien Rouhaud
> wrote:
>> On 29/12/2015 00:30, Jeff Janes wrote:
>>> On Wed, Nov 25, 2015 at 9:29 AM, Jeff Janes wrote:
>>>>
>>>> I'll prepare a patch for core for the Jan
lock should be safe, as pointed by Alvaro and Jaime earlier in this
thread
(http://www.postgresql.org/message-id/20151119161846.GK614468@alvherre.pgsql),
as ginInsertCleanup() can be called concurrently.
Also, since 38710a374ea the ginInsertCleanup() call must be fixed:
- ginInsertCleanu
lating this behavior with the pre-existing one (and not documenting
>> it) is confusing as can be. A bit more work on regression test cases
>> seems indicated.
>
> The history behind that is that at one point during developing the
> patch that test had started failing due to the g
On 23/01/2016 14:51, David Rowley wrote:
> On 24 January 2016 at 00:56, Julien Rouhaud wrote:
>> I wonder if in remove_useless_groupby_columns(), in the foreach loop you
>> could change the
>>
>> + if (bms_subset_compare(pkattnos, relattnos) == BMS_SUBSET1)
>
On 27/01/2016 10:27, Fujii Masao wrote:
> On Mon, Jan 25, 2016 at 3:54 PM, Jeff Janes
> wrote:
>> On Wed, Jan 20, 2016 at 6:17 AM, Fujii Masao
>> wrote:
>>> On Sat, Jan 16, 2016 at 7:42 AM, Julien Rouhaud
>>> wrote:
>>>> On 15/01/2016 22:59, Jeff
On 25/08/2015 14:45, Michael Paquier wrote:
> On Fri, Jul 17, 2015 at 2:53 PM, Craig Ringer wrote:
>> On 7 July 2015 at 21:37, Julien Rouhaud wrote:
>>
>>> Well, I obviously missed that pg_srand48() is only used if the system
>>> lacks random/srandom, sorry for
On 16/02/2016 22:51, Alvaro Herrera wrote:
> Julien Rouhaud wrote:
>
> Hijacking this macro is just too obscure:
>
>> #define auto_explain_enabled() \
>> (auto_explain_log_min_duration >= 0 && \
>> - (nesting_level == 0 || auto_explain_log_ne
Hello,
I just saw that the CREATE OPERATOR CLASS documentation doesn't mention
that BRIN indexes also support the STORAGE parameter.
Patch attached.
Regards
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/ref/create_opclass.sgml b/doc/src/sgm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/02/2016 23:12, Vik Fearing wrote:
> On 02/25/2016 09:13 PM, Julien Rouhaud wrote:
>> Hello,
>>
>> I just saw that the CREATE OPERATOR CLASS documentation doesn't
>> mention that BRIN indexes also support the ST
places, but it may be useful for some people.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
say.
My only remark is on following comment:
+ * LWLockHeldByMeInMode - test whether my process holds a lock in mode X
Maybe something like "test whether my process holds a lock in given
mode" would be better?
Otherwise, I think they're ready for committer.
--
Julien Rouhaud
http
On 05/09/2016 11:55, Julien Rouhaud wrote:
> On 20/06/2016 06:28, Thomas Munro wrote:
>> On Mon, Jun 20, 2016 at 3:43 PM, Craig Ringer wrote:
>>> On 18 June 2016 at 11:28, Thomas Munro
>>> wrote:
>>>> Several times now when reading, debugging and writing co
addr_abbrev_convert() doesn't mention
specific little-endian handling
* "There will be two bytes of zero padding on the least significant end"
"least significant bits" would be better
* This patch will trigger quite a lot modifications after a pgindent
run. Could you try
matter here?
>
After some more thinking, it looks like a reorder here won't have any
impact. I'll remove it, unless Amit has an objection about it.
> + {"max_parallel_workers", PGC_USERSET, RESOURCES_ASYNCHRONOUS,
> + gettext_noop(
Hi,
Hugo Mercier (in Cc) reported me an error in a query, failing since pg10.
Simple test case to reproduce:
CREATE TABLE public.test (id integer);
WITH test AS (select 42) INSERT INTO public.test SELECT * FROM test;
which will fail with "relation "test" cannot be the target of a
modifying stat
On Mon, Oct 9, 2017 at 10:43 PM, Thomas Munro
wrote:
>
> I suppose we could consider moving the schemaname check into
> getRTEForSpecialRelationType(), since otherwise both callers need to
> do that (and as you discovered, one forgot).
Thanks for the feedback. That was my first idea, but I assum
On Fri, Oct 13, 2017 at 5:22 AM, Tom Lane wrote:
> Thomas Munro writes:
>> On Fri, Oct 13, 2017 at 12:46 PM, Tom Lane wrote:
>>> Yeah, I agree --- personally I'd never write a query like that. But
>>> the fact that somebody ran into it when v10 has been out for barely
>>> a week suggests that p
On Thu, Oct 12, 2017 at 2:46 AM, Michael Paquier
wrote:
> On Thu, Oct 12, 2017 at 9:05 AM, Robert Haas wrote:
>> On Wed, Oct 4, 2017 at 9:00 PM, Michael Paquier
>> wrote:
>>> v4 looks correct to me. Testing it through (pgbench and some custom
>>> queries) I have not spotted issues. If the final
On Thu, Oct 19, 2017 at 1:08 AM, Michael Paquier
wrote:
> On Thu, Oct 19, 2017 at 4:12 AM, Robert Haas wrote:
>> On Wed, Oct 18, 2017 at 9:20 AM, Julien Rouhaud wrote:
>>> WIth current pgssHashKey definition, there shouldn't be padding bits,
>>> so it should be
On Fri, Oct 20, 2017 at 3:44 PM, Robert Haas wrote:
> On Thu, Oct 19, 2017 at 2:11 AM, Julien Rouhaud wrote:
>> I agree, and I'm perfectly fine with adding a comment around pgssHashKey.
>>
>> PFA a patch to warn about the danger.
>
> Committed a somewhat differen
Hi,
I just noticed that get_default_partition_oid() tries to release the
tuple even if it isn't valid.
Trivial patch attached.
diff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c
index 07fdf66c38..66ec214e02 100644
--- a/src/backend/catalog/partition.c
+++ b/src/backend/
On Sat, Oct 28, 2017 at 11:13 AM, Robert Haas wrote:
> On Sat, Oct 28, 2017 at 10:03 AM, Julien Rouhaud wrote:
>> I just noticed that get_default_partition_oid() tries to release the
>> tuple even if it isn't valid.
>> Trivial patch attached.
>
> Oops. I wo
On Wed, Nov 1, 2017 at 12:22 PM, 高增琦 wrote:
> Any comments?
>
Hi,
You should register these patches for the next commitfest at
https://commitfest.postgresql.org/15/. As Michael pointed out earlier,
this commitfest will start soon so you should add your patches
quickly.
Regards.
--
Sent via
On 28/09/2016 18:46, Robert Haas wrote:
>
> Everybody seems happy with this fix for a first step, so I've
> committed it and back-patched it to 9.3.
>
Thanks!
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
I'll
try to implement it.
I've already fixed every other issues mentioned upthread, but I'm facing
a problem for this one. Assuming that the bgworker classes are supposed
to be mutually exclusive, I don't see a simple and clean way to add such
a check in SanityCheckBackgroundWork
e patch, and noticed that only plain DELETE and
UPDATE commands are handled. Is it intended that writable CTE without
WHERE clauses are not detected by this extension? I personally think
that wCTE should be handled (everyone can forget a WHERE clause), but if
not it should at least be documented.
On 30/09/2016 21:12, David Fetter wrote:
> On Fri, Sep 30, 2016 at 06:37:17PM +0200, Julien Rouhaud wrote:
>> On 30/09/2016 05:23, Thomas Munro wrote:
>>>
>>> It would be really nice to be able to set this to 'Ready for
>>> Committer' in this
On 03/10/2016 21:27, Robert Haas wrote:
> On Fri, Sep 30, 2016 at 12:23 PM, Julien Rouhaud
> wrote:
>> I've already fixed every other issues mentioned upthread, but I'm facing
>> a problem for this one. Assuming that the bgworker classes are supposed
>> to be
Is it something that we should fix, and if yes is any of this
acceptable, or does someone see another way to solve this problem?
Regards.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On 10/10/2016 05:00, Jim Nasby wrote:
> On 10/7/16 4:39 AM, Julien Rouhaud wrote:
>> I see two ways of fixing this. First one would be to store normalized
>> queries while fully qualifiying the relation's names. After a quick look
>> this can't be done without stori
t a fan of that idea.
>
> Just use macaddr64 if you want wide MACs.
>
>
+1
and you can instead make macaddr64 support both format, and provide a
macaddr::macaddr64 cast
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 12/10/2016 14:32, Alvaro Herrera wrote:
> Julien Rouhaud wrote:
>
>> and you can instead make macaddr64 support both format, and provide a
>> macaddr::macaddr64 cast
>
> Having macaddr64 support both formats sounds nice, but how does it work?
> Will we have to re
On 16/10/2016 02:38, Jim Nasby wrote:
> On 10/10/16 12:58 AM, Julien Rouhaud wrote:
>> Unless you mean deparsing the Query instead of using raw source text? I
>> think that would solve this issue (and also the other issue when
>> multiple queries are submitted at once, y
re's any major difficulty here. I still hope we can find a way to
store the fully qualified objects name in the normalized query instead.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 16/10/2016 11:21, Craig Ringer wrote:
> On 16 Oct. 2016 14:31, Julien Rouhaud wrote:
>>
>> On 16/10/2016 02:38, Jim Nasby wrote:
>> > On 10/10/16 12:58 AM, Julien Rouhaud wrote:
>> >> Unless you mean deparsing the Query instead of using raw source
> tex
tion because there are commands that cannot or should not be
> used by different connections.
> To solve this, psql could keep a separate command history file for each
> connection.
You can already do this, for instance in your .psqlrc:
\set HISTFILE ~/.psql_history- :HOST - :PORT - :DBNAME
and a replica, enabling and
disabling track_commit_timestamp, and everything seemed to work as intended.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/src/backend/access/transam/commit_ts.c b/src/backend/access/transam/commit_ts.c
index a8d275f..7746578 100644
--- a/src/backend/access/
On 24/10/2016 06:58, Craig Ringer wrote:
> On 22 October 2016 at 19:51, Julien Rouhaud wrote:
>> I just noticed that if track_commit_timestamp is enabled, the
>> oldestCommitTsXid and newestCommitTsXid don't persist after a server
>> restart, so you can't ask for
It looks like pq_putmessage_hook and pq_flush_hook were meant for
development purpose and not supposed to be committed.
Attached patch remove them.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/src/include/libpq/libpq.h b/src/include/libpq/libpq.h
index 18052cb..5fac817
l! I've run the new version through pgindent.
>
Thanks also, no more issue here.
> Let me know if you have any further feedback and/or
> suggestions. Thanks!
One last thing, I noticed that you added:
+static int macaddr_internal_cmp(macaddr *a1, macaddr *a2);
but the existi
e (if necessary) as they're putting it into
> master?
I think picking the value with unused_oids as you dd is the right thing to do.
As Robert said, if this oid is used in another patch in the meantime, updating
it at commit time is not a big deal. Moreover, this patch will require a
catver
, which among other thing is used to regenerate query string from a
pgss normalized query, thus needing the original param location).
Is this something we want to get fixed? If yes, attached is a simple patch for
that.
Regards.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a
ite_time = 0;
+ }
(and similar ones)
The brackets seem unnecessary.
I marked the commitfest entry as waiting on author.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
A "condition" is missing, patch attached.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/planstats.sgml b/doc/src/sgml/planstats.sgml
index 8caf297f85..838fcda6d2 100644
--- a/doc/src/sgml/planstats.sgml
+++ b/doc/src/sgml/planstats.sgml
@@ -50
On Sat, Jun 17, 2017 at 10:24:32AM -0400, Peter Eisentraut wrote:
> On 6/15/17 15:19, Julien Rouhaud wrote:
> > Hi,
> >
> > I just found $SUBJECT, patch attached.
>
> fixed
Thanks!
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers
On 18/06/2017 01:03, Peter Eisentraut wrote:
> On 6/17/17 05:00, Julien Rouhaud wrote:
>> A "condition" is missing, patch attached.
>
> fixed
>
Thanks.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hac
Patch attached.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/ref/drop_publication.sgml
b/doc/src/sgml/ref/drop_publication.sgml
index 517d142251..8e45a43982 100644
--- a/doc/src/sgml/ref/drop_publication.sgml
+++ b/doc/src/sgml/ref/drop_publication.sgml
Patch attached.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/ref/insert.sgml b/doc/src/sgml/ref/insert.sgml
index 94dad00870..0e327e5b2e 100644
--- a/doc/src/sgml/ref/insert.sgml
+++ b/doc/src/sgml/ref/insert.sgml
@@ -228,7 +228,7 @@ INSERT INTO table_name
On Sun, Jun 18, 2017 at 07:42:54PM +0200, Magnus Hagander wrote:
> On Sun, Jun 18, 2017 at 8:46 AM, Julien Rouhaud
> wrote:
>
> > Patch attached.
> >
>
> Applied, thanks.
>
Thanks.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgs
On 20/06/2017 20:34, Peter Eisentraut wrote:
> On 6/18/17 03:16, Julien Rouhaud wrote:
>> Patch attached.
>
> This was not a typo, this was intentional.
>
Oh, sorry. I'm not a native english speaker, that sounded really weird.
--
Julien Rouhaud
http://dalibo.
sure we can simply rely on that - it's possible people will
> try to improve other index types (e.g. by adding similar compression to
> other index types).
That reminds me
https://www.postgresql.org/message-id/55e4051b.7020...@postgrespro.ru
where Anastasia proposed something simi
le to reproduce the issue if needed.
Should I add a regression test based on it?
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
segfault.sql
Description: application/sql
diff --git a/src/backend/executor/execSRF.c b/src/backend/executor/execSRF.c
index 138e86ac67..9d257d4d88 100644
---
On 15/07/2017 17:22, Tom Lane wrote:
> Julien Rouhaud writes:
>> Since b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755 (Andres in Cc), if you
>> write queries which result in infinite recursion (or just too many
>> nested function calls), execution ends with segfault instead of
-3.70]
Is it v11 material or is there any chance to make it in v10?
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 18/07/2017 14:04, Andres Freund wrote:
> On 2017-07-17 23:04:43 +0200, Julien Rouhaud wrote:
>> Is it v11 material or is there any chance to make it in v10?
>
> I think it'd make sense to apply the first to v10 (and earlier), and the
> second to v11. I think this isn&#
Hello,
Unless I miss something, \r isn't working anymore, since
exec_command_print() fallback to display previous_buf if query_buf has
been freed.
Trivial patch to fix issue (free both buffers in exec_command_reset())
attached.
Regards.
--
Julien Rouhaud
diff --git a/src/bin/psql/comman
On 20/07/2017 03:34, Tom Lane wrote:
> Julien Rouhaud writes:
>> Unless I miss something, \r isn't working anymore,
>
> Works for me. Please describe exactly what misbehavior you're seeing.
> What libreadline or libedit version are you using?
>
I have libreadlin
the relevant discussion:
> https://www.postgresql.org/message-id/flat/9b4ea968-753f-4b5f-b46c-d7d3bf7c8f90%40manitou-mail.org
>
Oh I see. Thanks a lot, sorry for the noise.
--
Julien Rouhaud
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
On Thu, Jul 20, 2017 at 5:44 AM, Peter Geoghegan wrote:
> On Wed, Jul 19, 2017 at 8:33 PM, Craig Ringer wrote:
>> That's silly, so here's a patch to teach pageinspect how to decode infomasks
>> to a human readable array of flag names.
>>
>> Example:
>>
>> SELECT t_infomask, t_infomask2, flags
>>
llbacks now are static.
Thanks for working on it. Just in case, I reviewed the patch and didn't
find any issue with it.
--
Julien Rouhaud
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 26, 2017 at 7:11 AM, Pavel Stehule wrote:
> Hi
>
> I wrote a special pager for psql. Surely, this pager is not good for paging
> of man pages. So is not good to set it as global pager. We can introduce new
> env variable PSQL_PAGER for this purpose. It can work similar like
> PSQL_EDIT
On 31/07/2017 01:47, Andres Freund wrote:
> Julien, could you quickly verify that everything's good for you now too?
>
I just checked on current HEAD
(cc9f08b6b813e30789100b6b34110d8be1090ba0) and everything's good for me.
Thanks!
--
Julien Rouhaud
http://dalibo.com - h
ne) fixes this issue for me, but I have no idea if
this is the right fix.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
y
>>> don't care and they remain happy because of the other improvements) or
>>> notably so, in which case they can easily figure where to add the
>>> MATERIALIZED option and regain the original performance.
>>
>> +1 for option 1. This change will be welc
p9zxeo...@mail.gmail.com
BTW Andres added support for likely/unlikely in aa3ca5e3dd6, but its
usage is still really limited.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
I just found this typo while doing french translation, patch attached.
Regards.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
index ad11109775..8dcc29925b 100644
--- a/doc/src/sgml/brin.sgml
+++ b/doc/src/sgml/brin.sgml
On Tue, Jun 13, 2017 at 11:29:30AM -0400, Peter Eisentraut wrote:
> On 6/13/17 07:53, Julien Rouhaud wrote:
> > I just found this typo while doing french translation, patch attached.
>
> fixed
>
Thanks !
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgs
Hi,
I just found $SUBJECT, patch attached.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/doc/src/sgml/ref/create_subscription.sgml
b/doc/src/sgml/ref/create_subscription.sgml
index 77bf87681b..3ca06fb3c3 100644
--- a/doc/src/sgml/ref/create_subscription.sgml
+++ b/doc/src
On Thu, Aug 31, 2017 at 5:30 AM, Peter Eisentraut
wrote:
> On 3/20/17 11:03, Ronan Dunklau wrote:
>>> Great idea. This is too late for v10 at this point, but please add it
>>> to the next CommitFest so we don't forget about it.
>> I know it is too late, and thought that it was too early to add it
1 - 100 of 174 matches
Mail list logo
