Re: [HACKERS] Escaping from blocked send() reprised.

Wow, thank you for the patch. > > > 0001: Allows WaitLatchOrSocket(WL_WRITABLE) without WL_READABLE. I've > > > tested the poll() and select() implementations on linux and > > > blindly patched up windows. > > > 0002: Put the socket the backend uses to communicate with the client > > >

Re: [HACKERS] Escaping from blocked send() reprised.

Thank you for reviewing. I'll look close to the patch tomorrow. > I must say this scares the heck out of me. The current code goes > through some trouble to not throw an error while in a recv() > send(). For example, you removed the DoingCommandRead check from > prepare_for_client_read(). There's

Re: [HACKERS] [v9.5] Custom Plan API

> On Mon, Sep 29, 2014 at 9:04 AM, Kohei KaiGai wrote: > > Do we need to match the prototype of wrapper function with callback? > > Yes. > OK, I fixed up the patch part-2, to fit declaration of GetSpecialCustomVar() with corresponding callback. Also, a noise in the part-3 patch, by git-pull, wa

Re: [HACKERS] Fwd: Proper query implementation for Postgresql driver

[ too tired to respond to the other points, but: ] Shay Rojansky writes: >> It's also possible for a type not to have send/recv functions, i.e. to >> support text-only use. > In that case, what would be the behavior of selecting such a type with an > extended query that specifies "all results in

Re: [HACKERS] Fwd: Proper query implementation for Postgresql driver

Thanks for all the answers. Tom: > FWIW, I'd go with text results, especially if you already have code to > deal with that. PG's on-the-wire binary formats are more efficient to > process in some absolute sense, but they're hardly free: you need to > consider byte endianness for integers and flo

Re: [HACKERS] Fwd: Proper query implementation for Postgresql driver

On 09/30/2014 01:09 PM, Shay Rojansky wrote: > The idea of using extended query protocol for non-prepared queries > raised another "best practices" question, which I'm hoping you can help > with. To get rid of text encoding (which is locale-dependent, > inefficient etc.) for certain fields, it see

Re: [HACKERS] Options OUTPUT_PLUGIN_* controlling format are confusing (Was: Misleading error message in logical decoding)

On Tue, Sep 30, 2014 at 12:06 AM, Robert Haas wrote: > On Mon, Sep 29, 2014 at 9:03 AM, Andres Freund > wrote: > >> -except that changes are returned as bytea. > >> +except that changes are returned as bytea and > that it > >> can > >> +be used on slots using output plugi

Re: [HACKERS] Options OUTPUT_PLUGIN_* controlling format are confusing (Was: Misleading error message in logical decoding)

On Mon, Sep 29, 2014 at 10:03 PM, Andres Freund wrote: > > 3) The formulation here seems vague as a plugin that generates textual > > output can call pg_logical_slot_peek_binary_changes as well: > > I've commented on this before: an output plugin doesn't call > pg_logical_slot_peek_binary_changes

Re: [HACKERS] Proper query implementation for Postgresql driver

On Tue, Sep 30, 2014 at 11:06 AM, Tom Lane wrote: > Shay Rojansky writes: > > Thanks for the suggestion to look at PgJDBC, I'll do that. > > BTW, libpqtypes (http://libpqtypes.esilo.com) might be worth > studying as well. I've not used it myself, but it claims to > offer datatype-extensible pro

Re: [HACKERS] Proper query implementation for Postgresql driver

Shay Rojansky writes: > Thanks for the suggestion to look at PgJDBC, I'll do that. BTW, libpqtypes (http://libpqtypes.esilo.com) might be worth studying as well. I've not used it myself, but it claims to offer datatype-extensible processing of binary formats. regards, to

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

On Thu, Sep 25, 2014 at 1:36 PM, Robert Haas wrote: > (concerns about a second sortsupport state) I think I may have underestimated the cost of not have sorttuple.datum1 with a pointer-to-text representation available in cases such as the one you describe. Attached revision introduces an alterna

Re: [HACKERS] Fwd: Proper query implementation for Postgresql driver

At 2014-09-30 07:09:38 +0200, r...@roji.org wrote: > > the unknown type would be transferred as text and we'd provide that > text to the user as an unprocessed string. Going full binary seems to > eliminate this possibility. If you're willing to hand the user an unprocessed string, why can't that

Re: [HACKERS] Fwd: Proper query implementation for Postgresql driver

Shay Rojansky writes: > The idea of using extended query protocol for non-prepared queries raised > another "best practices" question, which I'm hoping you can help with. To > get rid of text encoding (which is locale-dependent, inefficient etc.) for > certain fields, it seems that we have to get

Re: [HACKERS] Proper query implementation for Postgresql driver

Thanks for the answer Craig. The remaining point of confusion is not really about simple vs. extended, it's about text vs. binary. Sending parse/bind/describe/execute messages back-to-back means the results have to be all text or all binary. So the question is: are we supposed to transfer all typ

Re: [HACKERS] open items for 9.4

On Tue, Sep 30, 2014 at 3:44 AM, Tom Lane wrote: > Robert Haas writes: > > The items I see are: > > > - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > > > The text seems to indicate that there's some disagreement on this > > point. I don't have a strong opinion on whether or not to

Re: [HACKERS] Proper query implementation for Postgresql driver

On 09/28/2014 05:53 PM, Shay Rojansky wrote: > Hi. > > I'm a core developer on npgsql (the Postgresql .NET provider), we're > hard at work on a major 3.0 version. I have a fundamental question > that's been bugging me for a while and would like to get your opinion on it. > > Npgsql currently supp

[HACKERS] Fwd: Proper query implementation for Postgresql driver

Hi again, a few days ago I sent a question (below) about using the extended query protocol efficiently (especially for non-prepared statements). Your responses spawned a good discussion between the npgsql developers, it's here if you wish to look/weigh in: https://github.com/npgsql/npgsql/issues/37

Re: [HACKERS] proposal: plpgsql - Assert statement

On 9/17/14, 7:40 PM, Jan Wieck wrote: Exactly. Doing something like ASSERT (select count(*) from foo where fk not in (select pk from bar)) = 0; is a perfectly fine, arbitrary boolean expression. It will probably work well in a development environment too. And I am very sure that

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 09/30/2014 06:08 AM, Kevin Grittner wrote: > Well, unless we abandon transactional semantics for other MERGE > statements, we should have a way that UPSERT logic continues to > work if you don't match a suitable index; it will just be slower -- > potentially a lot slower, but that's what indexes

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 09/30/2014 05:57 AM, Kevin Grittner wrote: > Peter Geoghegan wrote: > >> I think the fact that no MERGE implementation does what you want >> should be convincing. It is *horrifically* complicated to make >> what you want work, if indeed it is technically feasible at all. >> Isn't this already

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 09/30/2014 01:59 AM, Peter Geoghegan wrote: > On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs wrote: >> If you were an ORM developer reading the PostgreSQL Release Notes for >> 9.5, which URL would you visit to see a complete description of the >> new feature, including how it works concurrently,

[HACKERS] Upcoming Postgres 9.4beta3 release

Since we bit the bullet and changed the on-disk format for JSONB data, the core committee feels that we should put out a new 9.4 beta release as soon as possible. Accordingly, we plan to wrap 9.4beta3 on Monday (Oct 6) for release Thursday Oct 9. regards, tom lane -- Se

Re: [HACKERS] Add generate_series(numeric, numeric)

On Tue, Sep 30, 2014 at 10:00 AM, Michael Paquier wrote: > > > On Mon, Sep 29, 2014 at 4:19 PM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> >> Michael >> Btw, while looking at your patch, I actually hacked it a bit and finished >> with the attached: >> - changed process to use Nume

Re: [HACKERS] Add generate_series(numeric, numeric)

On Mon, Sep 29, 2014 at 4:19 PM, Michael Paquier wrote: > > Michael > Btw, while looking at your patch, I actually hacked it a bit and finished > with the attached: > - changed process to use NumericVar instead of Numeric > - addition of custom step values with a function > generate_series(numeri

Re: [HACKERS] jsonb format is pessimal for toast compression

On Mon, Sep 29, 2014 at 12:30:40PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Thu, Sep 25, 2014 at 02:39:37PM -0400, Tom Lane wrote: > >> BTW, it seems like there is consensus that we ought to reorder the items > >> in a jsonb object to have keys first and then values, independently of

Re: [HACKERS] Documentation fix for pg_recvlogical's --create mode

On 2014-09-22 15:46:14 +0900, Michael Paquier wrote: > In the documentation of pg_recvlogical here > (http://www.postgresql.org/docs/devel/static/app-pgrecvlogical.html), > there is the following sentence: > "Create a new logical replication slot with the name specified in > --slot, using the outpu

Re: [HACKERS] Escaping from blocked send() reprised.

On 2014-09-28 00:54:21 +0200, Andres Freund wrote: > On 2014-09-27 21:12:43 +0200, Andres Freund wrote: > > On 2014-09-03 15:09:54 +0300, Heikki Linnakangas wrote: > > Sorry, I missed this message and only cought up when reading your CF > > status mail. I've attached three patches: > > > > 0001: A

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

Andres Freund writes: > On 2014-09-29 18:44:34 -0300, Alvaro Herrera wrote: >> As far as I recall, the rationale for why this is acceptable is that the >> whole of postmaster is run with signals blocked; they are only unblocked >> during the sleeping select(). > Yea, I wrote that above :). Still

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 3:08 PM, Kevin Grittner wrote: > Well, unless we abandon transactional semantics for other MERGE > statements, we should have a way that UPSERT logic continues to > work if you don't match a suitable index; it will just be slower -- > potentially a lot slower, but that's wh

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 2014-09-29 15:16:49 -0700, Kevin Grittner wrote: > Andres Freund wrote: > > > Wrong. You can't realistically implement the guarantees of UPSERT > > without a corresponding UNIQUE index. > > You definitely can do it; the question is what you consider > reasonable in terms of development effort

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

Andres Freund wrote: > Wrong. You can't realistically implement the guarantees of UPSERT > without a corresponding UNIQUE index. You definitely can do it; the question is what you consider reasonable in terms of development effort, performance, and concurrency. I think the problem can be solved

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 2014-09-29 15:08:36 -0700, Kevin Grittner wrote: > Andres Freund wrote: > > On 2014-09-29 14:57:45 -0700, Kevin Grittner wrote: > > >> The initial implementation could restrict to these exact clauses > >> and require that the boolean-expression used equality-quals on all > >> columns of a uniq

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

Andres Freund wrote: > On 2014-09-29 14:57:45 -0700, Kevin Grittner wrote: >> The initial implementation could restrict to these exact clauses >> and require that the boolean-expression used equality-quals on all >> columns of a unique index on only NOT NULL columns. > > That'll make it really ha

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 3:02 PM, Andres Freund wrote: > That'll make it really hard to actually implement real MERGE. > > Because suddenly there's no way for the user to know whether he's > written a ON condition that can implement UPSERT like properties > (i.e. the *precise* column list of an ind

[HACKERS] Valgrind warnings in master branch ("Invalid read of size 8") originating within CreatePolicy()

I see the following Valgrind warnings in a recent build of the master branch: --1159-- REDIR: 0x5f73450 (strstr) redirected to 0x4a25720 (_vgnU_ifunc_wrapper) --1159-- REDIR: 0x5f88cb0 (__strstr_sse2_unaligned) redirected to 0x4c31fa0 (strstr) 2014-09-29 14:49:24.342 PDT 1159 LOG: statement: CREA

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 2014-09-29 14:57:45 -0700, Kevin Grittner wrote: > Peter Geoghegan wrote: > > > I think the fact that no MERGE implementation does what you want > > should be convincing. It is *horrifically* complicated to make > > what you want work, if indeed it is technically feasible at all. > > Isn't thi

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

Peter Geoghegan wrote: > I think the fact that no MERGE implementation does what you want > should be convincing. It is *horrifically* complicated to make > what you want work, if indeed it is technically feasible at all. > Isn't this already complicated enough? What about the MERGE syntax I pos

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On 2014-09-29 18:44:34 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > I'm generally baffled at all the stuff postmaster does in signal > > handlers... ProcessConfigFile(), load_hba() et al. It's all done with > > signals disabled, but still. > > As far as I recall, the rationale for wh

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

Andres Freund wrote: > I'm generally baffled at all the stuff postmaster does in signal > handlers... ProcessConfigFile(), load_hba() et al. It's all done with > signals disabled, but still. As far as I recall, the rationale for why this is acceptable is that the whole of postmaster is run with s

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 2:20 PM, Kevin Grittner wrote: > The claims that you can't get a duplicate key error with an UPSERT > are completely bogus, IMV. The *best* you can do is avoid them on > the index used for matching (unless you're willing to ignore > problem input rows or mangle the data in

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

Peter Geoghegan wrote: > Heikki, Andres and I are against using MERGE for this, fwiw. Tom > seemed to think so too, on previous occasions. It isn't a matter > of alternative syntaxes. I have described in detail why I think > it's a bad idea - I have linked to that about 3 times in this > thread.

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 1:40 PM, Kevin Grittner wrote: > I think that the subset of the MERGE syntax that would be needed > for UPSERT behavior would be as follows. For one row as literals: > > MERGE INTO tab t > USING (VALUES ('foo', 'p1')) new(id, colB) > ON (t.id = new.id) > WHEN

Re: [HACKERS] open items for 9.4

On 2014-09-29 16:35:12 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-09-29 16:16:38 -0400, Tom Lane wrote: > >> I wonder why it's a fixed constant at all, and not something like > >> "wal_buffers / 8". > > > Because that'd be horrible performancewise on a system with many > > wal_buf

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

Peter Geoghegan wrote: > As I've mentioned, it isn't the MERGE syntax because that is > quite a different thing. There is a place for it, but it's not > strategically important in the same way as upsert is. I think that the subset of the MERGE syntax that would be needed for UPSERT behavior woul

Re: [HACKERS] json (b) and null fields

On 09/29/2014 04:32 PM, Tom Lane wrote: Andrew Dunstan writes: On 09/29/2014 04:14 PM, Tom Lane wrote: More to the point, the way to fix any concerns about double parsing is to create row_to_jsonb(), not to plaster a bunch of options on row_to_json(). row_to_jsonb would be completely redunda

Re: [HACKERS] open items for 9.4

Andres Freund writes: > On 2014-09-29 16:16:38 -0400, Tom Lane wrote: >> I wonder why it's a fixed constant at all, and not something like >> "wal_buffers / 8". > Because that'd be horrible performancewise on a system with many > wal_buffers. There's several operations where all locks are checked

Re: [HACKERS] json (b) and null fields

Andrew Dunstan writes: > On 09/29/2014 04:14 PM, Tom Lane wrote: >> More to the point, the way to fix any concerns about double parsing is to >> create row_to_jsonb(), not to plaster a bunch of options on row_to_json(). > row_to_jsonb would be completely redundant with to_jsonb() in my recent >

Re: [HACKERS] open items for 9.4

On 2014-09-29 16:16:38 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-09-29 14:44:42 -0400, Tom Lane wrote: > >> Personally I think a hardwired #define should be plenty. What's the > >> argument that users will need to tune this at runtime? > > > That right now it can make quite noti

Re: [HACKERS] json (b) and null fields

On 09/29/2014 04:14 PM, Tom Lane wrote: Andrew Dunstan writes: On 09/29/2014 03:23 PM, Pavel Stehule wrote: It is better than nothing, but it is not nice for JSON due 2x parsing. JSON parsing is actually pretty darn fast. Every json (as opposed to jsonb) function reparses the json. It's true

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On Mon, Sep 29, 2014 at 4:20 PM, Andres Freund wrote: >> Let's just check in the fix. It'll either fix anole or not, but we >> should fix the bug you found either way. > > Right. Are you going to do it? I can, but it'll be tomorrow. I'm neck > deep in another bug right now. I probably can't do i

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On 2014-09-29 16:16:24 -0400, Robert Haas wrote: > > > If you can manually run stuff on that machine, it'd be rather helpful if > > you could put a PG_SETMASK(&BlockSig);...PG_SETMASK(&UnBlockSig); in the > > HaveCrashedWorker() loop. > > I'd do it the other way around, and adjust ServerLoop to p

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

Robert Haas writes: > On Mon, Sep 29, 2014 at 3:37 PM, Andres Freund wrote: >> Ah. DetermineSleepTime(), which is called while signals are unblocked!, >> modifies BackgroundWorkerList. Previously that only iterated the list, >> without modifying it. That's already of quite debatable safety, but >

Re: [HACKERS] open items for 9.4

Andres Freund writes: > On 2014-09-29 14:44:42 -0400, Tom Lane wrote: >> Personally I think a hardwired #define should be plenty. What's the >> argument that users will need to tune this at runtime? > That right now it can make quite noticeable differences in > scalability. And we have not much

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On Mon, Sep 29, 2014 at 3:37 PM, Andres Freund wrote: > Yea :(. Note how signals are blocked in all the signal handlers and only > unblocked for a very short time (the sleep). > > (stare at random shit for far too long) > > Ah. DetermineSleepTime(), which is called while signals are unblocked!, >

Re: [HACKERS] json (b) and null fields

Andrew Dunstan writes: > On 09/29/2014 03:23 PM, Pavel Stehule wrote: >> It is better than nothing, but it is not nice for JSON due 2x parsing. > JSON parsing is actually pretty darn fast. Every json (as opposed to > jsonb) function reparses the json. It's true that this is not nearly as > fas

Re: [HACKERS] json (b) and null fields

2014-09-29 22:03 GMT+02:00 Andrew Dunstan : > > On 09/29/2014 03:23 PM, Pavel Stehule wrote: > >> >> >> 2014-09-27 14:00 GMT+02:00 Stephen Frost > sfr...@snowman.net>>: >> >> Andrew, all, >> >> * Andrew Dunstan (and...@dunslane.net >> ) wrote: >> > I sho

Re: [HACKERS] open items for 9.4

On 2014-09-29 14:44:42 -0400, Tom Lane wrote: > Robert Haas writes: > > The items I see are: > > > - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > > > The text seems to indicate that there's some disagreement on this > > point. I don't have a strong opinion on whether or not to kee

Re: [HACKERS] json (b) and null fields

On 09/29/2014 03:23 PM, Pavel Stehule wrote: 2014-09-27 14:00 GMT+02:00 Stephen Frost >: Andrew, all, * Andrew Dunstan (and...@dunslane.net ) wrote: > I should have been paying a bit more attention to the recent work on

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On 2014-09-29 14:46:20 -0400, Robert Haas wrote: > On Fri, May 9, 2014 at 10:18 AM, Robert Haas wrote: > > 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 te

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On 2014-09-29 15:24:55 -0400, Robert Haas wrote: > On Mon, Sep 29, 2014 at 2:52 PM, Andres Freund wrote: > > If that theory is true, wouldn't things get unstuck everytime a new > > connection comes in? Or 60 seconds have passed? That's not to say this > > isn't wrong, but still? > > There aren't

Re: [HACKERS] json (b) and null fields

2014-09-29 21:23 GMT+02:00 Pavel Stehule : > > > 2014-09-27 14:00 GMT+02:00 Stephen Frost : > >> Andrew, all, >> >> * Andrew Dunstan (and...@dunslane.net) wrote: >> > I should have been paying a bit more attention to the recent work on >> > adding an ignore_nulls option to row_to_json(). Here are

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On Mon, Sep 29, 2014 at 2:52 PM, Andres Freund wrote: >> This happened again, and I investigated further. It looks like the >> postmaster knows full well that it's supposed to start more bgworkers: >> the ones that never get started are in the postmaster's >> BackgroundWorkerList, and StartWorker

Re: [HACKERS] json (b) and null fields

2014-09-27 14:00 GMT+02:00 Stephen Frost : > Andrew, all, > > * Andrew Dunstan (and...@dunslane.net) wrote: > > I should have been paying a bit more attention to the recent work on > > adding an ignore_nulls option to row_to_json(). Here are some > > belated thought. I apologize to Pavel and Steph

Re: [HACKERS] json (b) and null fields

2014-09-29 17:38 GMT+02:00 Stephen Frost : > * Andrew Dunstan (and...@dunslane.net) wrote: > > That said, doing this as an extension is probably a good way to go, > > as I suggested upthread, since we could then make it available for > > 9.4, rather than making people wait until 9.5. > > Two point

Re: [HACKERS] json (b) and null fields

2014-09-28 18:35 GMT+02:00 Andrew Dunstan : > > On 09/27/2014 11:58 PM, Stephen Frost wrote: > >> All, >> >> >> On Saturday, September 27, 2014, Andrew Dunstan > > wrote: >> >> >> On 09/27/2014 10:52 PM, Tom Lane wrote: >> >> Andrew Dunstan writes: >> >>

Re: [HACKERS] effective_io_concurrency documentation

On Mon, Sep 29, 2014 at 10:41 AM, Peter Eisentraut wrote: > I think this is a mistake. For example, we allow setting ssl to false > even if SSL support is not compiled in. +1 -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 2:14 AM, Simon Riggs wrote: > 1. SQL Standard MERGE (or a subset) > 2. MySQL Compatible syntax > 3. Something completely different > > If we go for (3), I would like to see a long and detailed explanation > of what is wrong with (1) and (2) before we do (3). That needs to b

Re: [HACKERS] trivial patch for dynahash logging

On Sat, Sep 27, 2014 at 3:09 PM, Tom Lane wrote: > Jeff Janes writes: > > under HASH_STATISTICS, the output reporting "this HTAB" upon destruction > is > > pretty useless. Which HTAB would this one be? It is not necessarily the > > most recently created one. > > > This makes it output the %p to

Re: [HACKERS] jsonb format is pessimal for toast compression

Arthur Silva writes: > What's the call on the stride length? Are we going to keep it hardcoded? At the moment it's 32, but we could change it without forcing a new initdb. I ran a simple test that seemed to show 32 was a good choice, but if anyone else wants to try other cases, go for it.

Re: [HACKERS] jsonb format is pessimal for toast compression

On 09/29/2014 11:49 AM, Arthur Silva wrote: > What's the call on the stride length? Are we going to keep it hardcoded? Please, yes. The complications caused by a variable stride length would be horrible. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers ma

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On 2014-09-29 14:46:20 -0400, Robert Haas wrote: > On Fri, May 9, 2014 at 10:18 AM, Robert Haas wrote: > > 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 te

Re: [HACKERS] jsonb format is pessimal for toast compression

On Mon, Sep 29, 2014 at 12:19 AM, Josh Berkus wrote: > On 09/26/2014 06:20 PM, Josh Berkus wrote: > > Overall, I'm satisfied with the performance of the length-and-offset > > patch. > > Oh, also ... no bugs found. > > So, can we get Beta3 out now? > > -- > Josh Berkus > PostgreSQL Experts Inc. >

Re: [HACKERS] open items for 9.4

On Mon, Sep 29, 2014 at 2:44 PM, Tom Lane wrote: > Robert Haas writes: >> The items I see are: > >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > >> The text seems to indicate that there's some disagreement on this >> point. I don't have a strong opinion on whether or not to keep

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On Fri, May 9, 2014 at 10:18 AM, Robert Haas wrote: > 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. > Ha

Re: [HACKERS] open items for 9.4

Robert Haas writes: > The items I see are: > - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > The text seems to indicate that there's some disagreement on this > point. I don't have a strong opinion on whether or not to keep the > GUC, but if we're going to remove it it should proba

Re: [HACKERS] open items for 9.4

On 2014-09-29 11:28:07 -0700, Josh Berkus wrote: > On 09/29/2014 08:53 AM, Andres Freund wrote: > >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > >> > > >> > The text seems to indicate that there's some disagreement on this > >> > point. I don't have a strong opinion on whether or

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 2:27 AM, Craig Ringer wrote: >> Please go to some trouble to tidy things up so we have clarity that >> *we* can see and decide for ourselves whether or not you are correct. > > Are you suggesting a wiki page to document the issues, discussions > around each issue, etc? A su

Re: [HACKERS] open items for 9.4

On 09/29/2014 08:53 AM, Andres Freund wrote: >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! >> > >> > The text seems to indicate that there's some disagreement on this >> > point. I don't have a strong opinion on whether or not to keep the >> > GUC, but if we're going to remove it

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 12:02 AM, Andres Freund wrote: > On 2014-09-29 09:51:45 +0300, Heikki Linnakangas wrote: >> That said, it would be handy if the syntax was closer to MERGE. Aside from >> the concurrency issues, it does the same thing, right? So how about making >> the syntax identical to ME

Re: [HACKERS] jsonb format is pessimal for toast compression

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Done --- 201409291 is the cutover point. > > > Just to clarify- the commit bumped the catversion to 201409292, so > > version <= 201409291 has the old format while version > 201409291 ha

Re: [HACKERS] jsonb format is pessimal for toast compression

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Done --- 201409291 is the cutover point. > Just to clarify- the commit bumped the catversion to 201409292, so > version <= 201409291 has the old format while version > 201409291 has > the new format. There was no 201409291, so I s

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs wrote: > If you were an ORM developer reading the PostgreSQL Release Notes for > 9.5, which URL would you visit to see a complete description of the > new feature, including how it works concurrently, locking and other > aspects. How would you check whe

[HACKERS] effective_io_concurrency documentation

The documentation of effective_io_concurrency says Asynchronous I/O depends on an effective posix_fadvise function, which some operating systems lack. If the function is not present then setting this parameter to anything but zero will result in an error. This is not correct, bec

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 10:37 AM, Peter Geoghegan wrote: > But more likely, somebody will >> go find some other bit space that can be used to do this. My concerns have nothing to do with the availability of bit space, obviously. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

On Mon, Sep 29, 2014 at 12:05 PM, Stephen Frost wrote: > Perhaps I'm just being a bit over the top, but all this per-character > work feels a bit ridiculous.. When we're using MAXIMUM_ALIGNOF, I > suppose it's not so bad, but is there no hope to increase that and make > this whole process more ef

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 8:31 AM, Robert Haas wrote: > I'll be frank, too. Heikki doesn't need to persuade you to go his > way, because everyone other than yourself who has looked at this > problem has come up with a design that looks like his. Andres suggested something that is very roughly comp

Re: [HACKERS] jsonb format is pessimal for toast compression

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Bruce Momjian writes: > > On Thu, Sep 25, 2014 at 02:39:37PM -0400, Tom Lane wrote: > >> BTW, it seems like there is consensus that we ought to reorder the items > >> in a jsonb object to have keys first and then values, independently of the > >> other issu

Re: [HACKERS] jsonb format is pessimal for toast compression

Bruce Momjian writes: > On Thu, Sep 25, 2014 at 02:39:37PM -0400, Tom Lane wrote: >> BTW, it seems like there is consensus that we ought to reorder the items >> in a jsonb object to have keys first and then values, independently of the >> other issues under discussion. This means we *will* be bre

Re: [HACKERS] json (b) and null fields

On Sep 29, 2014, at 9:09 AM, Tom Lane wrote: > I seem to recall that we've run into practical difficulties with moving > extensions into core. It might be OK for a functions-only extension > though. It does make upgrading difficult, though, as I’ve learned the hard way with when upgrading from

Re: [HACKERS] open items for 9.4

Dne 29.9.2014 18:00 "Magnus Hagander" napsal(a): > > On Mon, Sep 29, 2014 at 5:53 PM, Andres Freund wrote: > > On 2014-09-29 11:50:19 -0400, Robert Haas wrote: > >> The items I see are: > >> > >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > >> > >> The text seems to indicate that

Re: [HACKERS] open items for 9.4

Andres Freund wrote: > On 2014-09-29 11:50:19 -0400, Robert Haas wrote: > > - pg_dump fails with --if-exists and blobs > > > > This looks like a 9.4 regression. > > Alvaro, IIRC you were looking at this one? I am. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Develop

Re: [HACKERS] json (b) and null fields

Stephen Frost writes: > * Andrew Dunstan (and...@dunslane.net) wrote: >> That said, doing this as an extension is probably a good way to go, >> as I suggested upthread, since we could then make it available for >> 9.4, rather than making people wait until 9.5. > Two points on this- having it in 9

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > Attached is a contrib module that lets you launch arbitrary command in > a background worker, and supporting infrastructure patches for core. Very cool! Started looking into this while waiting on a few CLOBBER_CACHE_ALWAYS runs to finish (ug

Re: [HACKERS] open items for 9.4

On Mon, Sep 29, 2014 at 5:53 PM, Andres Freund wrote: > On 2014-09-29 11:50:19 -0400, Robert Haas wrote: >> The items I see are: >> >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! >> >> The text seems to indicate that there's some disagreement on this >> point. I don't have a strong

Re: [HACKERS] open items for 9.4

On 2014-09-29 11:50:19 -0400, Robert Haas wrote: > The items I see are: > > - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > > The text seems to indicate that there's some disagreement on this > point. I don't have a strong opinion on whether or not to keep the > GUC, but if we're go

Re: [HACKERS] open items for 9.4

On Sun, Sep 28, 2014 at 11:36 PM, Tom Lane wrote: > Josh Berkus writes: >> So, can we get Beta3 out now? > > If nobody else steps up and says they want to do some performance > testing, I'll push the latest lengths+offsets patch tomorrow. > > Are any of the other open items listed at > https://wi

Re: [HACKERS] json (b) and null fields

* Andrew Dunstan (and...@dunslane.net) wrote: > That said, doing this as an extension is probably a good way to go, > as I suggested upthread, since we could then make it available for > 9.4, rather than making people wait until 9.5. Two points on this- having it in 9.5 doesn't preclude someone fr

Re: [HACKERS] WITH CHECK and Column-Level Privileges

* Robert Haas (robertmh...@gmail.com) wrote: > Well, I think that's an acceptable approach from the point of view of > fixing the security exposure, but it's far from ideal. Good error > messages are important for usability. I can live with this as a > short-term fix, but in the long run I strong

Re: [HACKERS] json (b) and null fields

Merlin, * Merlin Moncure (mmonc...@gmail.com) wrote: > Are you defining 'core' as 'supported by the core project' (in which > case I agree) or 'not an extension' (in which case I disagree). Which means you're suggesting it as an extension which lives in contrib..? Otherwise, I'm not following.

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Fri, Sep 26, 2014 at 5:40 PM, Peter Geoghegan wrote: > I will be frank. Everyone knows that the nbtree locking parts of this > are never going to be committed over your objections. It cannot > happen. And yet, I persist in proposing that we go that way. I may be > stubborn, but I am not so stub

  1   2   >