On Mon, Aug 17, 2015 at 12:06:42PM +0200, Andres Freund wrote:
> On 2015-08-16 03:31:48 -0400, Noah Misch wrote:
> I'd love to make it a #warning intead of an error, but unfortunately
> that's not standard C :(
Okay.
> > Other than that benefit, making headers #error-on-FRONTEND mostly lets
> > u
On Mon, Aug 17, 2015 at 02:04:40PM -0500, Jim Nasby wrote:
> On 8/16/15 8:48 AM, Greg Stark wrote:
> >On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch wrote:
> >>When I've just spent awhile implementing a behavior change, the test diffs
> >>are
> >>a comforting sight. They confirm that the test suite
Hi
2015-08-17 21:12 GMT+02:00 Jim Nasby :
> On 8/17/15 12:57 PM, Dmitry Dolgov wrote:
>
>> * is it interesting for the community?
>>
>
> We definitely need better ways to manipulate JSON.
>
> * is that a good idea to extend the `ArrayRef` for jsonb? If it's
>> appropriate, probably we can rename
On Tue, Aug 18, 2015 at 3:57 AM, Peter Geoghegan wrote:
> On Mon, Aug 17, 2015 at 11:50 AM, Peter Eisentraut wrote:
>> The commit message for de76884 contains some important information about
>> the purpose and use of the new .partial WAL files. But I don't see
>> anything about this in the docu
On 2015-08-17 22:33, Josh Berkus wrote:
So, both perl and python do not allow "deep nesting" of assignments.
For example:
d = { "a" : { } }
d["a"]["a1"]["a2"] = 42
Traceback (most recent call last):
File "", line 1, in
KeyError: 'a1'
Not sure I understand what you mean. In Perl you'd do
Rationale
=
Since introduction of the WAL-based replication into the PostgreSQL, it is
possible to create high-availability and load-balancing clusters.
However, there is no support for failover in the client libraries. So, only
way to provide transparent for client application failover i
On Mon, Aug 17, 2015 at 3:02 PM, Alvaro Herrera
wrote:
> Jeff Janes wrote:
>
> > The attached patch takes a ShareUpdateExclusiveLock lock on the index in
> > order to clean the pending list.
>
> Does it take a lock on the table also? Because if not ...
>
There must be some kind of lock held on
On Tue, Aug 18, 2015 at 1:02 AM, Fabien COELHO wrote:
>
> Hello Andres,
>
> [...] posix_fadvise().
>>>
>>> My current thinking is "maybe yes, maybe no":-), as it may depend on the
>>> OS
>>> implementation of posix_fadvise, so it may differ between OS.
>>>
>>
>> As long as fadvise has no 'un
Jeff Janes wrote:
> The attached patch takes a ShareUpdateExclusiveLock lock on the index in
> order to clean the pending list.
Does it take a lock on the table also? Because if not ...
> One potential problem is how it will interact with "create index
> concurrently".
... then I don't underst
On Tue, Aug 18, 2015 at 6:07 AM, Daniel Verite wrote:
> Hi,
>
> When tab-completing after GRANT EXECUTE, currently psql injects
> "PROCEDURE", rather than the expected "ON".
>
> The code for completing with "ON" is there, but it's not reached due to
> falling earlier into another branch, one that
On Tue, Aug 18, 2015 at 4:46 AM, Andres Freund wrote:
> On 2015-08-17 15:22:44 -0400, Peter Eisentraut wrote:
>> On 8/14/15 3:54 AM, Andres Freund wrote:
>> > I'd name it RESERVE_WAL.
>
>> Why "reserve"? > Isn't it "preserve"?
>
> Hm. I honestly do not know. I was thinking of ticket reservations..
>In case of vacuum, I think we need to track the number of scanned heap
>pages at least, and the information about index scan is the additional
>information
Actually the progress of heap pages scan depend on index scans. So complete
VACUUM progress
needs to have a count of index pages scanned too.
Peter Geoghegan writes:
> This patch does not add an operator at all, actually. If feels like
> there ought to be an operator, but in fact there is not. The parser is
> hard-coded to recognize array-style subscripts, which this uses.
> While I'm certainly glad that Dmitry took the time to work on
Jim Nasby writes:
> On 8/17/15 9:48 AM, Tom Lane wrote:
>> I'm inclined to think that if we wanted to make this better, the way to
>> improve it would be to detect the error*at compile time*, and get rid of
>> this hack in plpgsql_exec_function altogether.
> So split PLPGSQL_NSTYPE_LABEL into PLP
On Mon, Aug 17, 2015 at 1:41 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On Mon, Aug 17, 2015 at 10:22 AM, Josh Berkus wrote:
>>> Would be tricky. We don't currently have any way to wrap an EXPLAIN in
>>> any larger statement, do we? Would be very useful for automated query
>>> analysis,
On Mon, Aug 17, 2015 at 6:23 AM, Jeff Janes wrote:
>
> On Aug 16, 2015 11:49 PM, "Heikki Linnakangas" wrote:
> >
> > On 08/16/2015 12:58 AM, Jeff Janes wrote:
> >>
> >> When ginbulkdelete gets called for the first time in a VACUUM(i.e.
> stats
> >> == NULL), one of the first things it does is c
On 08/17/2015 02:18 PM, Jim Nasby wrote:
> On 8/17/15 3:33 PM, Josh Berkus wrote:
>> Again, how do we handle missing keys? Just return NULL? or ERROR? I'd
>> prefer the former, but there will be arguments the other way.
>
> I've been wondering if we should add some kind of "strict" JSON. My big
Dmitry Dolgov <9erthali...@gmail.com> writes:
> * is that a good idea to extend the `ArrayRef` for jsonb?
No. Make a new expression node type.
(Salesforce did something similar for an internal feature, and it was a
disaster both for code modularity and performance. We had to change it to
a sepa
On 8/17/15 3:33 PM, Josh Berkus wrote:
Again, how do we handle missing keys? Just return NULL? or ERROR? I'd
prefer the former, but there will be arguments the other way.
I've been wondering if we should add some kind of "strict" JSON. My big
concern is throwing an error if you try to provi
Hi,
When tab-completing after GRANT EXECUTE, currently psql injects
"PROCEDURE", rather than the expected "ON".
The code for completing with "ON" is there, but it's not reached due to
falling earlier into another branch, one that handles CREATE TRIGGER.
A trivial patch is attached. It adds the
On Mon, Aug 17, 2015 at 2:44 PM, Andrew Dunstan wrote:
>
>
> On 08/17/2015 03:26 PM, Merlin Moncure wrote:
>>
>>
>> I'm not sure if this:
>> update test_jsonb_subscript set test_json['a']['a1']['a2'] = 42;
>>
>> ...is a good idea. postgres operators tend to return immutable copies
>> of the item t
On 08/17/2015 10:57 AM, Dmitry Dolgov wrote:
> Hi,
>
> Some time ago the array-style subscripting for the jsonb data type was
> discussed in this mailing list. I think it will be quite convenient to
> have a such nice syntax to update jsonb objects, so I'm trying to
> implement this. I created a p
On Mon, Aug 17, 2015 at 12:26 PM, Merlin Moncure wrote:
> ...is a good idea. postgres operators tend to return immutable copies
> of the item they are referring to.
This patch does not add an operator at all, actually. If feels like
there ought to be an operator, but in fact there is not. The par
On 8/17/15 9:48 AM, Tom Lane wrote:
I'm inclined to think that if we wanted to make this better, the way to
improve it would be to detect the error*at compile time*, and get rid of
this hack in plpgsql_exec_function altogether. pl_gram.y already
successfully detects cases where CONTINUE mentions
On 2015-08-17 15:22:44 -0400, Peter Eisentraut wrote:
> On 8/14/15 3:54 AM, Andres Freund wrote:
> > I'd name it RESERVE_WAL.
> Why "reserve"? > Isn't it "preserve"?
Hm. I honestly do not know. I was thinking of ticket reservations...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On 08/17/2015 03:26 PM, Merlin Moncure wrote:
I'm not sure if this:
update test_jsonb_subscript set test_json['a']['a1']['a2'] = 42;
...is a good idea. postgres operators tend to return immutable copies
of the item they are referring to. In other words, you'd never see a
column operator on t
On Mon, Aug 17, 2015 at 12:26 PM, Merlin Moncure wrote:
> I'm not sure if this:
> update test_jsonb_subscript set test_json['a']['a1']['a2'] = 42;
>
> ...is a good idea.
This kind of "targetlist indirection" is already possible with arrays
and composite types.
--
Peter Geoghegan
--
Sent via
Dmitry Dolgov wrote:
> Some time ago the array-style subscripting for the jsonb data type was
> discussed in this mailing list. I think it will be quite convenient to have
> a such nice syntax to update jsonb objects, so I'm trying to implement
> this. I created a patch, that allows doing somethin
Hello Andres,
[...] posix_fadvise().
My current thinking is "maybe yes, maybe no":-), as it may depend on the OS
implementation of posix_fadvise, so it may differ between OS.
As long as fadvise has no 'undirty' option, I don't see how that
problem goes away. You're telling the OS to throw t
On Mon, Aug 17, 2015 at 12:57 PM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Hi,
>
> Some time ago the array-style subscripting for the jsonb data type was
> discussed in this mailing list. I think it will be quite convenient to have
> a such nice syntax to update jsonb objects, so I'm trying t
On 8/14/15 3:54 AM, Andres Freund wrote:
> I'd name it RESERVE_WAL. My feeling is that the options for the logical
> case are geared towards the output plugin, not the walsender. I think
> it'd be confusing to use (slot_options) differently for physical slots.
Why "reserve"? Isn't it "preserve"?
On 8/17/15 12:57 PM, Dmitry Dolgov wrote:
* is it interesting for the community?
We definitely need better ways to manipulate JSON.
* is that a good idea to extend the `ArrayRef` for jsonb? If it's
appropriate, probably we can rename it to `ArrayJsonbRef` of something.
* what can be improved
On 8/16/15 8:48 AM, Greg Stark wrote:
On Sun, Aug 16, 2015 at 7:33 AM, Noah Misch wrote:
When I've just spent awhile implementing a behavior change, the test diffs are
a comforting sight. They confirm that the test suite exercises the topic I
just changed. Furthermore, most tests today do not
On Mon, Aug 17, 2015 at 12:36 PM, Andres Freund wrote:
> On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
>> - The possibility that may repeatedly break #define FRONTEND
>> compilation when we add static inline functions, where instead adding
>> macros would not have caused breakage, thus resultin
On 2015-08-17 14:31:24 -0300, Alvaro Herrera wrote:
> The postmaster process in particular runs in a rather unusual
> arrangement, where most of the interesting stuff does happen in signal
> handlers.
FWIW, I think it might be worthwhile to convert postmaster into a loop
over a process local latch
On 8/15/15 4:45 AM, Petr Jelinek wrote:
We could fix a) by adding ORDER BY to those queries but I don't see how
to fix the rest easily or at all without sacrificing some test coverage.
Hopefully at some point we'll have test frameworks that don't depend on
capturing raw psql output, which pres
On Mon, Aug 17, 2015 at 11:50 AM, Peter Eisentraut wrote:
> The commit message for de76884 contains some important information about
> the purpose and use of the new .partial WAL files. But I don't see
> anything about this in the documentation or another user-visible place.
> We should probably
The commit message for de76884 contains some important information about
the purpose and use of the new .partial WAL files. But I don't see
anything about this in the documentation or another user-visible place.
We should probably add something.
--
Sent via pgsql-hackers mailing list (pgsql-ha
Hi,
Some time ago the array-style subscripting for the jsonb data type was
discussed in this mailing list. I think it will be quite convenient to have
a such nice syntax to update jsonb objects, so I'm trying to implement
this. I created a patch, that allows doing something like this:
=# create
On 08/17/2015 01:30 PM, Peter Geoghegan wrote:
On Mon, Aug 17, 2015 at 10:22 AM, Josh Berkus wrote:
Would be tricky. We don't currently have any way to wrap an EXPLAIN in
any larger statement, do we? Would be very useful for automated query
analysis, though.
No. In the grammar, ExplainStmt
Peter Geoghegan writes:
> On Mon, Aug 17, 2015 at 10:22 AM, Josh Berkus wrote:
>> Would be tricky. We don't currently have any way to wrap an EXPLAIN in
>> any larger statement, do we? Would be very useful for automated query
>> analysis, though.
> No. In the grammar, ExplainStmt expects the E
On 2015-08-17 07:37:45 +, Ewan Higgs wrote:
> So I changed volatile to _Atomic and continued (patch is in
> thread_test_atomic.patch). I then ran it against sqlsmith. The good
> news: I didn't happen to find any problems in normal use. The bad
> news: I did find a lot of warnings about improper
On Mon, Aug 17, 2015 at 10:22:11AM -0700, Josh Berkus wrote:
>
> > EXPLAIN [ANALYZE]
>
> Would be tricky. We don't currently have any way to wrap an EXPLAIN
> in any larger statement, do we?
We do, but it's kinda horrible.
CREATE OR REPLACE FUNCTION get_something_from_explain(your_query)
RETUR
Ewan Higgs wrote:
> So I changed volatile to _Atomic and continued (patch is in
> thread_test_atomic.patch). I then ran it against sqlsmith. The good
> news: I didn't happen to find any problems in normal use. The bad
> news: I did find a lot of warnings about improper use of functions
> like mall
On Mon, Aug 17, 2015 at 10:22 AM, Josh Berkus wrote:
> Would be tricky. We don't currently have any way to wrap an EXPLAIN in
> any larger statement, do we? Would be very useful for automated query
> analysis, though.
No. In the grammar, ExplainStmt expects the EXPLAIN to be at the
top-level. H
> EXPLAIN [ANALYZE]
Would be tricky. We don't currently have any way to wrap an EXPLAIN in
any larger statement, do we? Would be very useful for automated query
analysis, though.
> SHOW
Not very useful, easy to work around (pg_settings).
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexper
Folks,
In the interest of consistency, which is to say, of not hitting
barriers that are essentially implementation details, I'd like to
propose that we allow the rest of the row-returning commands inside
WITH clauses. We currently have:
SELECT
VALUES
INSERT/UPDATE/DELETE ... RETURNING
We don't
On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
> As far as I can see, the anticipated benefits of what we're doing here are:
>
> - Get a cleaner separation of frontend and backend headers (this could
> also be done independently of STATIC_IF_INLINE, but removing
> STATIC_IF_INLINE increases the
On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
> - The possibility that may repeatedly break #define FRONTEND
> compilation when we add static inline functions, where instead adding
> macros would not have caused breakage, thus resulting in continual
> tinkering with the header files.
Again, tha
On Sat, Aug 15, 2015 at 8:03 PM, Andres Freund wrote:
>> That gave me new respect for STATIC_IF_INLINE. While it does add tedious
>> work
>> to the task of introducing a new batch of inline functions, the work is
>> completely mechanical. Anyone can write it; anyone can review it; there's
>> o
On Mon, Aug 17, 2015 at 7:56 AM, Tom Lane wrote:
> Hi Neil! Long time no see.
Likewise :)
>> Attached is a one-liner to double the size of the table when space is
>> exhausted.
>
> I think this could use a comment, but otherwise seems OK.
Attached is a revised patch with a comment.
> Should w
Hi,
There seems to be a bug in the make rules when DTrace is enabled. It
causes dtrace -G to be invoked twice when building PostgreSQL as a
FreeBSD port: once during the build itself, and once during
installation. For a long time this has been worked around on FreeBSD
with a change to libdtrace it
I've written readers for both from scratch. Tar isn't that bad since it's
blocked - you read the header, skip forward N blocks, continue. The hardest
part is setting up the decompression libraries if you want to support
tar.gz or tar.bz2 files.
Zip files are more complex. You have (iirc) 5 control
On 2015-08-17 15:21:22 +0200, Fabien COELHO wrote:
> My current thinking is "maybe yes, maybe no":-), as it may depend on the OS
> implementation of posix_fadvise, so it may differ between OS.
As long as fadvise has no 'undirty' option, I don't see how that
problem goes away. You're telling the OS
On 08/17/2015 10:14 AM, Bear Giles wrote:
I'm starting to work on a tar FDW as a proxy for a much more specific
FDW. (It's the 'faster to build two and toss the first away' approach
- tar lets me get the FDW stuff nailed down before attacking the more
complex container.) It could also be usef
Neil Conway writes:
Hi Neil! Long time no see.
> spi_printtup() has the following code (spi.c:1798):
> if (tuptable->free == 0)
> {
> tuptable->free = 256;
> tuptable->alloced += tuptable->free;
> tuptable->vals = (HeapTuple *) rep
On 2015-08-17 15:51:33 +0100, Greg Stark wrote:
> But I'm not clear from the discussion exactly which compilers we're
> thinking of ruling out.
None.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
On Wed, Jul 1, 2015 at 5:14 PM, Andres Freund wrote:
> During the 9.5 cycle, and earlier, the topic of increasing our minimum
> bar for compilers came up a bunch of times. Specifically whether we
> still should continue to use C90 as a baseline.
>
> I think the time has come to rely at least on so
Jim Nasby writes:
> Calling CONTINUE with a label that's not a loop produces an error
> message with no context info [1].
True.
> I think err_stmt should probably only be reset in the non-return case a
> bit below that. I'm not sure about err_text though.
That is not going to help, as you'd s
On Wed, Jul 1, 2015 at 11:14 AM, Andres Freund wrote:
> Hi,
>
> During the 9.5 cycle, and earlier, the topic of increasing our minimum
> bar for compilers came up a bunch of times. Specifically whether we
> still should continue to use C90 as a baseline.
Minor question: is there any value to keep
On Mon, Aug 17, 2015 at 3:14 PM, Bear Giles wrote:
> I'm starting to work on a tar FDW as a proxy for a much more specific FDW.
> (It's the 'faster to build two and toss the first away' approach - tar lets
> me get the FDW stuff nailed down before attacking the more complex
> container.) It could
I'm starting to work on a tar FDW as a proxy for a much more specific FDW.
(It's the 'faster to build two and toss the first away' approach - tar lets
me get the FDW stuff nailed down before attacking the more complex
container.) It could also be useful in its own right, or as the basis for a
zip f
Here is one other thing I could learn from TPC-DS benchmark.
The attached query is Q4 of TPC-DS, and its result was towards SF=100.
It took long time to compete (about 30min), please see the attached
EXPLAIN ANALYZE output.
Its core workload is placed on CTE year_total. Its Append node has
underl
Hello Andres,
+ rc = posix_fadvise(context->fd, context->offset, [...]
I'm a bit wary that this might cause significant regressions on
platforms not supporting sync_file_range, but support posix_fadvise()
for workloads that are bigger than shared_buffers. Consider what happe
Hello Andres,
On 2015-08-12 22:34:59 +0200, Fabien COELHO wrote:
sort/flush : tps avg & stddev (percent of time beyond 10.0 tps)
on on : 631 +- 131 (0.1%)
on off : 564 +- 303 (12.0%)
off on : 167 +- 315 (76.8%) # stuck...
off off : 177 +- 305 (71.2%) # ~ cur
Hi,
On 2015-08-12 16:46:01 -0400, Stephen Frost wrote:
> From ab44660e9b8fc5b10f84ce6ba99a8340047ac8a5 Mon Sep 17 00:00:00 2001
> From: Stephen Frost
> Date: Wed, 12 Aug 2015 15:50:54 -0400
> Subject: [PATCH] In AlterRole, make bypassrls an int
>
> When reworking bypassrls in AlterRole to operat
On 2015-08-11 17:15:22 +0200, Fabien COELHO wrote:
> +void
> +PerformFileFlush(FileFlushContext * context)
> +{
> + if (context->ncalls != 0)
> + {
> + int rc;
> +
> +#if defined(HAVE_SYNC_FILE_RANGE)
> +
> + /* Linux: tell the memory manager to move these blocks to
Hi Fabien,
On 2015-08-12 22:34:59 +0200, Fabien COELHO wrote:
> sort/flush : tps avg & stddev (percent of time beyond 10.0 tps)
> on on : 631 +- 131 (0.1%)
> on off : 564 +- 303 (12.0%)
> off on : 167 +- 315 (76.8%) # stuck...
> off off : 177 +- 305 (71.2%) # ~
On 2015-08-16 03:31:48 -0400, Noah Misch wrote:
> As we see from the patches' need to add #include statements to .c files and
> from Robert's report of a broken EDB build, this change creates work for
> maintainers of non-core code, both backend code (modules) and frontend code
> (undocumented, but
v7 is a rebase after another small bug fix in pgbench.
v8 is a rebase after yet another small bug fix in pgbench.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 2517a3a..99670d4 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgben
Noah Misch wrote:
> > > If the autonomous transaction can interact with uncommitted
> > > work in a way that other backends could not, crazy things happen when the
> > > autonomous transaction commits and the suspended transaction aborts:
> > >
> > > CREATE TABLE t (c) AS SELECT 1;
> > > BEGIN;
> >
On 08/11/2015 06:44 PM, Fabien COELHO wrote:
Probably since 1bc90f7a (shame on me) pgbench does not report skipped
transactions (-L) counts properly: data are not aggregated over all
threads as they should be, either under --progress or in the end of run
report.
The attached patch fixes these re
72 matches
Mail list logo
