Hi,
Craig just mentioned in an internal chat that there's no btree or even
hash opclass for the new pg_lsn type. That restricts what you can do
with it quite severely.
Imo this should be fixed for 9.4 - after all it was possible unto now to
index a table with lsns returned by system functions or
On Sat, May 3, 2014 at 8:29 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-05-03 13:25:32 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-09-17 08:23:01 -0400, Dave Page wrote:
I've added MAX_CONNECTIONS=5 to both Castoroides and Protosciurus.
I've
On 03/31/2014 09:08 PM, Robert Haas wrote:
On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch n...@leadboat.com wrote:
The threat is that rounding the read size up to the next MAXALIGN would cross
into an unreadable memory page,
Hi!
On Tue, Apr 29, 2014 at 2:34 PM, Костя Кузнецов chapae...@yandex.ru wrote:
There is a task Sequential disk access during VACUUM for GiST/GIN in
list GSOC14.
Nobody is working on this task?
I didn't hear anybody is working on it.
Do I understand this task correctly?
I must recode
PFA patch ecpg_char_ptr_arr.patch to fix this issue. It has changes as
follows
...
Thanks for finding and fixing the problem. Patch applied to complete 9 series
with only a minor change.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael
Hi,
On 2014-05-05 13:41:00 +0300, Heikki Linnakangas wrote:
I came up with the attached fix for this. Currently, the entry is implicitly
considered dead or unlocked if the locking_xid transaction is no longer
active, but this patch essentially turns locking_xid into a simple boolean,
and
On 5 May 2014 21:54, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 5, 2014 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, May 4, 2014 at 7:50 AM, Andres Freund and...@2ndquadrant.com
wrote:
Thinking about this, I think it was a mistake
On 2014-05-05 23:20:43 -0400, Robert Haas wrote:
On Mon, May 5, 2014 at 6:54 PM, Tom Lane t...@sss.pgh.pa.us 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, there will be
complaints when we change the
On Tue, May 6, 2014 at 7:45 AM, Simon Riggs si...@2ndquadrant.com wrote:
The control segment is sized to support a number of dynamic shared
memory segments not exceeding 64 + 2 *MaxBackends. With default
settings, that currently works out to 288 segments, or 2306 bytes.
So, adding a 64-byte
On 19 August 2013 09:20, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 08.08.2013 20:15, Josh Berkus wrote:
Bruce, all:
We seem to be all over the map with the fast promotion code --- some
people don't trust it, some people want an option to enable the old
method, and some people
On 29 January 2014 20:53, Andres Freund and...@2ndquadrant.com wrote:
On 29. Januar 2014 20:51:38 MEZ, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jan 29, 2014 at 8:22 AM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
On 2014-01-29 21:59:05 +0900, Michael Paquier wrote:
The
On 05/06/2014 02:59 PM, Robert Haas wrote:
Why would we call multiple segments the same thing??
It's not clear to me how someone is going to intelligently name
multiple segments used by the same extension. Maybe they'll give them
all the same name. Maybe they'll name them all
On 05/05/2014 07:14 PM, Andres Freund wrote:
Hi,
Walsender does a PQClear(con) but then accesses data acquired with
PQgetvalue(). That's clearly not ok.
Fixed, thanks!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 6 May 2014 13:06, Heikki Linnakangas hlinnakan...@vmware.com wrote:
The best scheme will depend on how the segments
are used. Best to leave it to the extension author.
+1
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
Hi,
dsm_attach() does the following:
nitems = dsm_control-nitems;
for (i = 0; i nitems; ++i)
{
/* If the reference count is 0, the slot is actually unused. */
if (dsm_control-item[i].refcnt == 0)
continue;
On May 4, 2014, at 5:27 PM, Stephen Frost sfr...@snowman.net wrote:
* Neil Tiffin (ne...@neiltiffin.com) wrote:
On May 4, 2014, at 3:17 PM, Stephen Frost sfr...@snowman.net wrote:
Any system where there exists a role similar to 'superuser' in the PG
sense (a user who is equivilant to the
On Tue, May 6, 2014 at 8:43 AM, Andres Freund and...@2ndquadrant.com wrote:
dsm_attach() does the following:
nitems = dsm_control-nitems;
for (i = 0; i nitems; ++i)
{
/* If the reference count is 0, the slot is actually unused.
*/
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 pgindent until you are done.
This run will also have a tabs-in-comments
* Neil Tiffin (ne...@neiltiffin.com) wrote:
On May 4, 2014, at 5:27 PM, Stephen Frost sfr...@snowman.net wrote:
* Neil Tiffin (ne...@neiltiffin.com) wrote:
Well, except that a superuser *could* effectively turn off checksums by
changing the the control file and doing a restart (perhaps
On Sun, May 4, 2014 at 4:50 PM, Jeff Davis pg...@j-davis.com wrote:
If I recall correctly, Tom pointed out a while back that the comment
justifying the lockless read of the VM bit was not correct (or at least
not complete).
I rewrote it, but it was part of a patch that was not accepted.
On Mon, May 05, 2014 at 08:29:56PM -0400, Bruce Momjian wrote:
On Tue, Apr 22, 2014 at 03:19:15PM -0400, Bruce Momjian wrote:
As is often the case with pg_dump, the problems you saw are a small part
of a larger set of problems in that code --- there is general ignoring of
read and write
On Tue, May 6, 2014 at 2:04 PM, Robert Haas robertmh...@gmail.com wrote:
I also didn't find anything that looked like our
memory context paradigm, and in particular the ability to cheaply
reset a context, in any other allocator.
You probably knew this but just in case the term for this
On 05/06/2014 04:04 PM, Robert Haas wrote:
Over the last several months, I've been working on a new memory
allocator for PostgreSQL. While it's not done, and there are
problems, I think I've reached the point where it makes sense to get
this out in front of a wider audience and get some
Hi,
if you split configuration and data by setting data_directory,
postgresql.auto.conf is writen to the data directory
(/var/lib/postgresql/9.4/main in Debian), but tried to be read from
the etc directory (/etc/postgresql/9.4/main).
One place to fix it would be in ProcessConfigFile in
Andres Freund and...@2ndquadrant.com writes:
Craig just mentioned in an internal chat that there's no btree or even
hash opclass for the new pg_lsn type. That restricts what you can do
with it quite severely.
Imo this should be fixed for 9.4 - after all it was possible unto now to
index a
On 2014-05-06 09:37:54 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Craig just mentioned in an internal chat that there's no btree or even
hash opclass for the new pg_lsn type. That restricts what you can do
with it quite severely.
Imo this should be fixed for 9.4 -
Re: Jeff Janes 2014-05-05
CAMkU=1yo97bcGR-z6wg-OJpHKfEcaaaS=x1n7xygxcuakv5...@mail.gmail.com
I've personally never had a need to set the search_path to a system schema,
and I guess I was implicitly modelling this on what is returned by \dn, not
by \dnS. I wouldn't object much to including
On Tue, May 6, 2014 at 9:31 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
As a generic remark, I wish that whatever parallel algorithms we will use
won't need a lot of ad hoc memory allocations from shared memory. Even
though we have dynamic shared memory now, complex data structures
On Tue, May 6, 2014 at 4:14 PM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
Craig just mentioned in an internal chat that there's no btree or even
hash opclass for the new pg_lsn type. That restricts what you can do
with it quite severely.
Imo this should be fixed for 9.4 - after all it
2014-05-05 Bruce Momjian br...@momjian.us:
On Mon, May 5, 2014 at 10:40:29AM -0700, Josh Berkus wrote:
* ALTER SYSTEM SET
Lemme know if you need description text for any of the above.
OK, great! Once I have the markup done, I will beef up the descriptions
if needed and copy the text up
On Tue, May 6, 2014 at 09:22:20AM -0400, Noah Misch wrote:
On Mon, May 05, 2014 at 08:29:56PM -0400, Bruce Momjian wrote:
On Tue, Apr 22, 2014 at 03:19:15PM -0400, Bruce Momjian wrote:
As is often the case with pg_dump, the problems you saw are a small part
of a larger set of problems in
On Tue, May 6, 2014 at 9:25 AM, Greg Stark st...@mit.edu wrote:
On Tue, May 6, 2014 at 2:04 PM, Robert Haas robertmh...@gmail.com wrote:
I also didn't find anything that looked like our
memory context paradigm, and in particular the ability to cheaply
reset a context, in any other allocator.
On 8 October 2013 17:13, Bruce Momjian br...@momjian.us wrote:
Patch applied with a default of 4x shared buffers. I have added a 9.4
TODO that we might want to revisit this.
I certainly want to revisit this patch and this setting.
How can we possibly justify a default setting that could be
On 2014-05-06 15:09:15 +0100, Simon Riggs wrote:
On 8 October 2013 17:13, Bruce Momjian br...@momjian.us wrote:
Patch applied with a default of 4x shared buffers. I have added a 9.4
TODO that we might want to revisit this.
I certainly want to revisit this patch and this setting.
How
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-06 09:37:54 -0400, Tom Lane wrote:
Sorry, it is *way* too late for 9.4.
It's imo a regression/oversight introduced in the pg_lsn patch. Not a
new feature.
You can argue that if you like, but it doesn't matter. It's too late for
a
Simon Riggs si...@2ndquadrant.com 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 shared_buffers is insane.
On 6 May 2014 14:49, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 6, 2014 at 9:31 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
As a generic remark, I wish that whatever parallel algorithms we will use
won't need a lot of ad hoc memory allocations from shared memory. Even
On 05/06/2014 05:17 PM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-06 09:37:54 -0400, Tom Lane wrote:
Sorry, it is *way* too late for 9.4.
It's imo a regression/oversight introduced in the pg_lsn patch. Not a
new feature.
You can argue that if you like, but it
Thanks Michael.
On Tue, May 6, 2014 at 5:01 PM, Michael Meskes mes...@postgresql.orgwrote:
PFA patch ecpg_char_ptr_arr.patch to fix this issue. It has changes as
follows
...
Thanks for finding and fixing the problem. Patch applied to complete 9
series with only a minor change.
On Tue, May 6, 2014 at 7:04 PM, Christoph Berg c...@df7cb.de wrote:
Hi,
if you split configuration and data by setting data_directory,
postgresql.auto.conf is writen to the data directory
(/var/lib/postgresql/9.4/main in Debian), but tried to be read from
the etc directory
On Tue, May 6, 2014 at 10:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
1. Segments are relocatable, so you can't actually use absolute
pointers. Maybe someday we'll have a facility for dynamic shared
memory segments that are mapped at the same address in every process,
or maybe not, but
On Mon, May 5, 2014 at 1:53 PM, Tom Lane t...@sss.pgh.pa.us 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 integrity
On 05/06/2014 04:59 PM, Heikki Linnakangas wrote:
On 05/06/2014 05:17 PM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-06 09:37:54 -0400, Tom Lane wrote:
Sorry, it is *way* too late for 9.4.
It's imo a regression/oversight introduced in the pg_lsn patch. Not a
new
On 6 May 2014 15:18, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
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 pgindent
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
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
tested and
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
crashing
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 p...@heroku.com wrote:
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch n...@leadboat.com wrote:
The threat is that rounding the read size up to the
On 6 May 2014 15:17, Andres Freund and...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Mon, May 5, 2014 at 1:53 PM, Tom Lane t...@sss.pgh.pa.us 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
Simon Riggs si...@2ndquadrant.com writes:
On 6 May 2014 15:18, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
On 2014-05-06 17:43:45 +0100, Simon Riggs wrote:
On 6 May 2014 15:17, Andres Freund and...@2ndquadrant.com 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
On Sun, May 4, 2014 at 9:57 AM, Petr Jelinek p...@2ndquadrant.com wrote:
On 30/04/14 23:35, Robert Haas wrote:
On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek p...@2ndquadrant.com
wrote:
On 28/04/14 16:27, Robert Haas wrote:
It seems we have consensus on what to do about this, but what we
On 05/06/2014 08:41 AM, Simon Riggs wrote:
On 6 May 2014 15:18, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
On 2014-05-06 08:48:57 -0400, Robert Haas wrote:
On Tue, May 6, 2014 at 8:43 AM, Andres Freund and...@2ndquadrant.com 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 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
On Tue, May 6, 2014 at 1:14 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-05-06 08:48:57 -0400, Robert Haas wrote:
On Tue, May 6, 2014 at 8:43 AM, Andres Freund and...@2ndquadrant.com wrote:
The break because of refcnt == 1 doesn't generally seem to be a good
idea. Why are we
On 2014-05-06 13:45:13 -0400, Robert Haas wrote:
On Tue, May 6, 2014 at 1:14 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-05-06 08:48:57 -0400, Robert Haas wrote:
On Tue, May 6, 2014 at 8:43 AM, Andres Freund and...@2ndquadrant.com
wrote:
The break because of refcnt == 1
On Tue, May 6, 2014 at 12:26 PM, Michael Renner
michael.ren...@amd.co.at 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:
On Tue, May 6, 2014 at 1:46 PM, Andres Freund and...@2ndquadrant.com 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:
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
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,
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 t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
Andres Freund and...@2ndquadrant.com 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
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
* 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 lot of
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?
It
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 \
postgres with options
Bruce Momjian br...@momjian.us 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
Kevin Grittner kgri...@ymail.com writes:
Bruce Momjian br...@momjian.us 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 11:31 AM, Tom Lane t...@sss.pgh.pa.us 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:
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
On Tue, May 6, 2014 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Bruce Momjian br...@momjian.us 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
On Tue, May 6, 2014 at 12:38:41PM -0700, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Bruce Momjian br...@momjian.us wrote:
pgindent run for 9.4
The 13 tests above are broken by this commit. Probably the
directory should be
On Tue, May 6, 2014 at 7:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Tue, May 6, 2014 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us 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
Bruce Momjian br...@momjian.us wrote:
On Tue, May 6, 2014 at 12:38:41PM -0700, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Bruce Momjian br...@momjian.us wrote:
pgindent run for 9.4
The 13 tests above are broken by this commit.
On May 6, 2014 9:30:15 PM CEST, Heikki Linnakangas hlinnakan...@vmware.com
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
Kevin Grittner kgri...@ymail.com 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.
Kevin Grittner kgri...@ymail.com writes:
Bruce Momjian br...@momjian.us 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
On Tue, May 6, 2014 at 03:54:24PM -0400, Tom Lane wrote:
Kevin Grittner kgri...@ymail.com writes:
Bruce Momjian br...@momjian.us 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
On Tue, Apr 22, 2014 at 08:50:20PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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/x86 platforms?
On Tue, May 6, 2014 at 09:48:04PM +0200, Andres Freund wrote:
On May 6, 2014 9:30:15 PM CEST, Heikki Linnakangas hlinnakan...@vmware.com
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
On Tue, May 6, 2014 at 1:06 PM, Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us writes:
On Tue, Apr 22, 2014 at 08:50:20PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Tomas Vondra t...@fuzzy.cz 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
On Tue, May 6, 2014 at 12:48 PM, Andres Freund and...@anarazel.de 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
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 6 May 2014 18:08, Josh Berkus j...@agliodbs.com wrote:
On 05/06/2014 08:41 AM, Simon Riggs wrote:
On 6 May 2014 15:18, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Lets fix e_c_s at 25% of shared_buffers and remove the parameter
completely, just as we do
On 6 May 2014 20:41, Jeff Janes jeff.ja...@gmail.com 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
On 6.5.2014 22:24, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz 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:
On 6 May 2014 20:44, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, May 6, 2014 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us 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
Bruce Momjian br...@momjian.us 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
On Tue, May 6, 2014 at 05:05:00PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Tue, May 6, 2014 at 04:18:50PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Tue, Apr 22, 2014 at 08:50:20PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Where are we on the default JSONB opclass change?
Not sure. I'm for changing it, I think,
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
1 - 100 of 141 matches
Mail list logo
