On Fri, May 9, 2014 at 10:49 PM, Fujii Masao wrote:
> On Fri, May 9, 2014 at 10:03 PM, Andres Freund wrote:
>> You plan to commit it?
>
> Yes unless many people object the commit.
>
> Michael, you're now modifying the patch?
OK, I have been able to put my head into that earlier than I thought
as
On Thu, May 8, 2014 at 4:47 PM, MauMau wrote:
> I rebased the patch to HEAD and removed the compilation error on Linux. I
> made event_source variable on all platforms like register_servicename,
> although they are not necessary on non-Windows platforms.
I have verified that current patch is fin
On Fri, May 09, 2014 at 04:58:54PM +0200, Andres Freund wrote:
> On 2014-05-09 10:49:09 -0400, Robert Haas wrote:
> > > Patch 03: Add valgrind suppression for writing out padding bytes. That's
> > > better than zeroing the data from the get go because unitialized
> > > accesses are still detected.
On Fri, May 9, 2014 at 7:01 PM, Fujii Masao wrote:
> On Fri, May 9, 2014 at 1:06 PM, Amit Kapila wrote:
>> There is no harm in forbidding data_directory, but similarly we can
>> imagine that people can set some very large values for some config
>> variables due to which later it can have symptoms
Em sexta-feira, 9 de maio de 2014, Peter Eisentraut
escreveu:
> Wouldn't a better name be recovery_min_apply_delay?
>
>
+1
The original name was recovery_apply_delay but in some point of review it
was changed to reflect better the limit.
> Other parameters are usually named something_min_somet
Wouldn't a better name be recovery_min_apply_delay?
Other parameters are usually named something_min_something.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The pg_basebackup documentation says that only regular files and
directories are "allowed" in the data directory. But it is more correct
that any other files are skipped. Attached is a patch to correct that.
I also added a link to the protocol documentation and added more
details there, also abo
On Fri, May 9, 2014 at 9:30 PM, Tom Lane wrote:
>
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > On Fri, May 9, 2014 at 8:42 PM, Tom Lane wrote:
> >> I think it's really too late for this for 9.4. At this point it's
> >> less than 48 hours until beta1 wraps, and we do not have the bandw
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> On Fri, May 9, 2014 at 8:42 PM, Tom Lane wrote:
>> I think it's really too late for this for 9.4. At this point it's
>> less than 48 hours until beta1 wraps, and we do not have the bandwidth
>> to do anything but worry about stabilizing the feat
On 9.5.2014 00:47, Tomas Vondra wrote:
> On 8.5.2014 23:48, Andrew Dunstan wrote:
>>
>> On 05/08/2014 05:21 PM, Alvaro Herrera wrote:
>>> Andrew Dunstan wrote:
>>>
I really don't get what your objection to the setup is. And no, I
don't want them to run concurrently, I'd rather spread out
On Fri, May 9, 2014 at 8:42 PM, Tom Lane wrote:
>
> Michael Paquier writes:
> > On Fri, May 9, 2014 at 10:49 PM, Fujii Masao
wrote:
> >> Yes unless many people object the commit.
> >>
> >> Michael,
> >> You're now modifying the patch?
> > Not within a couple of days.
>
> I think it's really too
On Fri, May 9, 2014 at 10:18 AM, Andres Freund
wrote:
>
> On 2014-05-09 22:14:25 +0900, Michael Paquier wrote:
> > On Fri, May 9, 2014 at 10:01 PM, Fujii Masao
wrote:
> > > +DATA(insert OID = 3260 (403pglsn_opsPGNSP PGUID
));
> > > +DATA(insert OID = 3261 (405pglsn
Michael Paquier writes:
> On Fri, May 9, 2014 at 10:49 PM, Fujii Masao wrote:
>> Yes unless many people object the commit.
>>
>> Michael,
>> You're now modifying the patch?
> Not within a couple of days.
I think it's really too late for this for 9.4. At this point it's
less than 48 hours until
On Fri, May 9, 2014 at 10:49 PM, Fujii Masao wrote:
> Yes unless many people object the commit.
>
> Michael,
> You're now modifying the patch?
Not within a couple of days.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Josh Berkus writes:
> How can this be? We're bundling a beta in 2 days.
The remaining stuff in 2014-01 needs to get moved to 2014-06, I guess.
We're certainly not committing any of it at this point.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
How can this be? We're bundling a beta in 2 days.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Geoghegan writes:
> On Fri, May 9, 2014 at 2:54 PM, Tom Lane wrote:
>> However, what it looks to me like we've got here is a very bad
>> reimplementation of StringInfo buffers. There is for example no
>> integer-overflow checking here. Rather than try to bring this code
>> up to speed, I
On Fri, May 9, 2014 at 2:54 PM, Tom Lane wrote:
> However, what it looks to me like we've got here is a very bad
> reimplementation of StringInfo buffers. There is for example no
> integer-overflow checking here. Rather than try to bring this code
> up to speed, I think we should rip it out and
Alexander Korotkov writes:
> With current head I can't load delicious dataset into jsonb format. I got
> segfault. It looks like memory corruption.
The proximate cause of this seems to be that reserveFromBuffer() fails
to consider the possibility that it needs to more-than-double the
current buff
I wrote:
> It looks like hamster may have a repeatable issue there as well,
> since the last set of DSM code changes.
Ah, scratch that --- on closer inspection it looks like both failures
probably trace to out-of-disk-space.
regards, tom lane
--
Sent via pgsql-hackers m
Robert Haas writes:
> The test_shm_mq regression tests hung on this machine this morning.
It looks like hamster may have a repeatable issue there as well,
since the last set of DSM code changes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
Guillaume,
* Guillaume Lelarge (guilla...@lelarge.info) wrote:
> Should information_schema tables be moved and not pg_catalog ones? it
> doesn't seem consistent to me.
The catalog tables are moved by changing the database's tablespace, eg:
ALTER DATABASE ... SET TABLESPACE
That also moves any o
On May 9, 2014 10:37:49 PM CEST, Tom Lane wrote:
>Andres Freund writes:
>> That's nothing for 9.4 anymore, but shouldn't we make
>pg_class.relpages
>> a int8 (sounds slightly better than float to me) or somesuch?
>
>No; those are really BlockNumbers, and have always been. float4 would
>lose info
Greg Stark writes:
> Well the question seems to me to be that if we're always doing recheck
> then what advantage is there to not hashing everything?
Right now, there's not much. But it seems likely to me that there will be
more JSON operators in future, and some of them might be able to make us
On 9.5.2014 20:09, Andrew Dunstan wrote:
>
> I've done that a bit in the past. At one stage all my Windows animals
> were some sort of bat. There's nothing magical about the names. It's
> just a text field and can be whatever we like. I initially started with
> animals because it seemed like a cat
On 9.5.2014 17:18, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> So, if I get this right, the proposal is to have 7 animals:
>
> It's your machine, so you decide what you want. I'm only throwing
> out some ideas.
>
>> 1) all branches/locales, frequent builds (every few hours) magpie
>> - gcc
Andres Freund writes:
> That's nothing for 9.4 anymore, but shouldn't we make pg_class.relpages
> a int8 (sounds slightly better than float to me) or somesuch?
No; those are really BlockNumbers, and have always been. float4 would
lose information and float8 or int8 would waste space. If we had
Hey,
I was working on adding support to the new MOVE clause of the ALTER
TABLESPACE statement to pgAdmin when I noticed this issue. See this
example:
Fresh git compilation, and new database on a new cluster:
$ createdb b1
$ psql b1
psql (9.4devel)
Type "help" for help.
b1=# CREATE TABLESPACE ts
On Wed, May 7, 2014 at 1:40 PM, Heikki Linnakangas
wrote:
> On 05/07/2014 10:35 AM, Jeff Janes wrote:
>
>> When recovering from a crash (with injection of a partial page write at
>> time of crash) against 7c7b1f4ae5ea3b1b113682d4d I get a checksum
>> verification failure.
>>
>> 16396 is a gin inde
On Fri, May 9, 2014 at 10:27 AM, Alexander Korotkov
wrote:
> With current head I can't load delicious dataset into jsonb format. I got
> segfault. It looks like memory corruption.
I'll look at this within the next couple of hours.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pg
On 05/09/2014 11:25 AM, Robert Haas wrote:
On Fri, May 9, 2014 at 11:18 AM, Alvaro Herrera
wrote:
I guess it depends how likely we think that a different compiler will
change the behavior of the shared invalidation queue. Somebody else
would have to answer that. If not, then clearly we need
On Thu, May 8, 2014 at 10:44 PM, Amit Kapila wrote:
> On Thu, May 8, 2014 at 12:01 PM, Jaime Casanova wrote:
>> On Wed, May 7, 2014 at 10:52 PM, Amit Kapila wrote:
>>>
>>> Why to capture only for Index Insert/Update and not for Read; is it
>>> because Read will be always fast ot implementation c
On 04/26/2014 12:39 PM, Jim Nasby wrote:
> On 4/17/14, 6:42 PM, Josh Berkus wrote:
>> So we have some software we've been procrastinating on OSS'ing, which
>> does:
>>
>> 1) Takes full query CSV logs from a running postgres instance
>> 2) Runs them against a target instance in parallel
>> 3) Record
Hi,
postgres=# SELECT relpages FROM pg_class WHERE relname = 'large';
relpages
-
-1804468224
(1 row)
postgres=# \dt+ large
List of relations
Schema | Name | Type | Owner | Size | Description
+---+---++---+-
public | l
On Thu, May 8, 2014 at 11:45 AM, Heikki Linnakangas wrote:
> On 05/08/2014 02:25 AM, Peter Geoghegan wrote:
>
>> findJsonbValueFromSuperHeader()'s lowbound argument
>> previously served to establish a low bound for searching when
>> searching for multiple keys (so the second and subsequent
>> use
Robert Haas writes:
> That looks pretty good. However, I'm realizing this isn't the only
> place where we probably need to clarify the language. Just to take
> one example near at hand, PQputCopyData may also return 1 when it's
> only queued the data; it seems to try even less hard than PQputCo
On Thu, May 8, 2014 at 5:21 PM, Tom Lane wrote:
> Perhaps the text should be like this:
>
> The result is 1 if the termination message was sent; or in nonblocking
> mode, this may only indicate that the termination message was successfully
> queued. (In nonblocking mode, to be certain that the da
On Fri, May 9, 2014 at 11:32 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Fri, May 9, 2014 at 11:18 AM, Alvaro Herrera
>> wrote:
>> > I guess it depends how likely we think that a different compiler will
>> > change the behavior of the shared invalidation queue. Somebody else
>> > would
Andres Freund writes:
>> Anybody see other problems to fix here?
> Yea.
> 5)
> if (val_type > FirstNormalObjectId)
> isn't fundamentally incorrect but imo shouldn't be replaced by something
> like !IsCatalogType() (akin to IsCatalogRelation). At least if we decide
> that hunk is safe from ot
Andrew Dunstan writes:
> I guess this is my fault. I recall some discussions when some of this
> was first being written about the best way to make the type based
> decisions, not sure at this remove whether on list or off. The origin of
> it is in 9.2, so if you're going to adjust it you shoul
Robert Haas wrote:
> On Fri, May 9, 2014 at 11:18 AM, Alvaro Herrera
> wrote:
> > I guess it depends how likely we think that a different compiler will
> > change the behavior of the shared invalidation queue. Somebody else
> > would have to answer that. If not, then clearly we need only 5 anima
On 2014-05-09 10:07:10 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> b) datum_to_json() thinks it's a good idea to use typcategory to decide
> >> how a type is output. Isn't that pertty fundamentally flawed?
>
> > Indeed. I think the bit that uses TYPCATEGORY_NUMERIC as a hint
On Fri, May 9, 2014 at 11:18 AM, Alvaro Herrera
wrote:
> I guess it depends how likely we think that a different compiler will
> change the behavior of the shared invalidation queue. Somebody else
> would have to answer that. If not, then clearly we need only 5 animals.
This may be heresy, but
Tomas Vondra wrote:
> So, if I get this right, the proposal is to have 7 animals:
It's your machine, so you decide what you want. I'm only throwing out
some ideas.
> 1) all branches/locales, frequent builds (every few hours)
> magpie - gcc
> fulmar - icc
> treepie - clang
>
> 2) single
Hi,
On 2014-05-09 10:49:09 -0400, Robert Haas wrote:
> Committed.
Thanks.
> > Patch 03: Add valgrind suppression for writing out padding bytes. That's
> > better than zeroing the data from the get go because unitialized
> > accesses are still detected.
>
> I have no understanding of valgrind su
Hi,
I've attached a fair number of fixes for the current state of the
release notes. Many of them are fixing factual errors, others are more
minors.
I think the whole 'logical decoding' section will need an entire
rewrite, but I'll do that separately.
I've added a couple of for things that are c
On Thu, May 8, 2014 at 12:29 PM, Andres Freund wrote:
> Patch 01: Fix a couple of embarassing typos. Most of them harmless, but
> one isn't and can lead to crashing or decoding wrong data.
Committed.
> Patch 02: Don't crash with an Assert() failure if wal_level=logical but
> max_replication_slot
On 2014-05-09 10:26:48 -0400, Bruce Momjian wrote:
> On Fri, May 9, 2014 at 09:53:36AM -0400, Bruce Momjian wrote:
> > On Fri, May 9, 2014 at 07:04:17AM -0400, Tom Lane wrote:
> > > Gavin Flower writes:
> > > > On 09/05/14 15:34, Bruce Momjian wrote:
> > > >> Looks good. I was thinking the json
On 05/09/2014 10:07 AM, Tom Lane wrote:
After further reflection I think we should lose the TYPCATEGORY_NUMERIC
business too. ruleutils.c hard-wires the set of types it will consider
to be numeric, and I see no very good reason not to do likewise here.
That will remove the need to look up the t
On Fri, May 9, 2014 at 2:53 PM, Bruce Momjian wrote:
> Well, if we are optionally hashing json_ops for long strings, what does
> jsonb_hash_ops do uniquely with hashing? Does it always hash, while
> json_ops optionally hashes? Is that the distinguishing characteristic?
> It seemed the _content_
On Fri, May 9, 2014 at 09:53:36AM -0400, Bruce Momjian wrote:
> On Fri, May 9, 2014 at 07:04:17AM -0400, Tom Lane wrote:
> > Gavin Flower writes:
> > > On 09/05/14 15:34, Bruce Momjian wrote:
> > >> Looks good. I was thinking the jsonb_ops name could remain unchanged
> > >> and the jsonb_hash_o
On Thu, Mar 20, 2014 at 11:38 PM, Alvaro Herrera
wrote:
> Kyotaro HORIGUCHI escribió:
>> Hi, I confirmed that 82233ce7ea4 surely did it.
>>
>> At Wed, 19 Mar 2014 09:35:16 -0300, Alvaro Herrera wrote
>> > Fujii Masao escribió:
>> > > On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas
>> > > wrot
On Sat, May 3, 2014 at 4:31 AM, Dave Page wrote:
> Hamid@EDB; Can you please have someone configure anole to build git
> head as well as the other branches? Thanks.
The test_shm_mq regression tests hung on this machine this morning.
Hamid was able to give me access to log in and troubleshoot.
Unf
I wrote:
> Andres Freund writes:
>> b) datum_to_json() thinks it's a good idea to use typcategory to decide
>> how a type is output. Isn't that pertty fundamentally flawed?
> Indeed. I think the bit that uses TYPCATEGORY_NUMERIC as a hint to decide
> whether the value can be left unquoted (assum
On Fri, May 9, 2014 at 07:04:17AM -0400, Tom Lane wrote:
> Gavin Flower writes:
> > On 09/05/14 15:34, Bruce Momjian wrote:
> >> Looks good. I was thinking the jsonb_ops name could remain unchanged
> >> and the jsonb_hash_ops could be called jsonb_combo_ops as it combines
> >> the key and value
On Fri, May 9, 2014 at 10:03 PM, Andres Freund wrote:
> On 2014-05-09 22:01:07 +0900, Fujii Masao wrote:
>> On Wed, May 7, 2014 at 11:55 AM, Fabrízio de Royes Mello
>> wrote:
>> >
>> > On Tue, May 6, 2014 at 8:25 PM, Michael Paquier
>> > wrote:
>> >>
>> >> On Wed, May 7, 2014 at 8:22 AM, Andres
Andres Freund writes:
> Whoa. There's two wierd things here:
> a) "jsonb" has a typcategory 'C'. Marking a composite type. "json" has
>'U'.
Yeah, that's flat out wrong. I changed it before seeing your message.
> b) datum_to_json() thinks it's a good idea to use typcategory to decide
>ho
On Fri, May 9, 2014 at 1:06 PM, Amit Kapila wrote:
> On Thu, May 8, 2014 at 9:47 PM, Christoph Berg wrote:
>> Re: Andres Freund 2014-05-08 <20140508145901.gb1...@awork2.anarazel.de>
>>> > Maybe this is nitpicking, but what happens when postgresql.auto.conf also
>>> > includes the setting of data_
On 2014-05-09 22:14:25 +0900, Michael Paquier wrote:
> On Fri, May 9, 2014 at 10:01 PM, Fujii Masao wrote:
> > +DATA(insert OID = 3260 (403pglsn_opsPGNSP PGUID ));
> > +DATA(insert OID = 3261 (405pglsn_opsPGNSP PGUID ));
> >
> > The patch looks good to me ex
On Fri, May 9, 2014 at 10:01 PM, Fujii Masao wrote:
> +DATA(insert OID = 3260 (403pglsn_opsPGNSP PGUID ));
> +DATA(insert OID = 3261 (405pglsn_opsPGNSP PGUID ));
>
> The patch looks good to me except the name of index operator class.
> I think that "pg_lsn_o
Hi,
On 2014-05-09 21:40:07 +0900, Michael Paquier wrote:
> Hi all,
>
> I found the following error when playing with jsonb and json_build_object:
> =# with jsonb_data as (select * from jsonb_each('{"aa" :
> "po"}'::jsonb)) select json_build_object(key,value) from jsonb_data;
> ERROR: XX000: cach
Michael Paquier writes:
> I found the following error when playing with jsonb and json_build_object:
> =# with jsonb_data as (select * from jsonb_each('{"aa" :
> "po"}'::jsonb)) select json_build_object(key,value) from jsonb_data;
> ERROR: XX000: cache lookup failed for type 2147483650
> LOCATION
On 2014-05-09 22:01:07 +0900, Fujii Masao wrote:
> On Wed, May 7, 2014 at 11:55 AM, Fabrízio de Royes Mello
> wrote:
> >
> > 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:
> >> >
> >> >
On Wed, May 7, 2014 at 11:55 AM, Fabrízio de Royes Mello
wrote:
>
> 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 c
Hi all,
I found the following error when playing with jsonb and json_build_object:
=# with jsonb_data as (select * from jsonb_each('{"aa" :
"po"}'::jsonb)) select json_build_object(key,value) from jsonb_data;
ERROR: XX000: cache lookup failed for type 2147483650
LOCATION: lookup_type_cache, typc
Gavin Flower writes:
> On 09/05/14 15:34, Bruce Momjian wrote:
>> Looks good. I was thinking the jsonb_ops name could remain unchanged
>> and the jsonb_hash_ops could be called jsonb_combo_ops as it combines
>> the key and value into a single index entry.
> If you have 'jsonb_combo_ops' - then s
On 8 May 2014 01:00, Jaime Casanova wrote:
> Hi,
>
> This patch implements $subject only when ANALYZE and VERBOSE are on.
> I made it that way because for years nobody seemed interested in this
> info (at least no one did it) so i decided that maybe is to much
> information for most people (actua
67 matches
Mail list logo
