On Jul 16, 2014 7:05 AM, "Alvaro Herrera" wrote:
>
> Tom Lane wrote:
> > Dilip kumar 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?
> >
On 07/16/2014 08:30 AM, Michael Paquier wrote:
On Wed, Jul 16, 2014 at 1:34 PM, Pavan Deolasee
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 messag
I found and fixed a bug that causes recovery (crash recovery , PITR) to throw
unwanted LOG message if the tablespace symlink is not found during the
processing of DROP TABLESPACE redo.
LOG: could not remove symbolic link
"pg_tblspc/16384": No such file or directo
On Wed, Jul 16, 2014 at 1:34 PM, Pavan Deolasee
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 has not been committed y
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 (pgsql-hackers@postgres
Tom Lane wrote:
> Dilip kumar 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
On Tue, Jul 15, 2014 at 9:58 PM, Alvaro Herrera
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 subscription:
http://www.
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
p
Simon Riggs wrote:
> On 15 July 2014 19:15, Tom Lane 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 di
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,
FilePathName(v->m
On Tue, Jul 15, 2014 at 8:57 PM, MauMau wrote:
>
> From: "Magnus Hagander"
>
>> 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 nothing specific to any ven
On Wed, Jul 2, 2014 at 11:11 AM, Pavan Deolasee
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. I
> don't f
Dilip kumar 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 do this
> direc
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
>
On Mon, Jul 14, 2014 at 12:19 PM, Andres Freund wrote:
> On 2014-07-14 11:24:26 -0400, Robert Haas wrote:
>> On Sun, Jul 13, 2014 at 2:23 PM, Andres Freund
>> wrote:
>> > The actual if (lock != NULL) bit costs significant amounts of cycles?
>> > I'd have assumed that branch prediction takes care
Kaigai-san,
2014-07-15 21:37 GMT+09:00 Kouhei Kaigai :
> 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 for committer".
-
David Rowley 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 up with anything
On Tue, Jul 15, 2014 at 5:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane 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
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 al
Robert Haas writes:
> On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane 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 is that the user has to
>> speci
Simon Riggs writes:
> On 15 July 2014 22:01, Tom Lane 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 searched backwards quite far enough
On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane wrote:
> Robert Haas 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
>> wi
On 15 July 2014 22:01, Tom Lane wrote:
> Simon Riggs writes:
>> On 15 July 2014 19:15, Tom Lane 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?
>
>> The
Simon Riggs writes:
> On 15 July 2014 12:58, David Rowley 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.
> Is there a w
Simon Riggs writes:
> On 15 July 2014 19:15, Tom Lane 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 discussion of it on-list and a pub
On 15 July 2014 12:58, David Rowley 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 important that we don
On 15 July 2014 19:15, Tom Lane 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 descriptions on-list and in
David Rowley 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 feelings.
query_outputs
On 15 July 2014 19:15, Tom Lane wrote:
> Simon Riggs 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
>> --
>> REL
2014-07-15 12:07 GMT+02:00 Fujii Masao :
> On Tue, Jul 15, 2014 at 7:01 PM, Pavel Stehule
> wrote:
> >
> >
> >
> > 2014-07-15 11:29 GMT+02:00 Fujii Masao :
> >
> >> On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule >
> >> wrote:
> >> > Hello
> >> >
> >> > here is a proposed patch - autocomplete for
On Tue, Jul 15, 2014 at 3:04 PM, Christoph Berg 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
> > > t
Simon Riggs 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 necessarily objecting t
Hi Fabrízio,
thanks for the speedy new version.
Re: Fabrízio de Royes Mello 2014-07-15
> > > > > +
> > > > > + if (pass == AT_PASS_SET_LOGGED_UNLOGGED)
> > > > > +
> > > ATPostAlterSetLoggedUnlogged(RelationGetRelid(rel));
> > > >
> > > > This must be done before relation_cl
Gurjeet Singh 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 - '5 days
> 23:
On Tue, Jul 15, 2014 at 7:38 PM, Fujii Masao wrote:
> On Thu, Jul 10, 2014 at 11:10 PM, Sawada Masahiko
> 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 re
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 6:03 PM, Tom Lane wrote:
> Magnus Hagander 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 now.
--
Magnus Hagander
Me
Andrew Dunstan 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:
http://www.postgresql.org/mailpref/p
Magnus Hagander 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 to your subscriptio
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
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 y
From: "Magnus Hagander"
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 both not necessary
On Tue, Jul 15, 2014 at 4:41 PM, Tom Lane wrote:
> Magnus Hagander 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
Andrew Dunstan 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
functions is to be m
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 mai
Magnus Hagander 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 1 root wheel
Magnus Hagander wrote:
>On Mon, Aug 5, 2013 at 10:03 PM, Noah Misch
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 archive reco
On Tue, Jul 15, 2014 at 4:28 PM, Tom Lane wrote:
> Magnus Hagander 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
Magnus Hagander 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 it, especially
Jeff Janes 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 some symbolic displ
Robert Haas 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 example, if a fun
On Tue, Jul 15, 2014 at 4:01 PM, MauMau wrote:
> From: "Magnus Hagander"
>
>> 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, stri
From: "Magnus Hagander"
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 original proposal.
How
On Wed, Jul 2, 2014 at 10:52 PM, Tom Lane 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 allowed to
On Tue, Jul 1, 2014 at 6:25 AM, Dilip kumar 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 the Windows w
On Tue, Jul 15, 2014 at 1:08 AM, Robert Haas wrote:
> On Sat, Jul 12, 2014 at 8:49 AM, Magnus Hagander 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 started getting influenced by envir
On Tue, Jul 15, 2014 at 9:20 PM, Magnus Hagander wrote:
> On Tue, Jul 15, 2014 at 2:14 PM, Michael Paquier
> 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 - the functionality has already been ve
On Tue, Jul 15, 2014 at 2:14 PM, Michael Paquier
wrote:
> On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander wrote:
>> On Thu, Jun 19, 2014 at 4:13 PM, MauMau wrote:
>>> From: "Michael Paquier"
>>>
You are right, I only though about the MS scripts when working on this
patch. Updated pat
On Sat, May 10, 2014 at 4:10 PM, MauMau wrote:
> From: "Amit Kapila"
>
>> 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 look at the latest version of this
On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander wrote:
> On Thu, Jun 19, 2014 at 4:13 PM, MauMau wrote:
>> From: "Michael Paquier"
>>
>>> 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 manual
On Thu, Jun 19, 2014 at 4:13 PM, MauMau wrote:
> From: "Michael Paquier"
>
>> 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 purposes and did not re-run
>> autoconf)
Kaigai-san,
2014-07-14 22:18 GMT+09:00 Kohei KaiGai :
> 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 custom-plan-provider.sgml
On Thu, Jul 10, 2014 at 11:10 PM, Sawada Masahiko 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 following.
>
> if (t
On Tue, Jul 15, 2014 at 7:01 PM, Pavel Stehule wrote:
>
>
>
> 2014-07-15 11:29 GMT+02:00 Fujii Masao :
>
>> On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule
>> wrote:
>> > Hello
>> >
>> > here is a proposed patch - autocomplete for known psql variable content
>>
>> Even after applying the patch, th
2014-07-15 11:29 GMT+02:00 Fujii Masao :
> On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule
> 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
On Thu, Jul 10, 2014 at 9:56 PM, Pavel Stehule 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
HOST
IGNOREEOF
LASTOID
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)
-
67 matches
Mail list logo
