On 19/12/14 20:48, Andres Freund wrote:
On 2014-12-18 10:02:25 -0800, Joshua D. Drake wrote:
I think a lot of hackers forget exactly how tender their egos are. Now I say
this knowing that a lot of them will go, "Oh give me a break" but as someone
who employs hackers, deals with open source AND n
Hello friends,
Thanks for your useful inputs.
We are facing this issue and want to analyse this through logging.
can you please share a sample Postgres config file to enable max logging with
syslog support?
What should be the debug level so that I can capture the failure information?
Regards
On 10/12/14 16:03, Petr Jelinek wrote:
On 10/12/14 04:26, Michael Paquier wrote:
On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
wrote:
Yeah, it was raised. I don't think it was really addressed. There was
lengthy discussion on whether to include LSN, node id, and/or some other
information,
Re: Chris Butler 2014-12-19
<1155204201.65430.1418975376728.javamail.zim...@zedcore.com>
> One of our servers is currently running on postgres 9.2 using the
> 9.2.9-1.pgdg70+1 packages from pgdg.
>
> After an apt update this morning which brought in the libpq5 package version
> 9.4.0-1.pgdg70+1
On Mon, Dec 15, 2014 at 4:18 PM, Dilip kumar wrote:
>
> On December 2014 17:31 Amit Kapila Wrote,
>
>
> >Hmm, theoretically I think new behaviour could lead to more I/O in
>
> >certain cases as compare to existing behaviour. The reason for more I/O
>
> >is that in the new behaviour, while doing A
On 18 December 2014 at 02:48, Simon Riggs wrote:
>
>
> David, if you can update your patch with some docs to explain the
> behaviour, it looks complete enough to think about committing it in
> early January, to allow other patches that depend upon it to stand a
> chance of getting into 9.5. (It is
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > FWIW I've been giving this patch a look and and adjusting some coding
> > details here and there. Do you intend to commit it yourself? You're
> > not listed as reviewer or committer for it in the commitfest
On Fri, Dec 19, 2014 at 11:52 AM, Christoph Berg wrote:
>
> Re: Chris Butler 2014-12-19 <
> 1155204201.65430.1418975376728.javamail.zim...@zedcore.com>
> > One of our servers is currently running on postgres 9.2 using the
> 9.2.9-1.pgdg70+1 packages from pgdg.
> >
> > After an apt update this morn
On Fri, Dec 19, 2014 at 6:30 PM, Petr Jelinek wrote:
> On 10/12/14 16:03, Petr Jelinek wrote:
>>
>> On 10/12/14 04:26, Michael Paquier wrote:
>>>
>>> On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
>>> wrote:
Yeah, it was raised. I don't think it was really addressed. There was
On 19/12/14 13:17, Michael Paquier wrote:
On Fri, Dec 19, 2014 at 6:30 PM, Petr Jelinek wrote:
On 10/12/14 16:03, Petr Jelinek wrote:
On 10/12/14 04:26, Michael Paquier wrote:
On Thu, Dec 4, 2014 at 9:26 PM, Heikki Linnakangas
wrote:
Yeah, it was raised. I don't think it was really addre
Amit,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> 1. Parallel workers help a lot when there is an expensive qualification
> to evaluated, the more expensive the qualification the more better are
> results.
I'd certainly hope so. ;)
> 2. It works well for low selectivity quals and as the sel
When streaming replication was introduced in 9.0, we started to recycle
old WAL segments in archive recovery, like we do during normal
operation. The WAL segments are recycled on the current timeline. There
is no guarantee that they are useful, if the current timeline changes,
because we step t
On Fri, Dec 19, 2014 at 7:51 AM, Stephen Frost wrote:
>> 3. After certain point, increasing having more number of workers won't
>> help and rather have negative impact, refer Test-4.
>
> Yes, I see that too and it's also interesting- have you been able to
> identify why? What is the overhead (spe
On 15/12/14 19:42, Robert Haas wrote:
On Mon, Dec 15, 2014 at 12:57 AM, Petr Jelinek wrote:
we've made few helper functions for making logical replication easier, I
bundled it into contrib module as this is mainly for discussion at this time
(I don't expect this to get committed any time soon,
On Thu, Dec 18, 2014 at 11:51 PM, Tom Lane wrote:
> What it boils down to is that numeric is great for storing given decimal
> inputs exactly, and it can do exact addition/subtraction/multiplication
> on those too, but as soon as you get into territory where the result is
> fundamentally inexact i
The fact that the ROLE_ATTR_* definitions are in pg_authid.h means that
there are now a lot of files that need to include that one. I think the
includes relative to ACLs and roles is rather messy now, and this patch
makes it a bit worse.
I think we should create a new header file (maybe acltypes.
On Wed, Dec 17, 2014 at 2:53 PM, Robert Haas wrote:
> In the meantime, I had a good chat with Heikki on IM yesterday which
> gave me some new ideas on how to fix up the transaction handling in
> here, which I am working on implementing. So hopefully I will have
> that by then.
And here is a new
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 19, 2014 at 7:51 AM, Stephen Frost wrote:
> >> 3. After certain point, increasing having more number of workers won't
> >> help and rather have negative impact, refer Test-4.
> >
> > Yes, I see that too and it's also interesting-
On 12/19/14 3:27 PM, Stephen Frost wrote:
We'd have to coach our users to
constantly be tweaking the enable_parallel_query (or whatever) option
for the queries where it helps and turning it off for others. I'm not
so excited about that.
I'd be perfectly (that means 100%) happy if it just defau
* Marko Tiikkaja (ma...@joh.to) wrote:
> On 12/19/14 3:27 PM, Stephen Frost wrote:
> >We'd have to coach our users to
> >constantly be tweaking the enable_parallel_query (or whatever) option
> >for the queries where it helps and turning it off for others. I'm not
> >so excited about that.
>
> I'd
On Fri, Dec 19, 2014 at 9:39 AM, Stephen Frost wrote:
> Perhaps we should reconsider our general position on hints then and
> add them so users can define the plan to be used.. For my part, I don't
> see this as all that much different.
>
> Consider if we were just adding HashJoin support today a
On 12/19/2014 04:39 PM, Stephen Frost wrote:
* Marko Tiikkaja (ma...@joh.to) wrote:
On 12/19/14 3:27 PM, Stephen Frost wrote:
We'd have to coach our users to
constantly be tweaking the enable_parallel_query (or whatever) option
for the queries where it helps and turning it off for others. I'm
Magnus Hagander writes:
> On Fri, Dec 19, 2014 at 11:52 AM, Christoph Berg wrote:
>> Googling for "digest too big for rsa key" seems to indicate that this
>> problem occurs when you are using (client?) certificates with short
>> RSA keys. 512 bits is most often cited in the problem reports,
>> so
On 12/15/2014 11:38 AM, Alex Shulgin wrote:
These are all valid concerns IMHO. Attached is the modified version of
the original patch by Craig, addressing the handling of the new
hint_log error data field and removing the client-side HINT. I'm also
moving this to the current CF. -- Alex
Hi Christoph,
- Original Message -
> From: "Christoph Berg"
> To: "Chris Butler"
>
> Googling for "digest too big for rsa key" seems to indicate that this
> problem occurs when you are using (client?) certificates with short
> RSA keys. 512 bits is most often cited in the problem reports
Steve Singer writes:
> On 12/15/2014 11:38 AM, Alex Shulgin wrote:
>
>> These are all valid concerns IMHO. Attached is the modified version
>> of the original patch by Craig, addressing the handling of the new
>> hint_log error data field and removing the client-side HINT. I'm
>> also moving thi
On 12/19/2014 11:41 PM, Alex Shulgin wrote:
> I don't think so. The scenario this patch relies on assumes that the
> DBA will remember to look in the log if something goes wrong
Well, actually, the whole point was that the user who's connecting
(likely also the "DBA") will see a HINT telling them
Robert Haas writes:
> I think what it boils down to is that several people here (and I'll
> add my voice to the chorus) are saying, hey, numeric is really useful,
> and we'd like to be able to manipulate numerics without all the palloc
> and fmgr overhead, and your response appears to be to say, u
Hi,
When debugging lwlock issues I found PRINT_LWDEBUG/LOG_LWDEBUG rather
painful to use because of the amount of elog contexts/statements
emitted. Given the number of lwlock acquirations that's just not doable.
To solve that during development I've solved that by basically
replacing:
if (Tra
On Fri, Dec 19, 2014 at 10:56 AM, Tom Lane wrote:
> Well, there are two components to what I'm saying. One is that the
> example David started with looks like it could use some better-informed
> consideration about which datatype to use. The other is that numeric
> leaves quite a lot to be desir
Craig Ringer writes:
> On 12/19/2014 11:41 PM, Alex Shulgin wrote:
>> I don't think so. The scenario this patch relies on assumes that the
>> DBA will remember to look in the log if something goes wrong
>
> Well, actually, the whole point was that the user who's connecting
> (likely also the "D
On Fri, Dec 19, 2014 at 6:28 AM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:
> On 19/12/14 20:48, Andres Freund wrote:
>
>> On 2014-12-18 10:02:25 -0800, Joshua D. Drake wrote:
>>
>>> I think a lot of hackers forget exactly how tender their egos are. Now I
>>> say
>>> this knowing that a
Alvaro Herrera wrote:
> The fact that the ROLE_ATTR_* definitions are in pg_authid.h means that
> there are now a lot of files that need to include that one. I think the
> includes relative to ACLs and roles is rather messy now, and this patch
> makes it a bit worse.
>
> I think we should create
On Thu, Dec 18, 2014 at 11:51:37PM -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
>
> > I think that's ridiculous. You're basically arguing that numeric
> > doesn't offer meaningful advantages over float8, which flies in
> > the face of the fact that essentially every database application
> >
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Andres Freund wrote:
> >
> > > Having reread the patch just now I basically see two things to
> > > criticize:
> > > a) why isn't this accessible at SQL level? That seems easy to address.
> > > b) Arguably some of this could well be done in separat
On Wed, Dec 17, 2014 at 02:00:18PM -0500, Stephen Frost wrote:
> Another thought I had was to suggest we consider *everyone* to be a
> contributor and implement a way to tie together the mailing list
> archives with the commit history and perhaps the commitfest app and make
> it searchable and inde
On 20/12/14 03:54, Heikki Linnakangas wrote:
On 12/19/2014 04:39 PM, Stephen Frost wrote:
* Marko Tiikkaja (ma...@joh.to) wrote:
On 12/19/14 3:27 PM, Stephen Frost wrote:
We'd have to coach our users to
constantly be tweaking the enable_parallel_query (or whatever) option
for the queries where
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Dec 19, 2014 at 9:39 AM, Stephen Frost wrote:
> > Perhaps we should reconsider our general position on hints then and
> > add them so users can define the plan to be used.. For my part, I don't
> > see this as all that much different
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> On 12/19/2014 04:39 PM, Stephen Frost wrote:
> >* Marko Tiikkaja (ma...@joh.to) wrote:
> >>I'd be perfectly (that means 100%) happy if it just defaulted to
> >>off, but I could turn it up to 11 whenever I needed it. I don't
> >>believe to be
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Alvaro Herrera wrote:
> > I think we should create a new header file (maybe acltypes.h or
> > acldefs.h), which only contains the AclMode and RoleAttr typedefs and
> > their associated defines; that one would be included from parsenodes.h,
> > ac
On 12/19/2014 02:55 PM, Heikki Linnakangas wrote:
I'm thinking that we should add a step to promotion, where we scan
pg_xlog for any segments higher than the timeline switch point, and
remove them, or mark them with .done so that they are not archived.
There might be some real WAL that was stream
On 12/18/2014 12:32 PM, Fujii Masao wrote:
On Wed, Dec 17, 2014 at 4:11 AM, Heikki Linnakangas
wrote:
On 12/16/2014 10:24 AM, Borodin Vladimir wrote:
12 дек. 2014 г., в 16:46, Heikki Linnakangas
написал(а):
There have been a few threads on the behavior of WAL archiving,
after a standby ser
On 12/19/2014 12:28 AM, Mark Kirkwood wrote:
To me that's a bit over the top stereotyping.
+1
Having been mentioned one or two times myself - it was an unexpected
"wow - cool" rather than a grumpy/fragile "I must be noticed" thing. I
think some folk have forgotten the underlying principle o
On 12/18/14, 5:00 PM, Jim Nasby wrote:
2201582 20 -- Mostly LOCALLOCK and Shared Buffer
Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
be worth looking at, though it requires uint64.
It also occurs to me that we're needlessly shoving a lot of 0's into the hash
Jim Nasby writes:
> On 12/18/14, 5:00 PM, Jim Nasby wrote:
>> 2201582 20 -- Mostly LOCALLOCK and Shared Buffer
> Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
> be worth looking at, though it requires uint64.
> It also occurs to me that we're needlessly shoving a
On Fri, Dec 19, 2014 at 04:41:51PM -0600, Jim Nasby wrote:
> On 12/18/14, 5:00 PM, Jim Nasby wrote:
> >2201582 20 -- Mostly LOCALLOCK and Shared Buffer
>
> Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
> be worth looking at, though it requires uint64.
>
> It also
On 12/18/2014 05:36 PM, Stephen Frost wrote:
> I tend to agree that we want to avoid complicated rules. The corollary
> to that is the concern Andrew raised about my earlier off-the-cuff
> proposal- how do we avoid debasing the value of being recognized as a PG
> contributor?
I find that less of
"k...@rice.edu" writes:
> If we are going to consider changing the hash function, we should
> consider something like xxhash which runs at 13.8GB/s on a 2.7GHz
> x86_64 for the XXH64 variant and 6.8GB/s for the XXH32 variant which
> is double the speed of fast-hash according to the page running on
Josh Berkus writes:
> On 12/18/2014 05:36 PM, Stephen Frost wrote:
>>> I do agree that we need to give credit in some form, though. I'm just
>>> saying can we please not put the responsibility on committers.
>> Ugh, yeah, I certainly wouldn't want to have to work out some complex
>> set of rules
On Thu, Dec 18, 2014 at 6:59 AM, Heikki Linnakangas
wrote:
>> Good point.
>>
>> For the IGNORE case: I guess the syntax just isn't that flexible. I
>> agree that that isn't ideal.
>
>
> It should be simple to allow multiple key specifications:
>
> INSERT INTO persons (username, real_name, data)
>
On Wed, Dec 17, 2014 at 8:25 AM, David Fetter [via PostgreSQL] <
ml-node+s1045698n5831124...@n5.nabble.com> wrote:
> On Wed, Dec 17, 2014 at 08:14:04AM -0500, Andrew Dunstan wrote:
>
> >
> > On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:
> > >On 12/17/2014 10:03 AM, Albe Laurenz wrote:
> > >>Da
Right now, both table and domain constraints share the same
classification in the ObjType enum, OBJECT_CONSTRAINT. For my patch to
implement improved object drop reporting in event triggers, it is
necessary to separate them, as per in the attach patch.
One emerging side-effect is that it is now p
On Wed, Dec 17, 2014 at 02:41:39PM +, Simon Riggs wrote:
> Is there anything different here from work in my original patch series?
Not to my knowledge.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On 12/19/14, 5:13 PM, Tom Lane wrote:
Jim Nasby writes:
On 12/18/14, 5:00 PM, Jim Nasby wrote:
2201582 20 -- Mostly LOCALLOCK and Shared Buffer
Started looking into this; perhaps https://code.google.com/p/fast-hash/ would
be worth looking at, though it requires uint64.
It also occurs to
On 12/19/14, 6:16 PM, Tom Lane wrote:
Could we establish an expectation that whoever sets a CF entry to "ready
for committer" is responsible for reviewing the authors/reviewers lists
and making sure that those fairly represent who should get credit? That
would divide the labor a bit, and there w
On 2014-12-19 22:17:54 -0600, Jim Nasby wrote:
> git does allow you to revise a commit message; it just makes
> downstream pulls uglier if the commit was already pushed (see
> https://help.github.com/articles/changing-a-commit-message/). It might
> be possible to minimize or even eliminate that pai
On 2014-12-19 22:03:55 -0600, Jim Nasby wrote:
> I'm not suggesting we change BufferTag or BufferLookupEnt; clearly we
> can't simply throw away any of the fields I was talking about (well,
> except possibly tablespace ID. AFAICT that's completely redundant for
> searching because relid is UNIQUE).
On Sat, Jun 28, 2014 at 06:08:05AM +, Tom Lane wrote:
> Allow pushdown of WHERE quals into subqueries with window functions.
>
> We can allow this even without any specific knowledge of the semantics
> of the window function, so long as pushed-down quals will either accept
> every row in a giv
On 20/12/14 11:22, Joshua D. Drake wrote:
On 12/19/2014 12:28 AM, Mark Kirkwood wrote:
To me that's a bit over the top stereotyping.
+1
Having been mentioned one or two times myself - it was an unexpected
"wow - cool" rather than a grumpy/fragile "I must be noticed" thing. I
think some fol
Buildfarm members magpie, treepie and fulmar went absent on 2014-10-29. Since
returning on 2014-11-16, they have consistently failed with 'initdb: invalid
locale name "cs_CZ.WIN-1250"'. No commits in that period readily explain a
regression in this area. Did the underlying system configurations
PostgreSQL 9.2 and later support Python 3.3 and Python 3.4; PostgreSQL 9.1 and
9.0 do not. Buildfarm member raccoon upgraded from Python 2.7 to Python 3.3
for its 2013-08-18 run, and it has failed for REL9_1_STABLE and REL9_0_STABLE
ever since. Please omit --with-python for those branches. (Poin
61 matches
Mail list logo