Hi, the attached is the revised version.
- defined allnotnull instead of full_ordered in RelOptInfo and
changed to use it.
- compare_pathkeys_ignoring_strategy() is now integrated into
compare_pathkeys().
- index pathkeys caching in RelOptInfo
added. (build_index_pathkeys() does)
On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
here is a proposed patch - autocomplete for known psql variable content
Even after applying the patch, the following psql variables were not displayed
on the tab-completion of \set command.
HISTFILE
HISTSIZE
2014-07-15 11:29 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
here is a proposed patch - autocomplete for known psql variable content
Even after applying the patch, the following psql variables were not
On Tue, Jul 15, 2014 at 7:01 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2014-07-15 11:29 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
here is a proposed patch - autocomplete for known psql
On Thu, Jul 10, 2014 at 11:10 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
Hi,
At 1047 line of receivelog.c:CopyStreamPoll(), we set NULL to
timeoutptr variable.
if the value of timeoutprt is set NULL then the process will wait
until can read socket using by select() function as
Kaigai-san,
2014-07-14 22:18 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp:
Hanada-san,
Thanks for your checking. The attached v4 patch is rebased one on the
latest master branch. Indeed, merge conflict was trivial.
Updates from the v3 are below:
- custom-plan.sgml was renamed to
On Thu, Jun 19, 2014 at 4:13 PM, MauMau maumau...@gmail.com wrote:
From: Michael Paquier michael.paqu...@gmail.com
You are right, I only though about the MS scripts when working on this
patch. Updated patch for a complete cleanup is attached (note I
updated manually ./configure for test
On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jun 19, 2014 at 4:13 PM, MauMau maumau...@gmail.com wrote:
From: Michael Paquier michael.paqu...@gmail.com
You are right, I only though about the MS scripts when working on this
patch. Updated patch for a
On Sat, May 10, 2014 at 4:10 PM, MauMau maumau...@gmail.com wrote:
From: Amit Kapila amit.kapil...@gmail.com
I think it's bit late for this patch for 9.4, you might want to move it to
next CF.
Thanks, I've moved it. It's a regret that this very small patch wasn't put
in 9.4.
i took a
On Tue, Jul 15, 2014 at 2:14 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jun 19, 2014 at 4:13 PM, MauMau maumau...@gmail.com wrote:
From: Michael Paquier michael.paqu...@gmail.com
You are right, I
On Tue, Jul 15, 2014 at 9:20 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Jul 15, 2014 at 2:14 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Of course someone else than the patch author with a MinGW environment
at hand is invited to test.
Thanks!
I think that's enough -
On Tue, Jul 15, 2014 at 1:08 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jul 12, 2014 at 8:49 AM, Magnus Hagander mag...@hagander.net wrote:
It's today really hard to figure out if your SSL connection is
actually *using* SSL compression. This got extra hard when we the
default value
On Tue, Jul 1, 2014 at 6:25 AM, Dilip kumar dilip.ku...@huawei.com wrote:
On 01 July 2014 03:48, Alvaro Wrote,
In particular, pgpipe is almost an exact duplicate between them,
except the copy in vac_parallel.c has fallen behind changes made to
parallel.c. (Those changes would have fixed
On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
In short, maybe we ought to invent a new category PGC_SU_BACKEND (not
wedded to this spelling), which is to PGC_BACKEND as PGC_SUSET is to
PGC_USERSET, ie same when-it-can-be-changed behavior but only superusers
are
From: Magnus Hagander mag...@hagander.net
Is there a reason for there still being changes in guc.c, pgevent.c
etc? Shouldn't it all be confined to pg_ctl now? That's my
understanding from the thread that that's the only part we care about.
Yes, strictly speaking, those are useful for the
On Tue, Jul 15, 2014 at 4:01 PM, MauMau maumau...@gmail.com wrote:
From: Magnus Hagander mag...@hagander.net
Is there a reason for there still being changes in guc.c, pgevent.c
etc? Shouldn't it all be confined to pg_ctl now? That's my
understanding from the thread that that's the only part
Robert Haas robertmh...@gmail.com writes:
Dunno. Was hoping someone else had an idea. It'd certainly be nice
to have some way of calling functions like this without specifying the
shape of the return value, but I doubt there's a way to make that work
without a lot of new infrastructure. For
Jeff Janes jeff.ja...@gmail.com writes:
Is there an easy way to get a list of held lwlocks out of gdb attached to a
core dump (or for that matter attached to a live process)?
There's the held_lwlocks array in lwlock.c, but that will just give you
pointers. What I imagine you're wishing for is
Magnus Hagander mag...@hagander.net writes:
As far as my research shows, the function
SSL_get_current_compression() which it uses was added in OpenSSL
0.9.6, which is a long time ago (stopped being maintained in 2004).
AFAICT even RHEL *3* shipped with 0.9.7. So I think we can safely rely
on
On Tue, Jul 15, 2014 at 4:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
As far as my research shows, the function
SSL_get_current_compression() which it uses was added in OpenSSL
0.9.6, which is a long time ago (stopped being maintained in 2004).
AFAICT
Magnus Hagander wrote:
On Mon, Aug 5, 2013 at 10:03 PM, Noah Misch noah(at)leadboat(dot)com
wrote:
On Thu, Aug 01, 2013 at 01:04:42PM -0400, Andrew Dunstan wrote:
On 08/01/2013 12:15 PM, Noah Misch wrote:
1. Include in the base backup a file listing symbolic links/junction
points,
then have
Magnus Hagander mag...@hagander.net writes:
Out of curiosity, since one of those boxes seems to be yours, which
version of OpenSSL does it actually have?
Claims to be 0.9.7:
cube:~ tgl$ ls -l /usr/lib/*ssl*
-rwxr-xr-x 1 root wheel 266940 Nov 7 2010 /usr/lib/libssl.0.9.7.dylib*
-rwxr-xr-x
I have just noticed that I inadvertently marked the json_build*
functions as immutable. That seems to be a plain error, as, for example,
timestamptz output will not be immutable. I think we need to fix this
for 9.4. It will mean a catalog bump :-(
cheers
andrew
--
Sent via pgsql-hackers
Andrew Dunstan and...@dunslane.net writes:
I have just noticed that I inadvertently marked the json_build*
functions as immutable. That seems to be a plain error, as, for example,
timestamptz output will not be immutable.
Ah, yes, our convention is that anything depending on datatype I/O
On Tue, Jul 15, 2014 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Out of curiosity, since one of those boxes seems to be yours, which
version of OpenSSL does it actually have?
Claims to be 0.9.7:
cube:~ tgl$ ls -l /usr/lib/*ssl*
-rwxr-xr-x 1
From: Magnus Hagander mag...@hagander.net
Well, it does in a couple of places. I'm nto sure it's that important
(as nobody has AFAIK ever requested that change from for example EDB),
but it's not a bad thing. However, with a hardcoded service name, I
think the changes to pg_event.c are probably
On 07/15/2014 11:14 AM, Tom Lane wrote:
I think we need to fix this
for 9.4. It will mean a catalog bump :-(
Agreed.
Are we trying to store these up or just applying them as they go?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
We've observed a 9.0 database have undetected deadlocks repeatedly in
hot standby mode.
I think what's happening is that autovacuum is kicking off a VACUUM of
some system catalogs -- it seems to usually be pg_statistics' toast
table actually. At the end of the vacuum it briefly gets the exclusive
Magnus Hagander mag...@hagander.net writes:
Being a completely newbie when it comes to writing configure checks -
does this seem correct?
Looks reasonable to me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Andrew Dunstan and...@dunslane.net writes:
Are we trying to store these up or just applying them as they go?
No, just do it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Jul 15, 2014 at 6:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Being a completely newbie when it comes to writing configure checks -
does this seem correct?
Looks reasonable to me.
Thanks, I've applied it - let's hope the buildfarm is happier
It's hard to argue that the current behaviour is wrong, but it's worth a try.
First I'd appreciate the official reasons why Postgres prefers to
keep interval values in non-canonical form, like '1 day -23:37:00'
instead of '00:23:00'. I understand it has something to do with a
year/month/day not
On Tue, Jul 15, 2014 at 7:38 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jul 10, 2014 at 11:10 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
Hi,
At 1047 line of receivelog.c:CopyStreamPoll(), we set NULL to
timeoutptr variable.
if the value of timeoutprt is set NULL then the
Gurjeet Singh gurj...@singh.im writes:
The interval arithmetic operations may also yield non-canonical
values, and IMHO the 'interval op interval' or 'interval op scalar'
expressions should yield an interval in canonical form.
You're mistaken.
postgres=# select '6 days 00:16:00'::interval -
Hi Fabrízio,
thanks for the speedy new version.
Re: Fabrízio de Royes Mello 2014-07-15
cafcns+opbuhjuo1soathv8zqcowqp-yerjfoo15v1xpxspc...@mail.gmail.com
+
+ if (pass == AT_PASS_SET_LOGGED_UNLOGGED)
+
ATPostAlterSetLoggedUnlogged(RelationGetRelid(rel));
Simon Riggs si...@2ndquadrant.com writes:
Reset master xmin when hot_standby_feedback disabled.
If walsender has xmin of standby then ensure we
reset the value to 0 when we change from hot_standby_feedback=on
to hot_standby_feedback=off.
Branch
--
REL9_2_STABLE
While I'm not
On Tue, Jul 15, 2014 at 3:04 PM, Christoph Berg c...@df7cb.de wrote:
Hi Fabrízio,
thanks for the speedy new version.
You're welcome... If all happen ok I would like to have this patch commited
before the GSoC2014 ends.
I've just tried some SET (UN)LOGGED operations with altering column
2014-07-15 12:07 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
On Tue, Jul 15, 2014 at 7:01 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2014-07-15 11:29 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
On 15 July 2014 19:15, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Reset master xmin when hot_standby_feedback disabled.
If walsender has xmin of standby then ensure we
reset the value to 0 when we change from hot_standby_feedback=on
to
David Rowley dgrowle...@gmail.com writes:
I've made some changes to the patch so that it only allows the conversion
to ANTI JOIN to take place if both the outer query's expressions AND the
subquery's target list can be proved not to have NULLs.
This coding doesn't fill me with warm fuzzy
On 15 July 2014 19:15, Tom Lane t...@sss.pgh.pa.us wrote:
Where was the discussion of
why this change should be back-patched?
Your question has broader implications. Currently commit messages do
not reference the conversations that led to them and a great many use
entirely different
On 15 July 2014 12:58, David Rowley dgrowle...@gmail.com wrote:
I found that the call to is_NOTANY_compatible_with_antijoin adds about 0.2%
and 2.3% to total planning time. Though the 2.3% was quite an extreme case,
and the 0.2% was the most simple case I could think of.
I think its quite
Simon Riggs si...@2ndquadrant.com writes:
On 15 July 2014 19:15, Tom Lane t...@sss.pgh.pa.us wrote:
While I'm not necessarily objecting to the content of this patch,
I do have a problem with the process. Where was the discussion of
why this change should be back-patched?
There was recent
Simon Riggs si...@2ndquadrant.com writes:
On 15 July 2014 12:58, David Rowley dgrowle...@gmail.com wrote:
I found that the call to is_NOTANY_compatible_with_antijoin adds about 0.2%
and 2.3% to total planning time. Though the 2.3% was quite an extreme case,
and the 0.2% was the most simple
On 15 July 2014 22:01, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 15 July 2014 19:15, Tom Lane t...@sss.pgh.pa.us wrote:
While I'm not necessarily objecting to the content of this patch,
I do have a problem with the process. Where was the discussion of
On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Dunno. Was hoping someone else had an idea. It'd certainly be nice
to have some way of calling functions like this without specifying the
shape of the return value, but I doubt
Simon Riggs si...@2ndquadrant.com writes:
On 15 July 2014 22:01, Tom Lane t...@sss.pgh.pa.us wrote:
I searched the archives looking for that discussion and couldn't find it;
can you provide a link?
http://www.postgresql.org/message-id/e1u2jod-0005w4...@gemulon.postgresql.org
Ah. I hadn't
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think you're confusing these functions with the kind that specify
their own output rowtype --- which we *can* handle, via a list of OUT
parameters. In these cases, the entire point
The PG core team has agreed that it's about time to push out new minor
releases, since work has finished on repairing the known issues around
9.3's multixact code. We have scheduled this for next week (ie, wrap this
coming Monday, July 21, for announcement Thursday 7/24).
We will push 9.4beta2
On Tue, Jul 15, 2014 at 5:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think you're confusing these functions with the kind that specify
their own output rowtype --- which we *can*
David Rowley dgrowle...@gmail.com writes:
I've attached an updated patch which puts in some fast path code for
subquery type joins. I'm really not too sure on a good name for this
function. I've ended up with query_supports_distinctness() which I'm not
that keen on, but I didn't manage to come
Kaigai-san,
2014-07-15 21:37 GMT+09:00 Kouhei Kaigai kai...@ak.jp.nec.com:
Sorry, expected result of sanity-check test was not updated on
renaming to pg_custom_plan_provider.
The attached patch fixed up this point.
I confirmed that all regression tests passed, so I marked the patch as
Ready
On Mon, Jul 14, 2014 at 12:19 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-07-14 11:24:26 -0400, Robert Haas wrote:
On Sun, Jul 13, 2014 at 2:23 PM, Andres Freund and...@2ndquadrant.com
wrote:
The actual if (lock != NULL) bit costs significant amounts of cycles?
I'd have assumed
On Tue, Jul 15, 2014 at 04:54:05PM +0100, Greg Stark wrote:
We've observed a 9.0 database have undetected deadlocks repeatedly in
hot standby mode.
I think what's happening is that autovacuum is kicking off a VACUUM of
some system catalogs -- it seems to usually be pg_statistics' toast
Dilip kumar dilip.ku...@huawei.com writes:
On 15 July 2014 19:01, Magnus Hagander Wrote,
I am late to this game, but the first thing to my mind was - do we
really need the whole forking/threading thing on the client at all?
Thanks for the review, I understand you point, but I think if we have
On Wed, Jul 2, 2014 at 11:11 AM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
On Wed, Jun 25, 2014 at 10:39 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I came up with the attached. There were several bugs:
I tested for the original bug report and patch definitely fixes that.
On Tue, Jul 15, 2014 at 8:57 PM, MauMau maumau...@gmail.com wrote:
From: Magnus Hagander mag...@hagander.net
Well, it does in a couple of places. I'm nto sure it's that important
(as nobody has AFAIK ever requested that change from for example EDB),
but it's not a bad thing.
I think this is
I'm not saying there is no multixact bug here, but I wonder if this part
of your crasher patch might be the cause:
--- 754,771
errmsg(could not seek to block %u in file
\%s\: %m,
blocknum,
Hello Robert,
Well, I think the feedback has been pretty clear, honestly. Here's
what I'm unhappy about: I can't understand what these options are
actually doing.
We can try to improve the documentation, once more!
However, ISTM that it is not the purpose of pgbench documentation to be a
Simon Riggs wrote:
On 15 July 2014 19:15, Tom Lane t...@sss.pgh.pa.us wrote:
Where was the discussion of
why this change should be back-patched?
Your question has broader implications. Currently commit messages do
not reference the conversations that led to them and a great many use
On Tue, Jul 15, 2014 at 9:58 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I try to mention message-ids in commit messages. Are these useful?
In my view, yes, certainly.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane wrote:
Dilip kumar dilip.ku...@huawei.com writes:
On 15 July 2014 19:01, Magnus Hagander Wrote,
I am late to this game, but the first thing to my mind was - do we
really need the whole forking/threading thing on the client at all?
Thanks for the review, I understand you point,
Currently \pset is supported without any argument also, so same is updated in
documentation.
\pset option [ value ]
Changed to
\pset [ option [ value ] ]
Thanks Regards,
Dilip Kumar
psql_doc.patch
Description: psql_doc.patch
--
Sent via pgsql-hackers mailing list
On Wed, Jul 16, 2014 at 1:34 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Heikki, did you get chance to commit your patch? IMHO we should get the bug
fix in before minor releases next week. My apologies if you've already
committed it and I've missed the commit message.
FWIW, this patch
64 matches
Mail list logo
