On Wed, May 7, 2014 at 1:21 PM, Craig Ringer wrote:
> On 05/07/2014 07:16 AM, Michael Paquier wrote:
>> On Wed, May 7, 2014 at 8:07 AM, Andres Freund wrote:
>>> On 2014-05-06 22:49:07 +0900, Michael Paquier wrote:
>>> FWIW, the format you're using makes applying the patch including the
>>> commit
On 7 May 2014 02:05, Kouhei Kaigai wrote:
> Prior to the development cycle towards v9.5, I'd like to reopen
> the discussion of custom-plan interface. Even though we had lots
> of discussion during the last three commit-fests, several issues
> are still under discussion. So, I'd like to clarify di
On 07/05/14 17:35, Peter Geoghegan wrote:
On Tue, May 6, 2014 at 10:20 PM, Simon Riggs wrote:
On 6 May 2014 23:47, Josh Berkus wrote:
If you're going to make
an argument in favor of different tuning advice, then do it based on
something in which you actually believe, based on hard evidence.
On Tue, May 6, 2014 at 10:20 PM, Simon Riggs wrote:
> On 6 May 2014 23:47, Josh Berkus wrote:
>
>> If you're going to make
>> an argument in favor of different tuning advice, then do it based on
>> something in which you actually believe, based on hard evidence.
>
> The proposed default setting o
On 6 May 2014 23:28, Tom Lane wrote:
> Robert Haas writes:
>> I basically think the auto-tuning we've installed for
>> effective_cache_size is stupid. Most people are going to run with
>> only a few GB of shared_buffers, so setting effective_cache_size to a
>> small multiple of that isn't going
On 6 May 2014 23:47, Josh Berkus wrote:
> If you're going to make
> an argument in favor of different tuning advice, then do it based on
> something in which you actually believe, based on hard evidence.
The proposed default setting of 4x shared_buffers is unprincipled
*and* lacks hard evidence
On 05/07/2014 07:16 AM, Michael Paquier wrote:
> On Wed, May 7, 2014 at 8:07 AM, Andres Freund wrote:
>> On 2014-05-06 22:49:07 +0900, Michael Paquier wrote:
>> FWIW, the format you're using makes applying the patch including the
>> commit message relatively hard. Consider using git format-patch.
On Tue, May 6, 2014 at 8:08 PM, Tom Lane wrote:
> The early-exit code path supposes that JB_ROOT_COUNT is absolutely
> reliable as an indicator that there's nothing in the jsonb value.
> On the other hand, the realloc logic inside the iteration loop implies
> that JB_ROOT_COUNT is just an untrustw
Peter Eisentraut writes:
> On Thu, 2014-05-01 at 22:51 -0400, Tom Lane wrote:
>> -1. Doesn't this break "make man" for *any* hacker who doesn't have
>> xmllint installed?
> The intention is that we enforce that the documentation is correctly
> formatted. Enforcing that only when the required to
Would someone care to defend this code?
inttotal = 2 * JB_ROOT_COUNT(jb);
...
if (total == 0)
{
*nentries = 0;
PG_RETURN_POINTER(NULL);
}
...
while ((r = JsonbIteratorNext(&it, &v, false)) != WJB_DONE)
{
if (i >= total)
On Tue, May 6, 2014 at 8:25 PM, Michael Paquier
wrote:
>
> On Wed, May 7, 2014 at 8:22 AM, Andres Freund
wrote:
> > Uh. They're different:
> >
> > Datum
> > timestamp_hash(PG_FUNCTION_ARGS)
> > {
> > /* We can use either hashint8 or hashfloat8 directly */
> > #ifdef HAVE_INT64_TIMESTAMP
>
On Thu, 2014-05-01 at 22:51 -0400, Tom Lane wrote:
> > But we don't have xmllint installed on borka, where we build the
> > releases. Could someone please install it?
>
> -1. Doesn't this break "make man" for *any* hacker who doesn't have
> xmllint installed?
>
> Please change the patch so that
On 2014-04-30 18:17:54 +0200, Andres Freund wrote:
> On 2014-04-30 18:09:15 +0200, Andres Freund wrote:
> > The issues here don't seem to have been addressed in the commit. At
> > least the latin1 thing should be fixed.
>
> As an additional issue it currently doesn't seem to work in VPATH
> build
On 2014-05-06 20:44:56 -0400, Peter Eisentraut wrote:
> On Wed, 2014-04-30 at 18:09 +0200, Andres Freund wrote:
> > On 2014-04-04 16:44:46 +0200, Andres Freund wrote:
> > > On 2014-02-27 21:44:48 -0500, Peter Eisentraut wrote:
> > > > +open HBA, ">>$tempdir/pgdata/pg_hba.conf";
> > > > +print HBA "
On Tue, May 6, 2014 at 5:13 PM, Andres Freund wrote:
> If you think the following is a solution of essential complexity in
> *new* code for navigating one level down a relatively simple *new*
> datastructure - then we have a disconnect that's larger than I am
> willing to argue about
You omitted
On Wed, 2014-04-30 at 18:09 +0200, Andres Freund wrote:
> On 2014-04-04 16:44:46 +0200, Andres Freund wrote:
> > On 2014-02-27 21:44:48 -0500, Peter Eisentraut wrote:
> > > +open HBA, ">>$tempdir/pgdata/pg_hba.conf";
> > > +print HBA "local replication all trust\n";
> > > +print HBA "host replicati
On Tue, May 6, 2014 at 06:24:47PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, May 6, 2014 at 05:35:15PM -0400, Tom Lane wrote:
> >> But I don't see the reason why we shouldn't expect ecpg's headers to
> >> conform to our layout rules.
>
> > I don't know who ecpg got in there. Le
On 06/05/14 19:05, Robert Haas wrote:
Which brings up another point: the behavior of non-shmem-connected
workers is totally bizarre. An exit status other than 0 or 1 is not
treated as a crash requiring a restart, but failure to disengage the
deadman switch is still treated as a crash requiring a
On 2014-05-06 15:45:39 -0700, Peter Geoghegan wrote:
> I don't really know what to say to that. Lots of code in Postgres is
> complicated, especially if you look at one particular function without
> some wider context.
> Is your objection that the complexity is incidental rather than
> essential?
On Wed, May 7, 2014 at 8:22 AM, Andres Freund wrote:
> Uh. They're different:
>
> Datum
> timestamp_hash(PG_FUNCTION_ARGS)
> {
> /* We can use either hashint8 or hashfloat8 directly */
> #ifdef HAVE_INT64_TIMESTAMP
> return hashint8(fcinfo);
> #else
> return hashfloat8(fcin
On 2014-05-07 08:16:38 +0900, Michael Paquier wrote:
> On Wed, May 7, 2014 at 8:07 AM, Andres Freund wrote:
> > On 2014-05-06 22:49:07 +0900, Michael Paquier wrote:
> > FWIW, the format you're using makes applying the patch including the
> > commit message relatively hard. Consider using git forma
On Wed, May 7, 2014 at 8:07 AM, Andres Freund wrote:
> On 2014-05-06 22:49:07 +0900, Michael Paquier wrote:
> FWIW, the format you're using makes applying the patch including the
> commit message relatively hard. Consider using git format-patch.
Could you be clearer? By applying a filterdiff comma
Hi,
On 2014-05-06 22:49:07 +0900, Michael Paquier wrote:
> Makes sense, especially knowing operators needed for btree processing
> are already defined. Patch attached solves that.
Thanks for doing that quickly.
FWIW, the format you're using makes applying the patch including the
commit message r
On Tue, May 6, 2014 at 10:49 PM, Michael Paquier
wrote:
> Makes sense, especially knowing operators needed for btree processing
> are already defined. Patch attached solves that.
Please find attached an updated patch, I completely forgot that the
compare function needs to return {-1, 0, 1}.
--
Mi
On Tue, May 6, 2014 at 3:39 PM, Tom Lane wrote:
> Meh. I would not think that that represents effective use of JSON:
> if the rows are all the same, why aren't you exposing that structure
> as regular SQL columns? IMHO, the value of JSON fields within a SQL
> table is to deal with data that is n
Robert, Tom:
On 05/06/2014 03:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> I basically think the auto-tuning we've installed for
>> effective_cache_size is stupid. Most people are going to run with
>> only a few GB of shared_buffers, so setting effective_cache_size to a
>> small multiple of t
On May 6, 2014, at 3:39 PM, Tom Lane wrote:
> Meh. I would not think that that represents effective use of JSON:
> if the rows are all the same, why aren't you exposing that structure
> as regular SQL columns? IMHO, the value of JSON fields within a SQL
> table is to deal with data that is not
On 05/06/2014 01:38 PM, Simon Riggs wrote:
>> Most of them? Really?
>
> I didn't use the word "most" anywhere. So not really clear what you are
> saying.
Sorry, those were supposed to be periods, not question marks. As in
"Most of them. Really."
>> I have to tell you, your post sounds like y
On Tue, May 6, 2014 at 3:37 PM, Andres Freund wrote:
> That might or might not be true. I don't really remember. Documentation
> about the on-disk format is the one thing I am sure about that's not
> done.
I think it would be best to do that with reference to a concrete
example. As I said, I'll w
Peter Geoghegan writes:
> On Tue, May 6, 2014 at 3:20 PM, Tom Lane wrote:
>> I wonder whether the most effective use of time at this point
>> wouldn't be to fix jsonb_ops to do that, rather than arguing about
>> what to rename it to. If it didn't have the failure-for-long-strings
>> problem I do
On 2014-05-06 13:30:26 -0700, Peter Geoghegan wrote:
> On Tue, May 6, 2014 at 12:48 PM, Andres Freund wrote:
> > Enthusiatically seconded. I've asked for that about three times without
> > much success. If it had been my decision the patch wouldn't have been
> > merged without that and other adj
On Tue, May 6, 2014 at 3:20 PM, Tom Lane wrote:
> I wonder whether the most effective use of time at this point
> wouldn't be to fix jsonb_ops to do that, rather than arguing about
> what to rename it to. If it didn't have the failure-for-long-strings
> problem I doubt anybody would be unhappy ab
Robert Haas writes:
> I basically think the auto-tuning we've installed for
> effective_cache_size is stupid. Most people are going to run with
> only a few GB of shared_buffers, so setting effective_cache_size to a
> small multiple of that isn't going to make many more people happy than
> just r
Bruce Momjian writes:
> On Tue, May 6, 2014 at 05:35:15PM -0400, Tom Lane wrote:
>> But I don't see the reason why we shouldn't expect ecpg's headers to
>> conform to our layout rules.
> I don't know who ecpg got in there. Let me know what you would like
> done.
What I'm suggesting is that, in
"David E. Wheeler" writes:
> On May 6, 2014, at 2:20 PM, Bruce Momjian wrote:
>> Well, then, we only have a few days to come up with a name.
> What are the options?
We have no proposals as yet.
I've been looking at the source code to try to understand the difference
between the two opclasses (
On Tue, May 6, 2014 at 05:35:15PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Ah, found it. There is an excludes pattern file list I had forgotten
> > about; it has:
>
> > /s_lock\.h$
> > /ecpg/test/expected/
> > /snowball/libstemmer/
> > /ecpg/include/(sqlda|sqltypes)\.
On 6 May 2014 22:54, Robert Haas wrote:
> On Tue, May 6, 2014 at 4:38 PM, Simon Riggs wrote:
>> I read the code, think what to say and then say what I think, not
>> rely on dogma.
>>
>> I tried to help years ago by changing the docs on e_c_s, but that's
>> been mostly ignored down the years, as
On 2014-05-06 22:04:04 +0100, Simon Riggs wrote:
> On 6 May 2014 20:44, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, May 6, 2014 at 2:34 PM, Tom Lane wrote:
> >>> FWIW, I vote for fixing (a) now but holding (b) for 9.5.
> >
> >> I guess I'll vote for applying both. I don't see a lot of
On 2014-05-06 15:37:04 -0400, Robert Haas wrote:
> On Tue, May 6, 2014 at 2:34 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> Attached are two patches:
> >> a) Patch addin a 'name' parameter to dsm_create(). I think we should
> >>apply this to 9.4.
> >> b) pg_dynamic_shmem_allocations and
On 05/06/2014 05:54 PM, Robert Haas wrote:
On Tue, May 6, 2014 at 4:38 PM, Simon Riggs wrote:
I read the code, think what to say and then say what I think, not
rely on dogma.
I tried to help years ago by changing the docs on e_c_s, but that's
been mostly ignored down the years, as it is aga
On Tue, May 6, 2014 at 4:38 PM, Simon Riggs wrote:
> I read the code, think what to say and then say what I think, not
> rely on dogma.
>
> I tried to help years ago by changing the docs on e_c_s, but that's
> been mostly ignored down the years, as it is again here.
Well, for what it's worth, I'
Bruce Momjian writes:
> Ah, found it. There is an excludes pattern file list I had forgotten
> about; it has:
> /s_lock\.h$
> /ecpg/test/expected/
> /snowball/libstemmer/
> /ecpg/include/(sqlda|sqltypes)\.h$
> /ecpg/include/preproc/struct\.h$
> /pl/plperl/ppp
On May 6, 2014, at 2:20 PM, Bruce Momjian wrote:
>> Stuck on the naming question. I'd be willing to do the patch legwork
>> if we had a consensus (or even a proposal) for what to rename the
>> current jsonb_ops to.
>
> Well, then, we only have a few days to come up with a name.
What are the op
I wrote:
> I looked into this, and find that the cause of the problem is that
> pgindent touched src/interfaces/ecpg/include/sqlca.h, which is copied
> verbatim into preprocessed files by the ecpg preprocessor, so the expected
> files had to change in tandem. This amounts to a dependency, but the
On Tue, May 6, 2014 at 04:18:50PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Apr 22, 2014 at 08:50:20PM -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> Where are we on the default JSONB opclass change?
>
> >> Not sure. I'm for changing it, I think, but it wasn't at all
On Tue, May 6, 2014 at 05:05:00PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, May 6, 2014 at 03:54:24PM -0400, Tom Lane wrote:
> >> But having said that, if this didn't work then there's something broken
> >> about the make rules for the ecpg tests. I'm a bit suspicious of commit
Bruce Momjian writes:
> On Tue, May 6, 2014 at 03:54:24PM -0400, Tom Lane wrote:
>> But having said that, if this didn't work then there's something broken
>> about the make rules for the ecpg tests. I'm a bit suspicious of commit
>> 69e9768e7b183d4b276d0e067a5a689580eb.
I looked into this,
On 6 May 2014 20:44, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 6, 2014 at 2:34 PM, Tom Lane wrote:
>>> FWIW, I vote for fixing (a) now but holding (b) for 9.5.
>
>> I guess I'll vote for applying both. I don't see a lot of risk, and I
>> think doing one with out the other is somewhat
On 6.5.2014 22:24, Tom Lane wrote:
> Tomas Vondra writes:
>> I recall there was a call for more animals with CLOBBER_CACHE_ALWAYS
>> some time ago, so I went and enabled that on all three animals. Let's
>> see how long that will take.
>
>> I see there are more 'clobber' options in the code: CLOBB
On 6 May 2014 20:41, Jeff Janes wrote:
> The e_c_s is assumed to be usable for each backend trying to run queries
> sensitive to it. If you have dozens of such queries running simultaneously
> (not something I personally witness, but also not insane) and each of these
> queries has its own pecul
On 6 May 2014 18:08, Josh Berkus wrote:
> On 05/06/2014 08:41 AM, Simon Riggs wrote:
>> On 6 May 2014 15:18, Tom Lane wrote:
>>> Simon Riggs writes:
Lets fix e_c_s at 25% of shared_buffers and remove the parameter
completely, just as we do with so many other performance parameters.
>>>
FYI,
http://obartunov.livejournal.com/178495.html
This is hash based gin opclass for hstore with all operators support.
It's pity we had no time to do the same for jsonb, but we may include
it and couple of other opclasses to contrib/jsonx.
Oleg
On Wed, May 7, 2014 at 12:18 AM, Peter Geoghegan
On Tue, May 6, 2014 at 12:48 PM, Andres Freund wrote:
> Enthusiatically seconded. I've asked for that about three times without much
> success. If it had been my decision the patch wouldn't have been merged
> without that and other adjustments.
I'm almost certain that the only feedback of yours
Tomas Vondra writes:
> I recall there was a call for more animals with CLOBBER_CACHE_ALWAYS
> some time ago, so I went and enabled that on all three animals. Let's
> see how long that will take.
> I see there are more 'clobber' options in the code: CLOBBER_FREED_MEMORY
> and CLOBBER_CACHE_RECURSI
Bruce Momjian writes:
> On Tue, Apr 22, 2014 at 08:50:20PM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Where are we on the default JSONB opclass change?
>> Not sure. I'm for changing it, I think, but it wasn't at all clear
>> that we had consensus on that. We did not have a proposed ne
On Tue, May 6, 2014 at 1:06 PM, Bruce Momjian wrote:
> I also would like to know what the index-everything hash ops does? Does
> it index the keys, values, or both?
It indexes both, but it isn't possible to test existence (of a key)
with the hash GIN opclass.
--
Peter Geoghegan
--
Sent via
On Tue, May 6, 2014 at 09:48:04PM +0200, Andres Freund wrote:
> On May 6, 2014 9:30:15 PM CEST, Heikki Linnakangas
> wrote:
> >I'm reading the new jsonb code, trying to understand the on-disk
> >representation. And I cannot make heads or tails of it.
> >
> >My first entry point was jsonb.h. Jso
On 4.5.2014 21:29, Tomas Vondra wrote:
> On 3.5.2014 19:01, Andrew Dunstan wrote:
>>
>> On 05/03/2014 12:42 PM, Tomas Vondra wrote:
>>> On 3.5.2014 03:07, Noah Misch wrote:
More coverage of non-gcc compilers would be an asset to the buildfarm.
>>> Does that include non-gcc compilers on Linux/x
On Tue, Apr 22, 2014 at 08:50:20PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Where are we on the default JSONB opclass change?
>
> Not sure. I'm for changing it, I think, but it wasn't at all clear
> that we had consensus on that. We did not have a proposed new name
> for the opclass e
On Tue, May 6, 2014 at 03:54:24PM -0400, Tom Lane wrote:
> Kevin Grittner writes:
> > Bruce Momjian wrote:
> >> Yes, I had to modify those lines before I pushed the pgindent changes so
> >> 'make installcheck-world' would pass.� It passes here for me now.� Did
> >> you do 'make maintainer-clean'
Kevin Grittner writes:
> Bruce Momjian wrote:
>> Yes, I had to modify those lines before I pushed the pgindent changes so
>> 'make installcheck-world' would pass. It passes here for me now. Did
>> you do 'make maintainer-clean' before running the tests? That might
>> help.
> It occurred to me
Kevin Grittner wrote:
> It occurred to me after my last post that I had just done a "make
> world" without any cleanup when I pulled that, and had started a
> full build from "make maintainer-clean" when you sent that. :-)
>
> I'll let you know either way when I get results from that.
Yeah, aft
On May 6, 2014 9:30:15 PM CEST, Heikki Linnakangas
wrote:
>I'm reading the new jsonb code, trying to understand the on-disk
>representation. And I cannot make heads or tails of it.
>
>My first entry point was jsonb.h. Jsonb struct is the on-disk
>representation, so I looked at the comments abov
Bruce Momjian wrote:
> On Tue, May 6, 2014 at 12:38:41PM -0700, Kevin Grittner wrote:
>> Tom Lane wrote:
>>> Kevin Grittner writes:
>>>
Bruce Momjian wrote:
> pgindent run for 9.4
>>>
The 13 tests above are broken by this commit. Probably the
directory should be excluded fr
Robert Haas writes:
> On Tue, May 6, 2014 at 2:34 PM, Tom Lane wrote:
>> FWIW, I vote for fixing (a) now but holding (b) for 9.5.
> I guess I'll vote for applying both. I don't see a lot of risk, and I
> think doing one with out the other is somewhat pointless.
The difference is that there's n
On Tue, May 6, 2014 at 7:18 AM, Tom Lane wrote:
> Simon Riggs writes:
> > Lets fix e_c_s at 25% of shared_buffers and remove the parameter
> > completely, just as we do with so many other performance parameters.
>
> Apparently, you don't even understand what this parameter is for.
> Setting it s
On Tue, May 6, 2014 at 12:38:41PM -0700, Kevin Grittner wrote:
> Tom Lane wrote:
> > Kevin Grittner writes:
> >
> >> Bruce Momjian wrote:
> >>> pgindent run for 9.4
> >
> >> The 13 tests above are broken by this commit. Probably the
> >> directory should be excluded from pgindent processing.
>
Tom Lane wrote:
> Kevin Grittner writes:
>
>> Bruce Momjian wrote:
>>> pgindent run for 9.4
>
>> The 13 tests above are broken by this commit. Probably the
>> directory should be excluded from pgindent processing.
>
> What's broken? The buildfarm isn't complaining, and "make installcheck"
> in
On Tue, May 6, 2014 at 2:34 PM, Tom Lane wrote:
> Andres Freund writes:
>> Attached are two patches:
>> a) Patch addin a 'name' parameter to dsm_create(). I think we should
>>apply this to 9.4.
>> b) pg_dynamic_shmem_allocations and pg_static_shmem_allocations
>>views. The previous versio
I'm reading the new jsonb code, trying to understand the on-disk
representation. And I cannot make heads or tails of it.
My first entry point was jsonb.h. Jsonb struct is the on-disk
representation, so I looked at the comments above that. No help, the
comments are useless for getting an overvi
On Tue, May 6, 2014 at 11:31 AM, Tom Lane wrote:
> The source code says that "query strings are normalized on a best effort
> basis", so perhaps we ought to say the same in the documentation.
Perhaps.
> It would be rather expensive to provide a guarantee of normalization:
> basically, we'd have
Kevin Grittner writes:
> Bruce Momjian wrote:
>> pgindent run for 9.4
> The 13 tests above are broken by this commit. Probably the
> directory should be excluded from pgindent processing.
What's broken? The buildfarm isn't complaining, and "make installcheck"
in src/interfaces/ecpg/test passe
Bruce Momjian wrote:
> pgindent run for 9.4
>
> This includes removing tabs after periods in C comments, which was
> applied to back branches, so this change should not effect backpatching.
> http://git.postgresql.org/pg/commitdiff/0a7832005792fa6dad171f9cadb8d587fe0dd800
> .../test/expected/co
Hi,
I am not sure whether these are new for 9.4 but they're worth looking at
anyway:
Valgrind was run with:
--trace-children=yes --quiet \
--track-origins=yes --leak-check=no \
--read-var-info=yes \
--suppressions=/home/andres/src/postgresql/src/tools/valgrind.supp \
All seem to be due btree
On 5/5/14, 4:09 PM, Jim Nasby wrote:
> They do not accept DEFAULT though:
>
> GRANT EXECUTE ON FUNCTION test(t text DEFAULT '') to public;
> ERROR: syntax error at or near "DEFAULT"
> LINE 1: GRANT EXECUTE ON FUNCTION test(t text DEFAULT '') to public;
>
> Presumably this is just an oversight?
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 5/2/14, 2:22 PM, Stephen Frost wrote:
> > I'm aware and I really am not convinced that pushing all of this to
> > contrib modules using the hooks is the right approach- for one thing, it
> > certainly doesn't seem to me that we've actually gotten a l
On 5/2/14, 2:22 PM, Stephen Frost wrote:
> I'm aware and I really am not convinced that pushing all of this to
> contrib modules using the hooks is the right approach- for one thing, it
> certainly doesn't seem to me that we've actually gotten a lot of
> traction from people to actually make use of
Andres Freund writes:
> Attached are two patches:
> a) Patch addin a 'name' parameter to dsm_create(). I think we should
>apply this to 9.4.
> b) pg_dynamic_shmem_allocations and pg_static_shmem_allocations
>views. The previous version didn't include dsm support and didn't
>take the re
Robert Haas writes:
> On Tue, May 6, 2014 at 12:26 PM, Michael Renner
>> when regularly collecting & resetting query information from
>> pg_stat_statements itâs possible to trigger a situation where unnormalised
>> queries are stored.
>>
>> Is this something that should be fixed or is this inte
Hi,
On 2014-05-06 13:56:41 +0200, Andres Freund wrote:
> On 2014-05-05 23:20:43 -0400, Robert Haas wrote:
> > On Mon, May 5, 2014 at 6:54 PM, Tom Lane wrote:
> > > I'm not confident that it'll be useful either. But I am confident that
> > > if we don't put it in now, and decide we want it later,
Andreas,
* Andreas Karlsson (andr...@proxel.se) wrote:
> When benchmarking an application I got annoyed at how basic the tab
> completion for ALTER TABLE ... DISABLE/ENABLE TRIGGER and DROP
> TRIGGER is. So here is a patch improving the tab completion around
> triggers. For consistency I have also
Hi,
When benchmarking an application I got annoyed at how basic the tab
completion for ALTER TABLE ... DISABLE/ENABLE TRIGGER and DROP TRIGGER
is. So here is a patch improving the tab completion around triggers. For
consistency I have also added the same completions to rules since their
DDL i
On Tue, May 6, 2014 at 1:46 PM, Andres Freund wrote:
>> > Fix attached.
>>
>> Committed, thanks.
>
> Heh. Not a fan of film references? :)
I didn't quite put the pieces together there. I just thought the use
of "you" was awkward.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ent
On Tue, May 6, 2014 at 12:26 PM, Michael Renner
wrote:
> when regularly collecting & resetting query information from
> pg_stat_statements it’s possible to trigger a situation where unnormalised
> queries are stored.
>
> I think what happens is the following:
>
> pgss_post_parse_analyse calls pgss
On 2014-05-06 13:45:13 -0400, Robert Haas wrote:
> On Tue, May 6, 2014 at 1:14 PM, Andres Freund wrote:
> > On 2014-05-06 08:48:57 -0400, Robert Haas wrote:
> >> On Tue, May 6, 2014 at 8:43 AM, Andres Freund
> >> wrote:
> >> > The break because of refcnt == 1 doesn't generally seem to be a good
On Tue, May 6, 2014 at 1:14 PM, Andres Freund wrote:
> On 2014-05-06 08:48:57 -0400, Robert Haas wrote:
>> On Tue, May 6, 2014 at 8:43 AM, Andres Freund wrote:
>> > The break because of refcnt == 1 doesn't generally seem to be a good
>> > idea. Why are we bailing if there's *any* segment that's i
The plan for beta1 is to wrap the tarball this Sunday (May 11)
for public announcement Thursday May 15. This deviates from our
usual Monday wrap + Thursday announcement schedule so as to give
the packagers a little more time, knowing that packaging scripts
usually require extra adjustments when se
On 2014-05-06 08:48:57 -0400, Robert Haas wrote:
> On Tue, May 6, 2014 at 8:43 AM, Andres Freund wrote:
> > The break because of refcnt == 1 doesn't generally seem to be a good
> > idea. Why are we bailing if there's *any* segment that's in the process
> > of being removed? I think the check shoul
On 05/06/2014 08:41 AM, Simon Riggs wrote:
> On 6 May 2014 15:18, Tom Lane wrote:
>> Simon Riggs writes:
>>> Lets fix e_c_s at 25% of shared_buffers and remove the parameter
>>> completely, just as we do with so many other performance parameters.
>>
>> Apparently, you don't even understand what t
On Sun, May 4, 2014 at 9:57 AM, Petr Jelinek wrote:
> On 30/04/14 23:35, Robert Haas wrote:
>> On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek
>> wrote:
>>> On 28/04/14 16:27, Robert Haas wrote:
It seems we have consensus on what to do about this, but what we
haven't got is a patch.
>>>
>
On 2014-05-06 17:43:45 +0100, Simon Riggs wrote:
> On 6 May 2014 15:17, Andres Freund wrote:
>
> >> Lets fix e_c_s at 25% of shared_buffers and remove the parameter
> >> completely, just as we do with so many other performance parameters.
> >
> > That'd cause *massive* regression for many install
Simon Riggs writes:
> On 6 May 2014 15:18, Tom Lane wrote:
>> Simon Riggs writes:
>>> Lets fix e_c_s at 25% of shared_buffers and remove the parameter
>>> completely, just as we do with so many other performance parameters.
>> Apparently, you don't even understand what this parameter is for.
>>
Robert Haas writes:
> On Mon, May 5, 2014 at 1:53 PM, Tom Lane wrote:
>> A larger and more philosophical point is that such a direction of
>> development could hardly be called a "foreign" data wrapper. People
>> would expect Postgres to take full responsibility for such files,
>> including data
On 6 May 2014 15:17, Andres Freund wrote:
>> Lets fix e_c_s at 25% of shared_buffers and remove the parameter
>> completely, just as we do with so many other performance parameters.
>
> That'd cause *massive* regression for many installations. Without
> significantly overhauling costsize.c that's
On 2014-05-06 13:33:01 +0300, Heikki Linnakangas wrote:
> On 03/31/2014 09:08 PM, Robert Haas wrote:
> >On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan wrote:
> >>On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch wrote:
> >>>The threat is that rounding the read size up to the next MAXALIGN would
> >>
MauMau wrote:
> On Windows, you can use Stackwalk() or Stackwalk64() Win32 API.
> Several years ago, for some software, I implemented a feature that
> outputs the stack trace of a crashing process to its server log
> file.
>
> It would be very nice if PostgreSQL outputs the stack trace of a
> cra
Andres Freund wrote:
> > > * sparc 32bit
> >
> > Do we really care about sparc 32bit at this point? You're talking a
> > 10-year-old machine, there.
>
> I personally don't really, but the last time it came up significant
> parts of community opinionated the other way. And I'd rather have it
> t
Hi,
when regularly collecting & resetting query information from pg_stat_statements
it’s possible to trigger a situation where unnormalised queries are stored.
I think what happens is the following:
pgss_post_parse_analyse calls pgss_store with a non-null jstate which will
cause the query str
On Tue, May 6, 2014 at 08:55:07AM -0400, Bruce Momjian wrote:
> On Sat, May 3, 2014 at 02:20:27PM -0400, Bruce Momjian wrote:
> > I am planning to run pgindent in a few days to prepare for beta. Does
> > anyone have major patches that you are planning to apply soon? If so, I
> > can delay pgind
On 6 May 2014 15:18, Tom Lane wrote:
> Simon Riggs writes:
>> Lets fix e_c_s at 25% of shared_buffers and remove the parameter
>> completely, just as we do with so many other performance parameters.
>
> Apparently, you don't even understand what this parameter is for.
> Setting it smaller than sh
1 - 100 of 143 matches
Mail list logo
