On 2015/08/26 13:49, Kouhei Kaigai wrote:
On 2015/08/25 10:18, Kouhei Kaigai wrote:
Likely, what you need to do are...
1. Save the alternative path on fdw_paths when foreign join push-down.
GetForeignJoinPaths() may be called multiple times towards a particular
joinrel according to the
On Tue, Aug 25, 2015 at 11:02 PM, Peter Eisentraut wrote:
> On 6/19/15 10:52 AM, Robert Haas wrote:
>> Change TAP test framework to not rely on having a chmod executable.
>>
>> This might not work at all on Windows, and is not ever efficient.
>>
>> Michael Paquier
>
> I came across this on an unre
On Wed, Aug 26, 2015 at 10:30 AM, Andreas Karlsson wrote:
> On 08/25/2015 09:39 AM, Michael Paquier wrote:
>>
>> -- Reload SSL certificates on SIGHUP: returned with feedback? I think
>> that this patch needs more work to be in a commitable state.
>
>
> Maybe I am being dense here, but I do not fee
On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier
wrote:
> On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote:
>> [...]
>> So I think the way to move this forward is to investigate how to hold
>> the SSL config constant until SIGHUP in an EXEC_BACKEND build. If we
>> find out that that's unreasona
> On 2015/08/25 10:18, Kouhei Kaigai wrote:
> > How about your opinion towards the solution?
>
> >> Likely, what you need to do are...
> >> 1. Save the alternative path on fdw_paths when foreign join push-down.
> >> GetForeignJoinPaths() may be called multiple times towards a particular
> >>
Hi KaiGai-san,
On 2015/08/25 10:18, Kouhei Kaigai wrote:
How about your opinion towards the solution?
Likely, what you need to do are...
1. Save the alternative path on fdw_paths when foreign join push-down.
GetForeignJoinPaths() may be called multiple times towards a particular
joinr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/24/2015 08:52 AM, Joe Conway wrote:
> On 08/24/2015 06:50 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 08/23/2015 08:58 PM, Michael Paquier wrote:
I think that's a good thing to have, now I have concerns
about making this data
On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote:
> [...]
> So I think the way to move this forward is to investigate how to hold
> the SSL config constant until SIGHUP in an EXEC_BACKEND build. If we
> find out that that's unreasonably difficult, maybe we'll decide that
> we can live without it;
On Wed, Aug 26, 2015 at 2:21 AM, Tom Lane wrote:
>
> Amit Kapila writes:
>
> > I am wondering that is there any harm in calling TransactionIdDidAbort()
> > in slow path before calling SubTransGetTopmostTransaction(), that can
> > also maintain consistency of checks in both the functions?
>
> I th
On August 25, 2015 08:36:52 PM Tom Lane wrote:
> Jan de Visser writes:
> > On August 25, 2015 09:31:35 PM Michael Paquier wrote:
> >> This patch had feedback, but there has been no update in the last
> >> month, so I am now marking it as returned with feedback.
> >
> > It was suggested that this
[ moving this discussion back to the patch thread ]
Andreas Karlsson writes:
> On 08/25/2015 09:39 AM, Michael Paquier wrote:
>> -- Reload SSL certificates on SIGHUP: returned with feedback? I think
>> that this patch needs more work to be in a commitable state.
> Maybe I am being dense here, bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 06:03 PM, Joe Conway wrote:
> I'm arriving late to this party, so maybe everyone else already
> knows this, but apparently sepgsql is not compatible with the
> version of selinux available on RHEL 6.x. So there doesn't seem to
> be much r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 12:41 PM, Alvaro Herrera wrote:
> Joe Conway wrote:
>> On 08/25/2015 11:28 AM, Alvaro Herrera wrote:
>>> Joe Conway wrote:
>>>
Does anyone out there object to a non-backward compatible
change to pg_controldata output?
>>>
>>>
On 08/25/2015 09:39 AM, Michael Paquier wrote:
-- Reload SSL certificates on SIGHUP: returned with feedback? I think
that this patch needs more work to be in a commitable state.
Maybe I am being dense here, but I do not feel like I have gotten any
clear feedback which gives me a way forward wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 02:27 PM, Joe Conway wrote:
> On 08/25/2015 01:02 PM, Stephen Frost wrote:
>> * Adam Brightwell (adam.brightw...@crunchydatasolutions.com)
>> wrote:
So what about the buildfarm animal that was offered for
this? We still have th
> On 2015-08-25 14:42:32 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > Since we already have CustomScan->methods, it seems to be rather
> > > reasonable to have a CopyCustomScan callback and let it do the copying
> > > of the private data if present? Or possibly of the whole node, which'd
Jan de Visser writes:
> On August 25, 2015 09:31:35 PM Michael Paquier wrote:
>> This patch had feedback, but there has been no update in the last
>> month, so I am now marking it as returned with feedback.
> It was suggested that this mechanism became superfluous with the inclusion of
> the vie
On August 25, 2015 09:31:35 PM Michael Paquier wrote:
> On Thu, Jul 23, 2015 at 5:06 PM, Heikki Linnakangas wrote:
> > Other comments:
> > [...]
>
> This patch had feedback, but there has been no update in the last
> month, so I am now marking it as returned with feedback.
It was suggested that t
On Tue, Aug 25, 2015 at 6:21 PM, Jim Nasby wrote:
> This works:
>
> CREATE TYPE c AS (r float, i float);
> CREATE FUNCTION mag(c c) RETURNS float LANGUAGE sql AS $$
> SELECT sqrt(c.r^2 + c.i^2)
> $$;
> SELECT mag( (2.2, 2.2) );
>mag
> --
> 3.11126983722081
>
> But this do
Jim Nasby writes:
> This works:
> CREATE TYPE c AS (r float, i float);
> CREATE FUNCTION mag(c c) RETURNS float LANGUAGE sql AS $$
> SELECT sqrt(c.r^2 + c.i^2)
> $$;
> SELECT mag( (2.2, 2.2) );
> mag
> --
> 3.11126983722081
> But this doesn't:
> CREATE FUNCTION magsum( c
Andres Freund writes:
> On 2015-08-25 14:42:32 -0400, Tom Lane wrote:
>> In any case, since this convention already exists for FDWs I'm not
>> sure why we should make it different for CustomScan.
> I think it was a noticeable mistake in the fdw case, but we already
> released with that. We should
On Tue, Aug 25, 2015 at 11:28 PM, Stephen Frost wrote:
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> -- Default Roles: Stephen, are you planning to work on that for next CF?
>
> Yup!
OK. Fine for me. I have moved the patch to next CF, even if I
mentioned having marked it
>
> You mean "even if relacl is not null"? Sounds improbable: AFAIR, pg_class
> tuples are built with heap_form_tuple, same as anything else.
>
> regards, tom lane
I am sorry. It was a bug in my code. I did not add the size of the tuple's
header field to the off variable
On 2015-08-25 14:42:32 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Since we already have CustomScan->methods, it seems to be rather
> > reasonable to have a CopyCustomScan callback and let it do the copying
> > of the private data if present? Or possibly of the whole node, which'd
> > allow
Vignesh Raghunathan writes:
> On Tue, Aug 25, 2015 at 2:56 PM, Tom Lane wrote:
>> If t_len were *less* than that, it would be a bug. But I think it's
>> fairly common for t_len to be rounded up to the next maxalign boundary.
> I have modified heap_deform_tuple code to check whether the 'off' va
On Tue, Aug 25, 2015 at 2:56 PM, Tom Lane wrote:
> Vignesh Raghunathan writes:
> > Can the t_len field in HeapTuple structure be used to verify the length
> of
> > the tuple?
>
> > That is, if I calculate the length from the contents of the tuple using
> > data from pg_attribute for fixed length
This works:
CREATE TYPE c AS (r float, i float);
CREATE FUNCTION mag(c c) RETURNS float LANGUAGE sql AS $$
SELECT sqrt(c.r^2 + c.i^2)
$$;
SELECT mag( (2.2, 2.2) );
mag
--
3.11126983722081
But this doesn't:
CREATE FUNCTION magsum( c c[] ) RETURNS float LANGUAGE sql AS $$
S
Alvaro Herrera writes:
> Tom Lane wrote:
>> Well, strictly speaking, there were no uses of pg_read_barrier until 9.4.
>> However, pg_write_barrier (which used "wmb") was in use since 9.2; so
>> unless you're claiming your assembler knows wmb but not rmb, the code's
>> failed to compile for Alpha s
Vignesh Raghunathan writes:
> Can the t_len field in HeapTuple structure be used to verify the length of
> the tuple?
> That is, if I calculate the length from the contents of the tuple using
> data from pg_attribute for fixed length fields and the data from the header
> for varlena fields, shoul
Tom Lane wrote:
> Alvaro Herrera writes:
> > Aaron W. Swenson wrote:
> >> In the 4 years that that particular line has been there, not once had
> >> anyone else run into it on Gentoo until a couple months ago.
> >> And it isn't a case of end users missing it as we have arch testers
> >> that test
On 2015-08-25 15:43:12 -0400, Aaron W. Swenson wrote:
> As for the dropped support, has the Alpha specific code been ripped
> out? Would it still presumably run on Alpha?
I'm pretty sure that postgres hasn't run correctly under concurrency on
alpha for a long while. The lax cache coherency makes d
Hello,
Can the t_len field in HeapTuple structure be used to verify the length of
the tuple?
That is, if I calculate the length from the contents of the tuple using
data from pg_attribute for fixed length fields and the data from the header
for varlena fields, should it always match the value sto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 01:02 PM, Stephen Frost wrote:
> * Adam Brightwell (adam.brightw...@crunchydatasolutions.com)
> wrote:
>>> So what about the buildfarm animal that was offered for this?
>>> We still have this module completely uncovered in the buildfarm
>
Alvaro Herrera writes:
> Aaron W. Swenson wrote:
>> In the 4 years that that particular line has been there, not once had
>> anyone else run into it on Gentoo until a couple months ago.
>> And it isn't a case of end users missing it as we have arch testers
>> that test packages before marking them
Tom Lane wrote:
> Amit Kapila writes:
> > I am wondering that is there any harm in calling TransactionIdDidAbort()
> > in slow path before calling SubTransGetTopmostTransaction(), that can
> > also maintain consistency of checks in both the functions?
>
> I think this is probably a bad idea. It
Amit Kapila writes:
> On Fri, Aug 21, 2015 at 8:22 PM, Robert Haas wrote:
>> On Wed, Aug 19, 2015 at 2:53 AM, Amit Kapila
>>> Another minor point is, I think we should modify function level comment
>>> for XidInMVCCSnapshot() where it says that this applies to known-
>>> committed XIDs which wil
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> > So what about the buildfarm animal that was offered for this? We still
> > have this module completely uncovered in the buildfarm ...
>
> I believe that is in the works and should be made available soon.
Right, Joe commented
> So what about the buildfarm animal that was offered for this? We still
> have this module completely uncovered in the buildfarm ...
I believe that is in the works and should be made available soon.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.cr
So what about the buildfarm animal that was offered for this? We still
have this module completely uncovered in the buildfarm ...
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailin
Aaron W. Swenson wrote:
> I've been meaning to report this myself.
>
> In the 4 years that that particular line has been there, not once had
> anyone else run into it on Gentoo until a couple months ago.
>
> And it isn't a case of end users missing it as we have arch testers
> that test packages
All,
> The second approach above works.
> I defined a own privileged domain (sepgsql_regtest_superuser_t)
> instead of system's unconfined_t domain.
> The reason why regression test gets failed was, definition of
> unconfined_t in the system default policy was changed to bypass
> multi-category ru
On 2015-08-25 08:57, Andrew Dunstan wrote:
> On 08/25/2015 08:30 AM, Andres Freund wrote:
> > On 2015-08-25 08:29:18 -0400, Andrew Dunstan wrote:
> >> needs a buildfarm animal. If we had one we'd presumably have caught this
> >> much earlier.
> > On the other hand, we dropped alpha support in 9.5,
Joe Conway wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
I should have gotten my key signed when I had the chance :-(
> On 08/25/2015 11:28 AM, Alvaro Herrera wrote:
> > Joe Conway wrote:
> >
> >> Does anyone out there object to a non-backward compatible change
> >> to pg_controldata
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 11:28 AM, Alvaro Herrera wrote:
> Joe Conway wrote:
>
>> Does anyone out there object to a non-backward compatible change
>> to pg_controldata output?
>
> I don't (and thanks for taking care of it), but as I recall,
> pg_upgrade reads a
Andres Freund writes:
> On 2015-08-25 14:33:25 -0400, Tom Lane wrote:
>> (IOW, yeah, certainly third-party code could create a new *instance* of
>> the ResourceOwner data structure, but they would not have any knowledge of
>> what's inside unless they had hacked the core code.)
> What I was think
Andres Freund writes:
> Since we already have CustomScan->methods, it seems to be rather
> reasonable to have a CopyCustomScan callback and let it do the copying
> of the private data if present? Or possibly of the whole node, which'd
> allow to embed it into a bigger node?
Weren't there rumbling
On 2015-08-25 14:33:25 -0400, Tom Lane wrote:
> (IOW, yeah, certainly third-party code could create a new *instance* of
> the ResourceOwner data structure, but they would not have any knowledge of
> what's inside unless they had hacked the core code.)
What I was thinking is that somebody created a
Andres Freund writes:
> On 2015-08-25 14:12:37 -0400, Tom Lane wrote:
>> How would they have done that without major code surgery? We don't have
>> any hooks or function pointers involved in the users of resowner.h.
>> Certainly locks would not be getting passed to a nonstandard resowner.
> Curr
Joe Conway wrote:
> Does anyone out there object to a non-backward compatible change to
> pg_controldata output?
I don't (and thanks for taking care of it), but as I recall, pg_upgrade
reads and interprets pg_controldata output so it may need adjustment
too.
--
Álvaro Herrerahtt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 10:32 AM, Joe Conway wrote:
> On 08/25/2015 10:28 AM, Tom Lane wrote:
>> I was suggesting getting rid of "Current" in *all* the entries.
>> What value does it add?
>
> I agree, it adds no value, and is a simple solution.
>
> Does anyon
On 2015-08-25 14:12:37 -0400, Tom Lane wrote:
> How would they have done that without major code surgery? We don't have
> any hooks or function pointers involved in the users of resowner.h.
> Certainly locks would not be getting passed to a nonstandard resowner.
CurrentResourceOwner = myresowner;
(sending again, forgot to cc hackers, sorry for the duplicate)
Hi,
I'm trying to use the custom scan API to replace code that currently
does everything via hooks and isn't safe against copyObject() (Yes,
that's not a grand plan).
To me dealing with CustomScan->custom_private seems to be
extraord
Andres Freund writes:
> On 2015-08-25 13:54:20 -0400, Tom Lane wrote:
>> However, I'm not entirely following Andres' concern here. AFAICS,
>> the only externally visible API change in commit eeb6f37d8 was that
>> LockReleaseCurrentOwner and LockReassignCurrentOwner gained some
>> arguments. That
On 2015-08-25 13:54:20 -0400, Tom Lane wrote:
> Jeff Janes writes:
> > Once the code has to be rewritten, my argument that it has been working "in
> > the field" for a while doesn't really apply anymore.
If rewriting involves adding two one line wrapper functions, I don't see
the problem.
> Howe
Alvaro Herrera writes:
> Tom Lane wrote:
>> So the wording would have to be "there is no label "foo" attached to
>> any block or loop enclosing this statement". That's a tad verbose,
>> but at least it's clear ...
> This seems good to me, verbosity notwithstanding.
Hearing no objections, I'll g
Jeff Janes writes:
> On Tue, Aug 25, 2015 at 5:48 AM, Michael Paquier
>> On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund wrote:
>>> That's the safest way. Sometimes you can decide that a function can not
>>> sanely be called by external code and thus change the signature. But I'd
>>> rather not r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 10:28 AM, Tom Lane wrote:
> Joe Conway writes:
>> On 08/24/2015 07:41 PM, Tom Lane wrote:
>>> Seems to me we could s/Current //g, or s/ setting//g, or both,
>>> and get rid of the problem without adding more whitespace.
>
>> I'd agree,
Joe Conway writes:
> On 08/24/2015 07:41 PM, Tom Lane wrote:
>> Seems to me we could s/Current //g, or s/ setting//g, or both, and
>> get rid of the problem without adding more whitespace.
> I'd agree, except I think not everyone might be happy with that. The
> surrounding lines look like:
I was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/24/2015 07:41 PM, Tom Lane wrote:
> Joe Conway writes:
>> Do we care that as of 9.5 pg_controldata output is not 100%
>> aligned anymore? The culprit is: Current track_commit_timestamp
>> setting: off Its value is shifted 2 characters to the rig
On 08/24/2015 11:26 AM, Tom Lane wrote:
> "Paragon Corporation" writes:
>> Just checking to see if you guys have settled on a date for 9.5.0 release.
>
> No. Considering we don't have a beta out yet, it's not imminent ...
This is the timeline, effectively:
https://wiki.postgresql.org/wiki/Post
On Fri, Jul 10, 2015 at 11:29 AM, Tomas Vondra wrote:
> Hi,
>
> currently partial indexes end up not using index only scans in most cases,
> because check_index_only() is overly conservative, as explained in this
> comment:
>
> * XXX this is overly conservative for partial indexes, since we will
Tom Lane wrote:
> So the wording would have to be "there is no label "foo" attached to
> any block or loop enclosing this statement". That's a tad verbose,
> but at least it's clear ...
This seems good to me, verbosity notwithstanding.
--
Álvaro Herrerahttp://www.2ndQuadrant.co
Jim Nasby writes:
> On 8/25/15 10:56 AM, Tom Lane wrote:
>> I'm good with this as long as all the things that get stored in pg_am
>> are things that pg_class.relam can legitimately reference. If somebody
>> proposed adding an "access method" kind that was not a relation access
>> method, I'd prob
Jim Nasby wrote:
> On 8/25/15 10:56 AM, Tom Lane wrote:
> >I'm good with this as long as all the things that get stored in pg_am
> >are things that pg_class.relam can legitimately reference. If somebody
> >proposed adding an "access method" kind that was not a relation access
> >method, I'd probab
I wrote:
> Hmm ... what do you think of wording the error as "there is no label "foo"
> attached to any block enclosing this statement"? That still leaves the
> terminology "block" undefined, but it seems better than "any statement
> enclosing this statement".
Actually, looking at the plpgsql doc
On 8/25/15 10:56 AM, Tom Lane wrote:
I'm good with this as long as all the things that get stored in pg_am
are things that pg_class.relam can legitimately reference. If somebody
proposed adding an "access method" kind that was not a relation access
method, I'd probably push back on whether that
Jim Nasby writes:
> On 8/22/15 2:53 PM, Tom Lane wrote:
>> ... Given the way the namespace data
>> structure works, I am not sure that we can realistically detect at line 8
>> that there was an instance of lab1 earlier, but perhaps we could word the
> Are there any other reasons we'd want to impr
On 8/25/15 10:50 AM, Jim Nasby wrote:
figuring out the cause of his problem. Given the way the namespace data
structure works, I am not sure that we can realistically detect at line 8
that there was an instance of lab1 earlier, but perhaps we could word the
Are there any other reasons we'd wan
On 08/25/2015 10:39 AM, Michael Paquier wrote:
On Mon, Aug 10, 2015 at 4:34 PM, Heikki Linnakangas wrote:
Hello Hackers,
There are a few "Needs Review" items remaining in the July commitfest.
Reviewers, please take action - you are holding up the commitfest.
In addition to these items, there
Alvaro Herrera writes:
> Jim Nasby wrote:
>> On 8/24/15 9:49 AM, Alexander Korotkov wrote:
>>> 3) Non-index access methods reuse both pg_class.relam and pg_am. This
>>> violates relational theory because we store different objects in the
>>> same table.
> In my reading of the thread, we have a co
On Tue, Aug 25, 2015 at 5:48 AM, Michael Paquier
wrote:
> On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund wrote:
> > On July 9, 2015 9:13:20 PM GMT+02:00, Jeff Janes
> wrote:
> >
> >>Unfortunately I don't know what that means about the API. Does it mean
> >>that none of the functions declared i
On 8/22/15 2:53 PM, Tom Lane wrote:
This message seems confusing: label "lab1" does exist, it's just not
attached to the right loop. In a larger function that might not be too
obvious, and I can easily imagine somebody wasting some time before
Agreed.
figuring out the cause of his problem.
Jim Nasby wrote:
> On 8/24/15 9:49 AM, Alexander Korotkov wrote:
> >2) Non-index access methods reuse pg_class.relam but don't reuse pg_am.
> >This violates relational theory because single column reference multiple
> >tables.
> >3) Non-index access methods reuse both pg_class.relam and pg_am. This
On 8/24/15 9:49 AM, Alexander Korotkov wrote:
2) Non-index access methods reuse pg_class.relam but don't reuse pg_am.
This violates relational theory because single column reference multiple
tables.
3) Non-index access methods reuse both pg_class.relam and pg_am. This
violates relational theory b
Jim Nasby writes:
> What I've had problems with is trying to correlate psql specified
> connection attributes with things like DBI. It would be nice if there
> was a way to get a fully formed connection URI for the current connection.
Yeah, although I'd think the capability to create such a URI
Zhaomo,
* Zhaomo Yang (zmp...@gmail.com) wrote:
> > If no NEW or OLD is used, what happens? Or would you have
> > to always specify OLD/NEW for UPDATE, and then what about for the other
> > policies, and the FOR ALL policies?
>
> I should be clearer with references to OLD/NEW. SELECT Predicates
On 8/24/15 3:04 PM, Pavel Stehule wrote:
(1) there is no reason to believe that the db name and only the db name
is needed to do another connection; what about port, host, user, etc?
I have to agree - the possibilities is much more than database name - so
one option is not good idea.
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> -- Default Roles: Stephen, are you planning to work on that for next CF?
Yup!
Thanks!
Stephen
signature.asc
Description: Digital signature
On Tue, Aug 25, 2015 at 4:39 AM, Michael Paquier
wrote:
>
> [...]
>
> -- Support to COMMENT ON CURRENT DATABASE: returned with feedback? The
> author mentioned that patch will be reworked but there has been no new
> version around it seems.
>
Moved to the next commitfest.
Regards,
--
Fabrízio d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/25/2015 12:39 AM, Michael Paquier wrote:
> -- self-defined policy for sepgsql regression test, returned with
> feedback? The regressions are broken as mentioned at the end of
> the thread.
I am in the process of getting a VM setup with an appro
On 6/19/15 10:52 AM, Robert Haas wrote:
> Change TAP test framework to not rely on having a chmod executable.
>
> This might not work at all on Windows, and is not ever efficient.
>
> Michael Paquier
I came across this on an unrelated mission and noticed it was
unnecessarily complicated. How ab
Hi,
On 08/25/2015 02:44 PM, Michael Paquier wrote:
On Tue, Aug 25, 2015 at 6:05 PM, Fabien COELHO wrote:
-- merging pgbench logs: returned with feedback or bump? Fabien has
concerns about performance regarding fprintf when merging the logs.
Fabien, Tomas, thoughts?
-- pgbench - per-transacti
On Sat, Jul 11, 2015 at 6:06 AM, Heikki Linnakangas wrote:
> On 05/08/2015 07:35 AM, Stephen Frost wrote:
>> In consideration of the fact that you can't create schemas which start
>> with "pg_" and therefore the default search_path wouldn't work for that
>> user, and that we also reserve "pg_" for
On Thu, Jul 23, 2015 at 6:18 PM, Teodor Sigaev wrote:
>>> Poorly, by hanging boxes that straddled dividing lines off the parent
>>> node in a big linear list. The hope would be that the case was
>>
>> Ok, I see, but that's not really what I was wondering. My question is
>> this:
>> SP-GiST partiti
On Sun, Jul 26, 2015 at 9:46 PM, Andres Freund wrote:
> On 2015-07-24 09:53:49 +0300, Heikki Linnakangas wrote:
> To me it sounds like this shouldn't go through the full ReadBuffer()
> rigamarole. That code is already complex enough, and here it's really
> not needed. I think it'll be much easier t
On Thu, Apr 30, 2015 at 2:04 AM, Alvaro Herrera
wrote:
> Fabrízio de Royes Mello wrote:
>
>> I have this idea:
>>
>> 1) Add an ObjectAddress field to CommentStmt struct an set it in gram.y
>>
>> 2) In the CommentObject check if CommentStmt->address is
>> InvalidObjectAddress then call get_object_a
On 08/25/2015 08:30 AM, Andres Freund wrote:
On 2015-08-25 08:29:18 -0400, Andrew Dunstan wrote:
needs a buildfarm animal. If we had one we'd presumably have caught this
much earlier.
On the other hand, we dropped alpha support in 9.5, ...
Oh, I missed that. Sorry for the noise.
cheers
On Mon, Jul 6, 2015 at 12:30 PM, Amit Kapila wrote:
> Yes, we definitely want to see the effect on TPS at the beginning of
> checkpoint,
> but even measuring the IO during checkpoint with the way Digoal was
> capturing
> the data can show the effect of this patch.
I am marking this patch as return
On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund wrote:
> On July 9, 2015 9:13:20 PM GMT+02:00, Jeff Janes wrote:
>
>>Unfortunately I don't know what that means about the API. Does it mean
>>that none of the functions declared in any .h file can have their
>>signatures changed? But new functions
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 the noise. So yes, random() must be
>> used instead of pg_lrand48().
>>
>> I'm attac
On Tue, Aug 25, 2015 at 6:05 PM, Fabien COELHO wrote:
>
>> -- merging pgbench logs: returned with feedback or bump? Fabien has
>> concerns about performance regarding fprintf when merging the logs.
>> Fabien, Tomas, thoughts?
>> -- pgbench - per-transaction and aggregated logs: returned with
>> fe
On Fri, Jul 31, 2015 at 6:28 AM, Tomas Vondra
wrote:
> [series of arguments]
>
> If you need stats without these "issues" you'll have to use MCV list or a
> histogram. Trying to fix the simple statistics types is futile, IMHO.
Patch is marked as returned with feedback. There has been advanced
dis
On Thu, Aug 6, 2015 at 4:02 PM, Mikko Tiihonen wrote:
> Because the feature as its simplest is a for loop in libpq. I would not think
> it much of a feature creep, especially since my original patch to libpq
> showed the loop already has been hidden in libpq for a long time, it just
> needed a s
On Thu, Jul 23, 2015 at 5:06 PM, Heikki Linnakangas wrote:
> Other comments:
> [...]
This patch had feedback, but there has been no update in the last
month, so I am now marking it as returned with feedback.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On 2015-08-25 08:29:18 -0400, Andrew Dunstan wrote:
> needs a buildfarm animal. If we had one we'd presumably have caught this
> much earlier.
On the other hand, we dropped alpha support in 9.5, ...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
On 08/25/2015 06:16 AM, Christoph Berg wrote:
Hi,
>From the Debian ports buildd:
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=alpha&ver=9.4.4-1&stamp=1434132509
make[5]: Entering directory '/«PKGBUILDDIR»/build/src/backend/postmaster'
[...]
gcc -Wall -Wmissing-prototype
On Tue, Aug 25, 2015 at 5:51 PM, Heikki Linnakangas wrote:
> On 08/25/2015 10:39 AM, Michael Paquier wrote:
>> - 12 patches are waiting on author:
>
> These can all be marked as Returned with good conscience, they've gotten at
> least some feedback.
Fine for me. I'll notify each thread individuall
On Thu, Aug 20, 2015 at 3:49 PM, Andres Freund wrote:
>
> On 2015-08-20 15:38:36 +0530, Amit Kapila wrote:
> > On Wed, Aug 19, 2015 at 9:09 PM, Andres Freund
wrote:
> > > I spent some time today reviewing the commited patch. So far my only
> > > major complaint is that I think the comments are on
Hi,
>From the Debian ports buildd:
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=alpha&ver=9.4.4-1&stamp=1434132509
make[5]: Entering directory '/«PKGBUILDDIR»/build/src/backend/postmaster'
[...]
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-
On 24 August 2015 at 19:15, Paragon Corporation wrote:
> Just checking to see if you guys have settled on a date for 9.5.0 release.
>
> The PostGIS Dev team would like to release PostGIS 2.2 about or a week or
> more before, but not too far ahead of 9.5.0 release.
>
It's a good question, thanks
1 - 100 of 104 matches
Mail list logo
