On Mon, May 5, 2014 at 3:40 PM, Heikki Linnakangas
wrote:
> On 05/04/2014 11:13 PM, Magnus Hagander wrote:
>>
>> On Sun, May 4, 2014 at 9:35 PM, Josh Berkus wrote:
>>
Architecture wise there's no coverage for:
* some ARM architecture varians
>>>
>>>
>>> I could run a buildfarm animal on
Let me bring the bug fix again to the surface. Is anybody looking at this
fix?
On Tue, Apr 29, 2014 at 2:25 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Hi,
> When array of char * is used as target for the FETCH statement returning
> more than one row, it tries to store all the
Hi,
On 2014-05-04 12:35:44 -0700, Josh Berkus wrote:
> > There's pretty little coverage of non mainstream platforms/compilers in
> > the buildfarm atm. Maybe we should send an email on -announce asking for
> > new ones?
> > There's no coverage for OS-wise;
> > * AIX (at all)
> > * HP-UX (for maste
Hi
When running more than one cluster I often find myself looking at
the output of 'iotop' or other tools wondering which
cluster's "wal receiver process" or "checkpointer process" etc
I'm seeing. Obviously it's easy enough to find out (for example
by looking at a tree view in htop/ps that shows
Hi,
While investigating an issue pointed out by valgrind around undefined
bytes in inval.c SHAREDINVALSMGR_ID processing I noticed that there's a
bug in ReceiveSharedInvalidMessages(). It tries to be safe against
recursion but it's not:
When it recurses into ReceiveSharedInvalidMessages() from it'
Hi,
On 2014-05-05 10:00:34 +, Thomas Munro wrote:
> When running more than one cluster I often find myself looking at
> the output of 'iotop' or other tools wondering which
> cluster's "wal receiver process" or "checkpointer process" etc
> I'm seeing.
I wonder about that pretty regularly. To
On 04/14/2014 09:48 PM, Heikki Linnakangas wrote:
On 04/14/2014 07:51 PM, Tom Lane wrote:
I'd prefer to leave the prepare sequence alone and instead find a way
to reject COMMIT PREPARED until after the source transaction is safely
clear of the race conditions. The upthread idea of looking at vx
On 5 May 2014 10:10, Andres Freund wrote:
> Hi,
>
> On 2014-05-05 10:00:34 +, Thomas Munro wrote:
> > When running more than one cluster I often find myself looking at
> > the output of 'iotop' or other tools wondering which
> > cluster's "wal receiver process" or "checkpointer process" etc
>
On 05/05/2014 06:00 PM, Thomas Munro wrote:
> Hi
>
> When running more than one cluster I often find myself looking at
> the output of 'iotop' or other tools wondering which
> cluster's "wal receiver process" or "checkpointer process" etc
> I'm seeing. Obviously it's easy enough to find out (for
On 2014-05-05 10:49:19 +, Thomas Munro wrote:
> On 5 May 2014 10:10, Andres Freund wrote:
>
> > Hi,
> >
> > On 2014-05-05 10:00:34 +, Thomas Munro wrote:
> > > When running more than one cluster I often find myself looking at
> > > the output of 'iotop' or other tools wondering which
> >
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-05-05 10:00:34 +, Thomas Munro wrote:
> > When running more than one cluster I often find myself looking at
> > the output of 'iotop' or other tools wondering which
> > cluster's "wal receiver process" or "checkpointer process" etc
> > I
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> postgres[5433]: checkpointer process
>
> at least as useful. The only time that's not unique is in a BSD jail or
> lxc container, and in those cases IIRC ps can show you the
> jail/container anyway.
Uhh, that's not at all true. You can tr
On 2014-05-05 07:58:30 -0400, Stephen Frost wrote:
> > I guess the question is where this should be available as well. At the
> > very least I'd want to reference it in log_line_prefix as well?
>
> I'm not entirely sure that I see the point of having it in
> log_line_prefix- each cluster logs to i
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-05-05 07:58:30 -0400, Stephen Frost wrote:
> > > I guess the question is where this should be available as well. At the
> > > very least I'd want to reference it in log_line_prefix as well?
> >
> > I'm not entirely sure that I see the point
On 5 May 2014 10:49, Thomas Munro wrote:
> On 5 May 2014 10:10, Andres Freund wrote:
>
>> I guess the question is where this should be available as well. At the
>> very least I'd want to reference it in log_line_prefix as well?
>>
>
> Good idea, I will look into that.
>
See v2 patch attached wh
On 05/01/2014 07:55 AM, Amit Kapila wrote:
On Wed, Apr 30, 2014 at 4:01 PM, Heikki Linnakangas
wrote:
I committed the non-invasive fixes to backbranches (and master too, just to
keep it in sync), but the attached is what I came up with for master.
There are a couple of places in the code where
Hi,
apparently a few users were puzzled that archive_command is ignored on slave
servers, which comes as a surprise since streaming replication will work fine
from slaves and as far as I’ve checked the documentation also doesn’t point out
the fact that archive_command gets a different treatment
On Sun, May 4, 2014 at 03:49:27PM +0200, Andres Freund wrote:
> Hi,
>
> On 2014-05-04 08:46:07 -0400, Bruce Momjian wrote:
> > Feedback expected and welcomed. I expect to be modifying this until we
> > release 9.4 final. I have marked items where I need help with question
> > marks.
>
> Thanks
On Sun, May 4, 2014 at 06:06:52PM +0400, Oleg Bartunov wrote:
> Bruce,
>
> you forgot Alexander Korotkov, who contributed jsonb_hash_ops opclass
> for GIN. Something like
> "Alexander Korotkov introduced an elegant jsonb_hash ops for GIN,
> which competes with MongoDB performance in contains ope
On 04/30/2014 06:39 PM, Andres Freund wrote:
Hi,
Coverity flagged a couple of issues that seem to worth addressing by
changing the code instead of ignoring them:
01) heap_xlog_update() looks to coverity as if it could trigger a NULL
pointer dereference. That's because it thinks that oldtup
On 05/05/2014 04:19 PM, Michael Renner wrote:
Hi,
apparently a few users were puzzled that archive_command is ignored
on slave servers, which comes as a surprise since streaming
replication will work fine from slaves and as far as I’ve checked the
documentation also doesn’t point out the fact th
On Sun, May 4, 2014 at 10:24:54AM -0400, Andrew Dunstan wrote:
>
> On 05/04/2014 10:12 AM, Petr Jelinek wrote:
> >On 04/05/14 14:46, Bruce Momjian wrote:
> >>I have completed the initial version of the 9.4 release notes. You can
> >>view them here:
> >>
> >>http://www.postgresql.org/docs/dev
On Mon, May 5, 2014 at 09:10:11AM +0300, Heikki Linnakangas wrote:
> On 05/04/2014 03:46 PM, Bruce Momjian wrote:
> >I have completed the initial version of the 9.4 release notes.
>
> Thanks!
>
> >You can view them here:
> >
> > http://www.postgresql.org/docs/devel/static/release-9-4.html
>
On Mon, May 5, 2014 at 09:23:15AM +0300, Heikki Linnakangas wrote:
> On 05/04/2014 03:46 PM, Bruce Momjian wrote:
> >Auto-resize the catalog cache (Heikki Linnakangas)
> >
> >This reduces memory consumption for backends accessing only a few
> >tables, and improves performance for backend accessing
--On 3. Mai 2014 10:11:33 +0200 Andres Freund
wrote:
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
new file mode 100644
index 6d26ffc..dec3d4a
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
*** psql_completion(const char *text, int s
Andres Freund writes:
> On 2014-05-05 10:49:19 +, Thomas Munro wrote:
>> Hah -- I agree, but on systems using setproctitle, the program name and ":
>> " are provided already, so the end result would have to be different on
>> those systems and I figured it should be the same everywhere if poss
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> How about dropping the brackets, and the cluster-name concept, and
> just doing
>
> postgres: 5432 checkpointer process
-1 for my part, as I'd just end up with a bunch of those and no
distinction between the various processes. In other words, without
On Wed, Apr 30, 2014 at 4:10 AM, Etsuro Fujita
wrote:
> (2014/04/28 23:31), Robert Haas wrote:
>> On Thu, Apr 24, 2014 at 7:59 AM, Etsuro Fujita
>> wrote:
>>>
>>> The patch attached improves docs in fdwhandler.sgml a little bit.
>>
>>
>> When you submit a patch, it's helpful to describe what the
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> How about dropping the brackets, and the cluster-name concept, and
>> just doing
>>
>> postgres: 5432 checkpointer process
> -1 for my part, as I'd just end up with a bunch of those and no
> distinction between the various process
On Sun, May 4, 2014 at 08:46:07AM -0400, Bruce Momjian wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedb
Bruce Momjian wrote:
> On Sun, May 4, 2014 at 03:49:27PM +0200, Andres Freund wrote:
> > +
> > +
> > +Add huge_pages configuration parameter to attempt to use huge
> > translation look-aside buffer (TLB) pages on Linux (Christian Kruse,
> > +Richard Poole, Abhijit Me
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Including the value of listen_addresses along w/ the port would make it
> > useful. If we really don't want the cluster-name concept (which,
> > personally, I like quite a bit), how about including the listen_address
> > value if
On Mon, May 5, 2014 at 10:18:44AM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Sun, May 4, 2014 at 03:49:27PM +0200, Andres Freund wrote:
>
> > > +
> > > +
> > > +Add huge_pages configuration parameter to attempt to use huge
> > > translation look-aside buffer
On Sat, May 3, 2014 at 5:48 AM, Marko Tiikkaja wrote:
> On 5/2/14, 10:10 PM, Merlin Moncure wrote:
>>
>> On Fri, May 2, 2014 at 3:03 PM, Tom Lane wrote:
>>>
>>> Meh. Then you could have a query that works fine until you add a column
>>> to the table, and it stops working. If nobody ever used co
2014-05-05 17:02 GMT+02:00 Merlin Moncure :
> On Sat, May 3, 2014 at 5:48 AM, Marko Tiikkaja wrote:
> > On 5/2/14, 10:10 PM, Merlin Moncure wrote:
> >>
> >> On Fri, May 2, 2014 at 3:03 PM, Tom Lane wrote:
> >>>
> >>> Meh. Then you could have a query that works fine until you add a
> column
> >>
On 05/05/2014 09:38 AM, Bruce Momjian wrote:
On Sun, May 4, 2014 at 10:24:54AM -0400, Andrew Dunstan wrote:
On 05/04/2014 10:12 AM, Petr Jelinek wrote:
On 04/05/14 14:46, Bruce Momjian wrote:
I have completed the initial version of the 9.4 release notes. You can
view them here:
http://
On 05/05/2014 11:20 AM, Pavel Stehule wrote:
How about:
UPDATE foo SET (foo).* = (1,2,3);
It is looking little bit strange
I like previous proposal UPDATE foo SET foo = (1,2,3);
What if the table has a field called foo? Won't it then be ambiguous?
cheers
andrew
--
Sent via p
On Mon, May 5, 2014 at 10:32 AM, Andrew Dunstan wrote:
>
> On 05/05/2014 11:20 AM, Pavel Stehule wrote:
>>
>>
>>
>>
>> How about:
>> UPDATE foo SET (foo).* = (1,2,3);
>>
>>
>> It is looking little bit strange
>>
>> I like previous proposal UPDATE foo SET foo = (1,2,3);
>>
>
> What if the t
Merlin Moncure-2 wrote
> On Sat, May 3, 2014 at 5:48 AM, Marko Tiikkaja <
> marko@
> > wrote:
>> On 5/2/14, 10:10 PM, Merlin Moncure wrote:
>>>
>>> On Fri, May 2, 2014 at 3:03 PM, Tom Lane <
> tgl@.pa
> > wrote:
Meh. Then you could have a query that works fine until you add a
co
On 2014-05-05 09:52:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> >>> Aren't you potentially dereferencing a NULL pointer here?
>
> >> Hmm -- I thought the GUC machinery would make sure cluster_name either
> >> pointed to the default I provided, an empty string, or a string read from
> >> t
On 2014-05-05 08:03:04 -0400, Stephen Frost wrote:
> Craig,
>
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
> > postgres[5433]: checkpointer process
> >
> > at least as useful. The only time that's not unique is in a BSD jail or
> > lxc container, and in those cases IIRC ps can show you the
>
On 2014-05-05 10:07:46 -0400, Tom Lane wrote:
> Stephen Frost writes:
> > Including the value of listen_addresses along w/ the port would make it
> > useful. If we really don't want the cluster-name concept (which,
> > personally, I like quite a bit), how about including the listen_address
> > va
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-05-05 08:03:04 -0400, Stephen Frost wrote:
> > Uhh, that's not at all true. You can trivially have multiple IPs on a
> > box w/o jails or containers (aliased interfaces) and then run PG on the
> > default port- which I find to be *far* more
On Mon, May 5, 2014 at 11:28:21AM -0400, Andrew Dunstan wrote:
> No, I think you're missing the point of what I'm saying, and I think
> the addition is at best misleading. I would avoid talk of key value
> pairs, anyway, that's not all that's in a json document (it might be
> an array, for example
On Sat, May 3, 2014 at 1:11 AM, Andres Freund wrote:
> On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
> > On Friday, May 2, 2014, Jeff Janes wrote:
> >
> > > I've been working with an app that uses a schema name whose spelling is
> > > hard to type, and the lack of tab completion for "SET search
Hi,
Walsender does a PQClear(con) but then accesses data acquired with
PQgetvalue(). That's clearly not ok.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
>From 1b7df22ff6da40ad4fcfa4eeacc182
Andres Freund writes:
> On 2014-05-05 10:07:46 -0400, Tom Lane wrote:
>> Also, -1 for adding another log_line_prefix escape. If you're routing
>> multiple clusters logging to the same place (which is already a bit
>> unlikely IMO), you can put distinguishing strings in log_line_prefix
>> already.
On 5/2/14, 8:57 PM, Tom Lane wrote:
Jim Nasby writes:
ISTM it’d be a lot better if it treated NULL flags the same as ‘’...
In Oracle's universe that probably makes sense, but to me it's not
sensible. Why should "unknown" flags produce a non-unknown result?
Only because they're more options
On 05/03/2014 01:07 AM, Andres Freund wrote:
> On 2014-05-02 18:57:08 -0700, Josh Berkus wrote:
>> Just got a report of a replication issue with 9.2.8 from a community member:
>>
>> Here's the sequence:
>>
>> 1) A --> B (sync rep)
>>
>> 2) Shut down B
>>
>> 3) Shut down A
>>
>> 4) Start up B as a m
On 2014-05-05 13:07:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-05 10:07:46 -0400, Tom Lane wrote:
> >> Also, -1 for adding another log_line_prefix escape. If you're routing
> >> multiple clusters logging to the same place (which is already a bit
> >> unlikely IMO), you can p
All,
I'm working with the cstore_fdw project, which has an interesting
property for an FDW: the FDW itself creates the files which make up the
database. This raises a couple of questions:
1) Do we want to establish a standard directory for FDWs which create
files, such as $PGDATA/base/{database
On 05/05/2014 10:25 AM, Andres Freund wrote:
> On 2014-05-05 10:16:27 -0700, Josh Berkus wrote:
>> On 05/03/2014 01:07 AM, Andres Freund wrote:
>>> On 2014-05-02 18:57:08 -0700, Josh Berkus wrote:
Just got a report of a replication issue with 9.2.8 from a community
member:
Here
Seems there is no documentation for the 9.4 worker_spi contrib module. Is
this OK? The comment at the top of the C file says:
* Sample background worker code that demonstrates various coding
* patterns: establishing a database connection; starting and committing
* transactions;
On 2014-05-05 10:16:27 -0700, Josh Berkus wrote:
> On 05/03/2014 01:07 AM, Andres Freund wrote:
> > On 2014-05-02 18:57:08 -0700, Josh Berkus wrote:
> >> Just got a report of a replication issue with 9.2.8 from a community
> >> member:
> >>
> >> Here's the sequence:
> >>
> >> 1) A --> B (sync rep)
On 05/04/2014 05:46 AM, Bruce Momjian wrote:
> I have completed the initial version of the 9.4 release notes. You can
> view them here:
>
> http://www.postgresql.org/docs/devel/static/release-9-4.html
>
> I will be adding additional markup in the next few days.
>
> Feedback expected and w
On Mon, May 5, 2014 at 10:40:29AM -0700, Josh Berkus wrote:
> On 05/04/2014 05:46 AM, Bruce Momjian wrote:
> > I have completed the initial version of the 9.4 release notes. You can
> > view them here:
> >
> > http://www.postgresql.org/docs/devel/static/release-9-4.html
> >
> > I will be ad
On Mon, May 5, 2014 at 2:26 PM, Josh Berkus wrote:
>
> All,
>
> I'm working with the cstore_fdw project, which has an interesting
> property for an FDW: the FDW itself creates the files which make up the
> database. This raises a couple of questions:
>
> 1) Do we want to establish a standard dir
Hi,
Today, I discovered that when building a btree index, the btree code
uses index_form_tuple() to create an index tuple from the heap tuple,
calls tuplesort_putindextuple() to copy that tuple into the sort's
memory context, and then frees the original one it built. This seemed
inefficient, so I
Josh Berkus writes:
> I'm working with the cstore_fdw project, which has an interesting
> property for an FDW: the FDW itself creates the files which make up the
> database. This raises a couple of questions:
> 1) Do we want to establish a standard directory for FDWs which create
> files, such
On 2014-05-05 10:30:17 -0700, Josh Berkus wrote:
> On 05/05/2014 10:25 AM, Andres Freund wrote:
> > On 2014-05-05 10:16:27 -0700, Josh Berkus wrote:
> >> On 05/03/2014 01:07 AM, Andres Freund wrote:
> >>> On 2014-05-02 18:57:08 -0700, Josh Berkus wrote:
> Just got a report of a replication iss
On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan wrote:
> How about:
>
>This data type allows for faster access to values in the json document
> and faster and more useful indexing of json.
We should refer to the fact that jsonb is internally typed. This isn't
all that obvious now, but it is ev
Hi,
On 2014-05-05 13:52:39 -0400, Robert Haas wrote:
> Today, I discovered that when building a btree index, the btree code
> uses index_form_tuple() to create an index tuple from the heap tuple,
> calls tuplesort_putindextuple() to copy that tuple into the sort's
> memory context, and then frees
Andres Freund writes:
> While investigating an issue pointed out by valgrind around undefined
> bytes in inval.c SHAREDINVALSMGR_ID processing I noticed that there's a
> bug in ReceiveSharedInvalidMessages(). It tries to be safe against
> recursion but it's not:
> When it recurses into ReceiveShar
On 05/05/2014 10:53 AM, Tom Lane wrote:
> Josh Berkus writes:
>> I'm working with the cstore_fdw project, which has an interesting
>> property for an FDW: the FDW itself creates the files which make up the
>> database. This raises a couple of questions:
>
>> 1) Do we want to establish a standar
On Mon, May 5, 2014 at 8:17 PM, Josh Berkus wrote:
> On 05/05/2014 10:53 AM, Tom Lane wrote:
> > Josh Berkus writes:
> >> I'm working with the cstore_fdw project, which has an interesting
> >> property for an FDW: the FDW itself creates the files which make up the
> >> database. This raises a
On 2014-05-05 11:17:18 -0700, Josh Berkus wrote:
> On 05/05/2014 10:53 AM, Tom Lane wrote:
> > Josh Berkus writes:
> >> I'm working with the cstore_fdw project, which has an interesting
> >> property for an FDW: the FDW itself creates the files which make up the
> >> database. This raises a coup
On Mon, May 5, 2014 at 10:58:57AM -0700, Peter Geoghegan wrote:
> On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan wrote:
> > How about:
> >
> >This data type allows for faster access to values in the json document
> > and faster and more useful indexing of json.
>
> We should refer to the fac
On 05/05/2014 11:31 AM, Bruce Momjian wrote:
> JSONB values are also mapped to SQL scalar data types, rather
> than being treated always as strings.
+ ... allowing for correct sorting of JSON according to internal datums.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Se
On Mon, May 5, 2014 at 2:13 PM, Andres Freund wrote:
> On 2014-05-05 13:52:39 -0400, Robert Haas wrote:
>> Today, I discovered that when building a btree index, the btree code
>> uses index_form_tuple() to create an index tuple from the heap tuple,
>> calls tuplesort_putindextuple() to copy that t
On 05/05/2014 10:53 AM, Andres Freund wrote:
> Still a user error. You need to reclone.
>
> Depending on how archiving and the target timeline was configured the
> timeline increase won't be treated as an error...
Andres and I hashed this out on IRC. The basic problem was that I was
relying on p
Josh Berkus writes:
> On 05/05/2014 10:53 AM, 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 integrit
On Mon, May 5, 2014 at 11:31 AM, Bruce Momjian wrote:
> JSONB values are also mapped to SQL scalar data types, rather
> than being treated always as strings.
Something like that. Perhaps you should just go with what the
documentation says: "Primitive JSON types described by RFC 7159 are
e
On Sun, May 4, 2014 at 7:50 AM, Andres Freund wrote:
> On 2014-05-04 13:44:17 +0200, Andres Freund wrote:
>> postgres=# SELECT * FROM pg_shmem_allocations ORDER BY size DESC;
>> key | off |size | allocated
>> -+--
Robert Haas writes:
> On Sun, May 4, 2014 at 7:50 AM, Andres Freund wrote:
>> Thinking about this, I think it was a mistake to not add a 'name' field
>> to dynamic shared memory's dsm_control_item.
> Well, right now a dsm_control_item is 8 bytes. If we add a name field
> of our usual 64 bytes,
On 2014-05-05 15:04:07 -0400, Robert Haas wrote:
> On Sun, May 4, 2014 at 7:50 AM, Andres Freund wrote:
> > On 2014-05-04 13:44:17 +0200, Andres Freund wrote:
> >> postgres=# SELECT * FROM pg_shmem_allocations ORDER BY size DESC;
> >> key | off |size
On 2014-05-05 15:09:02 -0400, Tom Lane wrote:
> > I'm quite in favor of having something like this for the main shared
> > memory segment, but I think that's 9.5 material at this point.
>
> If you're prepared to break the current APIs later to add a name parameter
> (which would have to be require
On 2014-05-05 14:15:58 -0400, Tom Lane wrote:
> Andres Freund writes:
> > While investigating an issue pointed out by valgrind around undefined
> > bytes in inval.c SHAREDINVALSMGR_ID processing I noticed that there's a
> > bug in ReceiveSharedInvalidMessages(). It tries to be safe against
> > rec
Andres Freund writes:
> a) SICleanupQueue() sometimes releases and reacquires the write lock
>held on the outside. That's pretty damn fragile, not to mention
>ugly. Even slight reformulations of the code in SIInsertDataEntries()
>can break this... Can we please extend the comment in th
Hi,
We really should fix this one of these days.
On 2014-03-26 18:45:54 -0700, Peter Geoghegan wrote:
> Attached patch silences the "Invalid read of size n" complaints of
> Valgrind. I agree with your general thoughts around backpatching. Note
> that the patch addresses a distinct complaint from
Prior to default parameters on functions, GRANT and COMMENT accepted full
parameter syntax. IE:
GRANT EXECUTE ON test(t text) TO public
as opposed to regprocedure, which only accepts the data types ( test(text), not
test(t text) ).
They do not accept DEFAULT though:
GRANT EXECUTE ON FUNCTION
On Mon, May 5, 2014 at 1:13 PM, Andrew Dunstan wrote:
> The fact that jsonb maps scalar values to internal postgres types is an
> implementation artefact.
I wouldn't go that far, but I take your point. The fact that the
primitive/scalar JSON types are in a very real sense strongly typed is
a very
On 05/05/2014 02:33 PM, Josh Berkus wrote:
On 05/05/2014 11:31 AM, Bruce Momjian wrote:
JSONB values are also mapped to SQL scalar data types, rather
than being treated always as strings.
+ ... allowing for correct sorting of JSON according to internal datums.
The problem is that a
Jim Nasby wrote:
> Prior to default parameters on functions, GRANT and COMMENT accepted full
> parameter syntax. IE:
>
> GRANT EXECUTE ON test(t text) TO public
>
> as opposed to regprocedure, which only accepts the data types ( test(text),
> not test(t text) ).
>
> They do not accept DEFAULT
On 2014-05-05 15:41:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > a) SICleanupQueue() sometimes releases and reacquires the write lock
> >held on the outside. That's pretty damn fragile, not to mention
> >ugly. Even slight reformulations of the code in SIInsertDataEntries()
> >
On Mon, May 5, 2014 at 10:40:29AM -0700, Josh Berkus wrote:
> Major enhancement list:
>
> Per discussion on the -advocacy list, the features we've picked out as
> "major enhancements" for advocacy reasons this round are:
>
> * Materialized Views (because with refresh concurrently, MatViews are
>
On 05/05/2014 11:53 AM, Tom Lane wrote:
> Sure. They should all keep them outside $PGDATA, making it not-our-
> problem. When and if we're prepared to consider it our problem, we
> will be sure to advise people.
OK.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgs
On Mon, May 5, 2014 at 3:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 4, 2014 at 7:50 AM, Andres Freund wrote:
>>> Thinking about this, I think it was a mistake to not add a 'name' field
>>> to dynamic shared memory's dsm_control_item.
>
>> Well, right now a dsm_control_item is 8
On Sun, May 4, 2014 at 6:49 AM, Andres Freund wrote:
> +
> +
> +Have pg_stat_statements use a flat file for query text storage,
> allowing higher limits (Peter Geoghegan)
> +
> +
> +
> +Also add the ability to retrieve all pg_stat_statements information
While stress testing the crash-recovery system, I keep running into
wraparound shutdowns that I think should not be occurring. I go out of my
way give autovac a chance to complete every now and then, more often than
it should need to in order to keep up with the xid usage.
I think the problem tra
Andres Freund writes:
> On 2014-05-05 15:41:22 -0400, Tom Lane wrote:
>> Looks all right to me. Yeah, the right shift might have undefined
>> high-order bits, but we don't care because we're storing the result
>> into an int16.
> Doesn't at the very least
> rnode.backend = (msg->sm
Robert Haas writes:
> On Mon, May 5, 2014 at 3:09 PM, Tom Lane wrote:
>> And the controlled shared segment is likely to be how big exactly? It's
>> probably not even possible for it to be smaller than a page size, 4K or
>> so depending on the OS. I agree with Andres that a name would be a good
On 5 May 2014 17:22, Andres Freund wrote:
> On 2014-05-05 13:07:48 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2014-05-05 10:07:46 -0400, Tom Lane wrote:
> > >> Also, -1 for adding another log_line_prefix escape. If you're routing
> > >> multiple clusters logging to the same place
On Mon, May 5, 2014 at 02:23:13PM -0700, Peter Geoghegan wrote:
> On Sun, May 4, 2014 at 6:49 AM, Andres Freund wrote:
> > +
> > +
> > +Have pg_stat_statements use a flat file for query text storage,
> > allowing higher limits (Peter Geoghegan)
> > +
> > +
> > +
On Mon, May 5, 2014 at 10:58:57AM -0700, Peter Geoghegan wrote:
> On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan wrote:
> > How about:
> >
> >This data type allows for faster access to values in the json document
> > and faster and more useful indexing of json.
>
> We should refer to the fac
On Mon, May 5, 2014 at 4:14 PM, Bruce Momjian wrote:
> We rarely get into specific numers like this. It says "higher limit(s)" and
> hopefully that is enough. If you want to create a documentation 'id' I
> can like to that for the "higher limits" text.
You don't have to mention a number. Just t
On Mon, May 5, 2014 at 4:16 PM, Bruce Momjian wrote:
> This allows for faster access to values in the JSON document and
> faster
> and more useful indexing of JSON. JSONB values are also typed as
> appropriate scalar SQL types.
>
> Is that OK?
That seems reasonable.
--
On 05/05/2014 07:16 PM, Bruce Momjian wrote:
On Mon, May 5, 2014 at 10:58:57AM -0700, Peter Geoghegan wrote:
On Mon, May 5, 2014 at 8:28 AM, Andrew Dunstan wrote:
How about:
This data type allows for faster access to values in the json document
and faster and more useful indexing of jso
On Mon, May 5, 2014 at 4:26 PM, Andrew Dunstan wrote:
> After all, everything that's not a number or boolean is typed as text (just
> as it is in JSON). We don't, for example, map anything to timestamp types.
JSON doesn't have a timestamp primitive type. Of those types that it
has, their internal
On 05/05/2014 07:34 PM, Peter Geoghegan wrote:
On Mon, May 5, 2014 at 4:26 PM, Andrew Dunstan wrote:
After all, everything that's not a number or boolean is typed as text (just
as it is in JSON). We don't, for example, map anything to timestamp types.
JSON doesn't have a timestamp primitive t
On Mon, May 5, 2014 at 04:20:26PM -0700, Peter Geoghegan wrote:
> On Mon, May 5, 2014 at 4:14 PM, Bruce Momjian wrote:
> > We rarely get into specific numers like this. It says "higher limit(s)" and
> > hopefully that is enough. If you want to create a documentation 'id' I
> > can like to that
1 - 100 of 110 matches
Mail list logo
