Re: [HACKERS] Allow a per-tablespace effective_io_concurrency setting

On Wed, Sep 2, 2015 at 4:31 PM, Josh Berkus wrote: > On 09/02/2015 02:25 PM, Tomas Vondra wrote: >> >> As I explained, spindles have very little to do with it - you need >> multiple I/O requests per device, to get the benefit. Sure, the DBAs >> should know how many spindles

[HACKERS] minor typo in trigger.c

diff --git a/src/backend/commands/trigger.c b/src/backend/commands/trigger.c index d169027..43421d6 100644 --- a/src/backend/commands/trigger.c +++ b/src/backend/commands/trigger.c @@ -4126,7 +4126,7 @@ AfterTriggerEndXact(bool isCommit) /* -* Forget the query stack and constrant-related

Re: [HACKERS] Autonomous Transaction is back

On Tue, Aug 18, 2015 at 8:17 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, Aug 15, 2015 at 6:47 PM, Noah Misch n...@leadboat.com wrote: CREATE TABLE t (c) AS SELECT 1; BEGIN; UPDATE t SET c = 2 WHERE c = 1; BEGIN_AUTONOMOUS; UPDATE t SET c = 3 WHERE c = 1; UPDATE t SET c = 4 WHERE c

Re: [HACKERS] Raising our compiler requirements for 9.6

On Wed, Jul 1, 2015 at 11:14 AM, Andres Freund and...@anarazel.de 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

Re: [HACKERS] jsonb array-style subscripting

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 to

Re: [HACKERS] jsonb array-style subscripting

On Mon, Aug 17, 2015 at 2:44 PM, Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] Autonomous Transaction is back

On Thu, Aug 6, 2015 at 4:15 PM, Robert Haas robertmh...@gmail.com wrote: On Mon, Aug 3, 2015 at 9:09 AM, Merlin Moncure mmonc...@gmail.com wrote: hm. OK, what's the behavior of: BEGIN UPDATE foo SET x = x + 1 WHERE foo_id = 1; BEGIN WITH AUTONOMOUS TRANSACTION UPDATE foo SET x = x

Re: [HACKERS] Autonomous Transaction is back

On Tue, Aug 4, 2015 at 4:12 AM, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 03 August 2015 18:40, Merlin Moncure [mailto:mmonc...@gmail.com] Wrote: On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 31 July 2015 23:10, Robert Haas Wrote: I think we're

Re: [HACKERS] Autonomous Transaction is back

On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi rajeev.rast...@huawei.com wrote: On 31 July 2015 23:10, Robert Haas Wrote: I think we're going entirely down the wrong path here. Why is it ever useful for a backend's lock requests to conflict with themselves, even with autonomous transactions?

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 29, 2015 at 12:53 PM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2015 09:40 AM, Corey Huinker wrote: Say I've got a table my_partitioned_table (key1 integer, key2 integer, metric1 integer, metric2 integer); And I've got many

Re: [HACKERS] Autonomous Transaction is back

On Mon, Jul 27, 2015 at 4:41 PM, Joel Jacobson j...@trustly.com wrote: On Fri, Jul 24, 2015 at 9:39 PM, Merlin Moncure mmonc...@gmail.com wrote: On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus j...@agliodbs.com wrote: Batch Jobs: large data-manipulation tasks which need to be broken up

Re: [HACKERS] Autonomous Transaction is back

On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus j...@agliodbs.com wrote: Batch Jobs: large data-manipulation tasks which need to be broken up into segments, with each segment committing separately. Example: updating 1 million records in batches of 1000. Autonomous transactions are not a good fit

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Tue, Jul 21, 2015 at 2:53 AM, Heikki Linnakangas hlinn...@iki.fi wrote: On 07/21/2015 10:38 AM, Pavel Stehule wrote: where we are with this patch? Can I do some for it? I still feel this approach is misguided, and we should be tweaking psql and/or libpq instead. I don't feel strongly

Re: [HACKERS] First Aggregate Funtion?

On Mon, Jul 20, 2015 at 8:40 AM, sudalai sudala...@gmail.com wrote: I don't think so, because arrays can contain duplicates. I just add two element to the array. One for INITCOND value NULL, second for first row value. So Array size is always 2. So no duplicates. rhaas=# select

Re: [HACKERS] First Aggregate Funtion?

On Mon, Jul 20, 2015 at 10:06 AM, Paul A Jungwirth p...@illuminatedcomputing.com wrote: The above implementation of first aggregate returns the first non-NULL item value. I'm curious what advantages this approach has over these FIRST/LAST functions from the Wiki?:

Re: [HACKERS] [PATCH] Generalized JSON output functions

On Sun, Jul 12, 2015 at 4:35 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2015-07-12 10:29 GMT+02:00 Shulgin, Oleksandr oleksandr.shul...@zalando.de: On Jul 11, 2015 8:41 PM, Pavel Stehule pavel.steh...@gmail.com wrote: There is simple rule - be strict on output and tolerant on

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Thu, Jul 9, 2015 at 10:48 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2015-07-09 15:17 GMT+02:00 Merlin Moncure mmonc...@gmail.com: On Wed, Jul 8, 2015 at 11:28 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hi second version of this patch make check-world passed quickly

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Wed, Jul 8, 2015 at 11:28 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hi second version of this patch make check-world passed quickly scanning the patch, the implementation is trivial (minus regression test adjustments), and is, IMSNSHO, the right solution. Several of the source

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Thu, Jul 9, 2015 at 3:31 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2015-07-09 20:08 GMT+02:00 Merlin Moncure mmonc...@gmail.com: On Thu, Jul 9, 2015 at 10:48 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2015-07-09 15:17 GMT+02:00 Merlin Moncure mmonc...@gmail.com

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Wed, Jul 8, 2015 at 1:35 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2015-07-07 18:15 GMT+02:00 Merlin Moncure mmonc...@gmail.com: On Tue, Jul 7, 2015 at 9:04 AM, Pavel Stehule pavel.steh...@gmail.com wrote: It doesn't have to if the behavior is guarded with a GUC. I just don't

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 10:12 AM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2015 10:22 PM, Michael Paquier wrote: On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway m...@joeconway.com wrote: That explains why the first example works while the second

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Wed, Jul 8, 2015 at 4:39 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2015-07-08 8:35 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com: 2015-07-07 18:15 GMT+02:00 Merlin Moncure mmonc...@gmail.com: On Tue, Jul 7, 2015 at 9:04 AM, Pavel Stehule pavel.steh...@gmail.com wrote

Re: [HACKERS] PL/pgSQL, RAISE and error context

, Jul 7, 2015 at 9:42 AM, Heikki Linnakangas hlinn...@iki.fi wrote: On 07/07/2015 04:56 PM, Merlin Moncure wrote: It doesn't have to if the behavior is guarded with a GUC. I just don't understand what all the fuss is about. The default behavior of logging that is well established by other

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Tue, Jul 7, 2015 at 8:13 AM, Heikki Linnakangas hlinn...@iki.fi wrote: On 01/26/2015 05:14 PM, Tom Lane wrote: Pavel Stehule pavel.steh...@gmail.com writes: 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja ma...@joh.to: I am thinking, so solution /* if we are doing RAISE, don't report

Re: [HACKERS] dblink: add polymorphic functions.

On Thu, Feb 19, 2015 at 4:06 PM, Corey Huinker corey.huin...@gmail.com wrote: In the course of writing a small side project which hopefully will make its way onto pgxn soon, I was writing functions that had a polymorphic result set. create function foo( p_row_type anyelement, p_param1 ...)

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 11:13 AM, Corey Huinker corey.huin...@gmail.com wrote: On Mon, Jul 6, 2015 at 11:33 AM, Merlin Moncure mmonc...@gmail.com wrote: On Mon, Jul 6, 2015 at 9:52 AM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 07:37

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 9:52 AM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 07:37 AM, Merlin Moncure wrote: yup, and at least one case now fails where previously it ran through: postgres=# select * from dblink('a', 'b', 'c'); ERROR

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 9:35 AM, Tom Lane t...@sss.pgh.pa.us wrote: Joe Conway m...@joeconway.com writes: Actually, I had in mind something like: 8- inti; intnumargs; int *argtypes; numargs = PG_NARGS(); argtypes = palloc(numargs * sizeof(int)); for (i = 0; i

Re: [HACKERS] proposal: condition blocks in psql

On Sun, Jun 28, 2015 at 1:59 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: \if_ver_eq 9.2 What do you thinking about it? Couldn't this kind of thing be done directly with PL/pgSQL? you can use PL/pgSQL - but there are some limits * maintenance large plpgsql functions I agree with

Re: [HACKERS] pg_trgm version 1.2

On Sat, Jun 27, 2015 at 5:17 PM, Jeff Janes jeff.ja...@gmail.com wrote: This patch implements version 1.2 of contrib module pg_trgm. This supports the triconsistent function, introduced in version 9.4 of the server, to make it faster to implement indexed queries where some keys are common and

Re: [HACKERS] pg_trgm version 1.2

On Mon, Jun 29, 2015 at 7:23 AM, Merlin Moncure mmonc...@gmail.com wrote: On Sat, Jun 27, 2015 at 5:17 PM, Jeff Janes jeff.ja...@gmail.com wrote: V1.1: Time: 1743.691 ms --- after repeated execution to warm the cache V1.2: Time: 2.839 ms --- after repeated execution to warm the cache

Re: [HACKERS] proposal: row_to_array function

On Tue, Jun 23, 2015 at 2:57 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 6/23/15 9:45 AM, Pavel Stehule wrote: 1. parametrized record reference syntax - some like SELECT $1[$] 2. possibility to throw plan cache, if result has different type than is expected in cache. Well, the other

Re: [HACKERS] proposal: row_to_array function

On Tue, Jun 23, 2015 at 3:45 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 6/23/15 3:22 PM, Merlin Moncure wrote: I would rephrase that to: do X to all fields of an object. Array handling is pretty good now (minus arrays of arrays, but arrays Except that still won't make it easy to do

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Jun 22, 2015 at 12:37 PM, Robert Haas robertmh...@gmail.com wrote: When a PostgreSQL system wedges, or when it becomes dreadfully slow for some reason, I often find myself relying on tools like strace, gdb, or perf to figure out what is happening. This doesn't tend to instill

Re: [HACKERS] Is it possible to have a fast-write Index?

On Thu, Jun 11, 2015 at 9:32 PM, Qingqing Zhou zhouqq.postg...@gmail.com wrote: On Fri, Jun 5, 2015 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote: So I really doubt that anyone would have any enthusiasm for saddling btree with a similar mechanism. It's complicated (and has been the cause of

Re: [HACKERS] [PATCH] Function to get size of asynchronous notification queue

On Wed, Jun 17, 2015 at 6:15 PM, Brendan Jurd dire...@gmail.com wrote: Posting v2 of the patch, incorporating some helpful suggestions from Merlin. Based on perfunctory scan of the code, I think this is gonna make it, unless you draw some objections based on lack of necessity. merlin -- Sent

Re: [HACKERS] query execution time faster with geqo on than off: bug?

On Sun, Jun 14, 2015 at 6:43 PM, David Kamholz lautges...@gmail.com wrote: I've encountered a query with 11 joins whose execution time (i.e., the time not taken up by planning) is significantly faster with geqo on rather than off. This is surprising to me and seems like it might be a bug in the

Re: [HACKERS] Function to get size of notification queue?

On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Brendan Jurd wrote: Hi Kevin, I never found a direct solution to this problem. I still feel that a function to find the size of the notification queue would be a handy feature to have, and I would be willing to

Re: [HACKERS] Function to get size of notification queue?

On Mon, Jun 15, 2015 at 3:16 PM, Brendan Jurd dire...@gmail.com wrote: On Tue, 16 Jun 2015 at 05:36 Merlin Moncure mmonc...@gmail.com wrote: On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Brendan Jurd wrote: However, given the tumbleweed/ response to my

Re: [HACKERS] On columnar storage

On Thu, Jun 11, 2015 at 6:03 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: We hope to have a chance to discuss this during the upcoming developer unconference in Ottawa. Here are some preliminary ideas to shed some light on what we're trying to do. Quick thought. We already support out

Re: [HACKERS] DBT-3 with SF=20 got failed

On Wed, Jun 10, 2015 at 9:57 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: Hello, I got the following error during DBT-3 benchmark with SF=20. psql:query21.sql:50: ERROR: invalid memory alloc request size 1073741824 psql:query21.sql:50: ERROR: invalid memory alloc request size

Re: [HACKERS] Reconsidering the behavior of ALTER COLUMN TYPE

On Thu, Jun 11, 2015 at 3:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: A recent thread in pgsql-general shows yet another user who's befuddled by the need to add a USING clause to an ALTER TABLE ... ALTER COLUMN TYPE command:

Re: [HACKERS] Improving GEQO

On Wed, May 27, 2015 at 3:06 PM, boix b...@uclv.cu wrote: Hello, my partner and me are working with the goal of improve the GEQO's performance, we tried with Ant Colony Optimization, but it does not improve, actually we are trying with a new variant of Genetic Algorithm, specifically Micro-GA.

Re: [HACKERS] [PATCH] Generalized JSON output functions

On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Andrew Dunstan wrote: On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote: Attached is a patch against master to generalize the JSON-producing functions in utils/adt/json.c and to provide a set of callbacks which

Re: [HACKERS] [PATCH] Generalized JSON output functions

On Wed, May 20, 2015 at 8:16 AM, Shulgin, Oleksandr oleksandr.shul...@zalando.de wrote: Hi, Hackers! Attached is a patch against master to generalize the JSON-producing functions in utils/adt/json.c and to provide a set of callbacks which can be overridden the same way that is already

Re: [HACKERS] cache invalidation for PL/pgsql functions

On Fri, May 1, 2015 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja ma...@joh.to wrote: We recently hit a similar case in our production environment. What was annoying about it is that there didn't seem

Re: [HACKERS] Allow SQL/plpgsql functions to accept record

On Tue, Apr 28, 2015 at 12:44 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 4/27/15 10:06 PM, Andrew Dunstan wrote: My point remains that we really need methods of a) getting the field names from generic records and b) using text values to access fields of generic records, both as lvalues

Re: [HACKERS] cache invalidation for PL/pgsql functions

On Tue, Apr 28, 2015 at 12:43 PM, Robert Haas robertmh...@gmail.com wrote: I hate to use the term bug for what somebody's probably going to tell me is acceptable behavior, but that seems like a bug. I guess the root of the problem is that PL/plgsql's cache invalidation logic only considers

Re: [HACKERS] Allow SQL/plpgsql functions to accept record

On Wed, Apr 22, 2015 at 11:20 AM, Andrew Dunstan and...@dunslane.net wrote: On 04/22/2015 11:29 AM, Jim Nasby wrote: On 4/20/15 2:04 PM, David G. Johnston wrote: SELECT (src.v).* FROM ( VALUES (ROW(1,2,3)) ) src (v); ERROR: record type has not been registered While it may not be

[HACKERS] Reducing spinlock acquisition within clock sweep loop

Background: The main sources of contention, buffer_strategy_lock, has been removed FWICT via 5d7962c6 and d72731a7. However, during the sweep each tick locks the buffer header via spinlock in order to to adjust usage_count. I believe that removing this lock is possible optimization fruit. I

Re: [HACKERS] Reducing spinlock acquisition within clock sweep loop

On Tue, Apr 21, 2015 at 3:25 PM, Andres Freund and...@anarazel.de wrote: On 2015-04-21 14:46:04 -0500, Merlin Moncure wrote: The main sources of contention, buffer_strategy_lock, has been removed FWICT via 5d7962c6 and d72731a7. However, during the sweep each tick locks the buffer header via

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On Mon, Apr 20, 2015 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Apr 15, 2015 at 5:00 PM, Martijn van Oosterhout klep...@svana.org wrote: I've been following this thread from the side with interest and got twigged by the point about loss of information. If you'd like better

Re: [HACKERS] proposal: row_to_array function

On Sun, Mar 29, 2015 at 1:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Pavel Stehule pavel.steh...@gmail.com writes: here is rebased patch. It contains both patches - row_to_array function and foreach array support. While I don't have a problem with hstore_to_array, I don't think that

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Thu, Jan 22, 2015 at 3:50 PM, Merlin Moncure mmonc...@gmail.com wrote: I still haven't categorically ruled out pl/sh yet; that's something to keep in mind. Well, after bisection proved not to be fruitful, I replaced the pl/sh calls with dummy calls that approximated the same behavior

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 28, 2015 at 8:05 AM, Merlin Moncure mmonc...@gmail.com wrote: On Thu, Jan 22, 2015 at 3:50 PM, Merlin Moncure mmonc...@gmail.com wrote: I still haven't categorically ruled out pl/sh yet; that's something to keep in mind. Well, after bisection proved not to be fruitful, I replaced

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 28, 2015 at 12:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: ...hm, I spoke to soon. So I deleted everything, and booted up a new instance 9.4 vanilla with asserts on and took no other action. Applying the script with no data activity fails

Re: [HACKERS] jsonb, unicode escapes and escaped backslashes

On Tue, Jan 27, 2015 at 12:40 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: On 01/27/2015 12:23 PM, Tom Lane wrote: I think coding anything is premature until we decide how we're going to deal with the fundamental ambiguity. The input \\uabcd will be

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Fri, Jan 16, 2015 at 5:20 PM, Peter Geoghegan p...@heroku.com wrote: On Fri, Jan 16, 2015 at 10:33 AM, Merlin Moncure mmonc...@gmail.com wrote: ISTM the next step is to bisect the problem down over the weekend in order to to narrow the search. If that doesn't turn up anything productive

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan p...@heroku.com wrote: On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure mmonc...@gmail.com wrote: Running this test on another set of hardware to verify -- if this turns out to be a false alarm which it may very well be, I can only offer my

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Fri, Jan 16, 2015 at 8:05 AM, Merlin Moncure mmonc...@gmail.com wrote: On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan p...@heroku.com wrote: On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure mmonc...@gmail.com wrote: Running this test on another set of hardware to verify -- if this turns

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Fri, Jan 16, 2015 at 8:22 AM, Andres Freund and...@2ndquadrant.com wrote: Is there any chance you can package this somehow so that others can run it locally? It looks hard to find the actual bug here without adding instrumentation to to postgres. That's possible but involves a lot of

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Fri, Jan 16, 2015 at 8:22 AM, Andres Freund and...@2ndquadrant.com wrote: Hi, On 2015-01-16 08:05:07 -0600, Merlin Moncure wrote: On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan p...@heroku.com wrote: On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure mmonc...@gmail.com wrote: Running

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Thu, Jan 15, 2015 at 8:02 AM, Merlin Moncure mmonc...@gmail.com wrote: On Thu, Jan 15, 2015 at 6:04 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 01/15/2015 03:23 AM, Peter Geoghegan wrote: So now the question is: how did that inconsistency arise? It didn't necessarily arise

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Thu, Jan 15, 2015 at 1:15 PM, Andres Freund and...@2ndquadrant.com wrote: Hi, The plot thickens! I looped the test, still stock 9.4 as of this time and went to lunch. When I came back, the database was in recovery mode. Here is the rough sequence of events. Whoa. That looks scary. Did

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Thu, Jan 15, 2015 at 1:32 PM, Merlin Moncure mmonc...@gmail.com wrote: Since it's possible the database is a loss, do you see any value in bootstrappinng it again with checksums turned on? One point of note is that this is a brand spanking new SSD, maybe we nee to rule out hardware based

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Thu, Jan 15, 2015 at 4:03 PM, Merlin Moncure mmonc...@gmail.com wrote: On Thu, Jan 15, 2015 at 1:32 PM, Merlin Moncure mmonc...@gmail.com wrote: Since it's possible the database is a loss, do you see any value in bootstrappinng it again with checksums turned on? One point of note

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Thu, Jan 15, 2015 at 6:04 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 01/15/2015 03:23 AM, Peter Geoghegan wrote: So now the question is: how did that inconsistency arise? It didn't necessarily arise at the time of the (presumed) split of block 2 to create 9. It could be that

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 9:49 AM, Andres Freund and...@2ndquadrant.com wrote: On 2015-01-14 09:47:19 -0600, Merlin Moncure wrote: On Wed, Jan 14, 2015 at 9:30 AM, Andres Freund and...@2ndquadrant.com wrote: If you gdb in, and type 'fin' a couple times, to wait till the function finishes

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 6:50 PM, Peter Geoghegan p...@heroku.com wrote: This is great, but it's not exactly clear which bt_page_items() page is which - some are skipped, but I can't be sure which. Would you mind rewriting that query to indicate which block is under consideration by

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 2:32 PM, Peter Geoghegan p...@heroku.com wrote: On Wed, Jan 14, 2015 at 12:24 PM, Peter Geoghegan p...@heroku.com wrote: Could you write some code to print out the block number (i.e. BlockNumber blkno) if there are more than, say, 5 retries within _bt_moveright()?

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 5:39 PM, Peter Geoghegan p...@heroku.com wrote: On Wed, Jan 14, 2015 at 3:38 PM, Merlin Moncure mmonc...@gmail.com wrote: (gdb) print BufferGetBlockNumber(buf) $15 = 9 ..and it stays 9, continuing several times having set breakpoint. And the index involved? I'm

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 6:26 PM, Merlin Moncure mmonc...@gmail.com wrote: On Wed, Jan 14, 2015 at 5:39 PM, Peter Geoghegan p...@heroku.com wrote: On Wed, Jan 14, 2015 at 3:38 PM, Merlin Moncure mmonc...@gmail.com wrote: (gdb) print BufferGetBlockNumber(buf) $15 = 9 ..and it stays 9

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 9:05 AM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: On Wed, Jan 14, 2015 at 8:41 AM, Tom Lane t...@sss.pgh.pa.us wrote: What are the autovac processes doing (according to pg_stat_activity)? pid,running,waiting,query 7105,00:28

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 8:41 AM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: There were seven process with that backtrace exact backtrace (except that randomly they are sleeping in the spinloop). Something else interesting: autovacuum has been running all

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 9:11 AM, Andres Freund and...@2ndquadrant.com wrote: On 2015-01-14 10:05:01 -0500, Tom Lane wrote: Merlin Moncure mmonc...@gmail.com writes: On Wed, Jan 14, 2015 at 8:41 AM, Tom Lane t...@sss.pgh.pa.us wrote: What are the autovac processes doing (according

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 9:30 AM, Andres Freund and...@2ndquadrant.com wrote: If you gdb in, and type 'fin' a couple times, to wait till the function finishes, is there actually any progress? I'm wondering whether it's just many catalog accesses + contention, or some other problem.

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Tue, Jan 13, 2015 at 7:24 PM, Peter Geoghegan p...@heroku.com wrote: On Tue, Jan 13, 2015 at 3:54 PM, Merlin Moncure mmonc...@gmail.com wrote: Some more information what's happening: This is a ghetto logical replication engine that migrates data from sql sever to postgres, consolidating

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Wed, Jan 14, 2015 at 8:03 AM, Merlin Moncure mmonc...@gmail.com wrote: Here's a backtrace: #0 0x00750a97 in spin_delay () #1 0x00750b19 in s_lock () #2 0x00750844 in LWLockRelease () #3 0x0073 in LockBuffer () #4 0x004b2db4

[HACKERS] hung backends stuck in spinlock heavy endless loop

On my workstation today (running vanilla 9.4.0) I was testing some new code that does aggressive parallel loading to a couple of tables. It ran ok several dozen times and froze up with no external trigger. There were at most 8 active backends that were stuck (the loader is threaded to a cap) --

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Tue, Jan 13, 2015 at 4:33 PM, Andres Freund and...@2ndquadrant.com wrote: Hi, On 2015-01-13 16:29:51 -0600, Merlin Moncure wrote: On my workstation today (running vanilla 9.4.0) I was testing some new code that does aggressive parallel loading to a couple of tables. It ran ok several

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Tue, Jan 13, 2015 at 5:21 PM, Andres Freund and...@2ndquadrant.com wrote: On 2015-01-13 15:17:15 -0800, Peter Geoghegan wrote: I'm inclined to think that this is a livelock, and so the problem isn't evident from the structure of the B-Tree, but it can't hurt to check. My guess is rather

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Tue, Jan 13, 2015 at 5:49 PM, Peter Geoghegan p...@heroku.com wrote: On Tue, Jan 13, 2015 at 3:21 PM, Andres Freund and...@2ndquadrant.com wrote: My guess is rather that it's contention on the freelist lock via StrategyGetBuffer's. I've seen profiles like this due to exactly that before -

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Tue, Jan 13, 2015 at 5:54 PM, Peter Geoghegan p...@heroku.com wrote: On Tue, Jan 13, 2015 at 3:50 PM, Merlin Moncure mmonc...@gmail.com wrote: I don't remember seeing _bt_moveright() or _bt_compare() figuring so prominently, where _bt_binsrch() is nowhere to be seen. I can't see

Re: [HACKERS] hung backends stuck in spinlock heavy endless loop

On Tue, Jan 13, 2015 at 5:42 PM, Andres Freund and...@2ndquadrant.com wrote: On 2015-01-13 17:39:09 -0600, Merlin Moncure wrote: On Tue, Jan 13, 2015 at 5:21 PM, Andres Freund and...@2ndquadrant.com wrote: On 2015-01-13 15:17:15 -0800, Peter Geoghegan wrote: I'm inclined to think

[HACKERS] empty select list allowed when using function as table

Interestingly, the following query works (it didn't used to): select from generate_series(1, 1); Was this intentional? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] BUG #12330: ACID is broken for unique constraints

On Mon, Dec 29, 2014 at 3:53 PM, Kevin Grittner kgri...@ymail.com wrote: I tend to build out applications on top of functions and the inability to set isolation mode inside a function confounds me from using anything but 'read committed'. Hey, no problem -- just set

Re: [HACKERS] BUG #12330: ACID is broken for unique constraints

On Mon, Dec 29, 2014 at 8:03 AM, Kevin Grittner kgri...@ymail.com wrote: Merlin Moncure mmonc...@gmail.com wrote: On Fri, Dec 26, 2014 at 12:38 PM, Kevin Grittner kgri...@ymail.com wrote: Tom Lane t...@sss.pgh.pa.us wrote: Just for starters, a 40XXX error report will fail to provide

Re: [HACKERS] BUG #12330: ACID is broken for unique constraints

On Mon, Dec 29, 2014 at 9:09 AM, Kevin Grittner kgri...@ymail.com wrote: Merlin Moncure mmonc...@gmail.com wrote: In other words, the current behavior is: txn A,B begin txn A inserts txn B inserts over A, locks, waits txn A commits. B aborts with duplicate key error What I'm proposing

Re: [HACKERS] BUG #12330: ACID is broken for unique constraints

On Mon, Dec 29, 2014 at 9:44 AM, Greg Stark st...@mit.edu wrote: On Mon, Dec 29, 2014 at 3:31 PM, Merlin Moncure mmonc...@gmail.com wrote: In that case: we don't agree. How come duplicate key errors would be reported as serialization failures but not RI errors (for example, inserting a record

Re: [HACKERS] BUG #12330: ACID is broken for unique constraints

On Mon, Dec 29, 2014 at 10:47 AM, Nikita Volkov nikita.y.vol...@mail.ru wrote: [combining replies -- nikita, better not to top-post (FYI)] [combining replied again] I'm sorry. I don't know what you mean. I just replied to an email. http://www.idallen.com/topposting.html To prove your

Re: [HACKERS] BUG #12330: ACID is broken for unique constraints

On Fri, Dec 26, 2014 at 12:38 PM, Kevin Grittner kgri...@ymail.com wrote: Tom Lane t...@sss.pgh.pa.us wrote: Just for starters, a 40XXX error report will fail to provide the duplicated key's value. This will be a functional regression, Not if, as is normally the case, the transaction is

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Mon, Dec 15, 2014 at 5:37 PM, Michael Paquier michael.paqu...@gmail.com wrote: On Tue, Dec 16, 2014 at 5:14 AM, Merlin Moncure mmonc...@gmail.com wrote: OTOH, Our built in compressor as we all know is a complete dog in terms of cpu when stacked up against some more modern implementations

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Fri, Dec 12, 2014 at 8:27 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-12-12 09:24:27 -0500, Bruce Momjian wrote: On Fri, Dec 12, 2014 at 03:22:24PM +0100, Andres Freund wrote: Well, the larger question is why wouldn't we just have the user compress the entire WAL file before

Re: [HACKERS] postgres_fdw does not see enums

On Wed, Dec 3, 2014 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us wrote: David Fetter da...@fetter.org writes: On Wed, Dec 03, 2014 at 05:52:03PM -0500, Tom Lane wrote: What do you mean reconstruct the enum? Capture its state at the time when IMPORT FOREIGN SCHEMA is executed. Right now, if you

Re: [HACKERS] bug in json_to_record with arrays

On Mon, Dec 1, 2014 at 3:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: On 12/01/2014 12:30 PM, Tom Lane wrote: Code-wise, yeah, but it would put some pressure on the translators. What did you think of the new error texts in themselves? I would prefer

Re: [HACKERS] controlling psql's use of the pager a bit more

On Thu, Nov 13, 2014 at 11:39 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Nov 13, 2014 at 11:54 AM, David G Johnston david.g.johns...@gmail.com wrote: Because I might be quite happy with 100 or 200 lines I can just scroll in my terminal's scroll buffer, but want to use the pager for

Re: [HACKERS] controlling psql's use of the pager a bit more

On Thu, Nov 13, 2014 at 12:03 PM, David Johnston david.g.johns...@gmail.com wrote: On Thu, Nov 13, 2014 at 10:55 AM, Merlin Moncure mmonc...@gmail.com wrote: On Thu, Nov 13, 2014 at 11:39 AM, Robert Haas robertmh...@gmail.com wrote: On Thu, Nov 13, 2014 at 11:54 AM, David G Johnston

[HACKERS] plpgsql plan changes causing failure after repeated invocation

I chased down a problem today where users were reporting sporadic failures in the application. Turns out, the function would work exactly 5 times and then fail; this is on 9.2. I think I understand why this is happening and I'm skeptical it's a bug in postgres, but I thought I'd socialize it.

Re: [HACKERS] Let's drop two obsolete features which are bear-traps for novices

On Tue, Nov 4, 2014 at 8:16 AM, Kevin Grittner kgri...@ymail.com wrote: In any event, I'm against removing or re-deprecating the money type. There are some problems with money; there are other problems with numeric. If the docs are failing to make the trade-offs clear, we should fix the

Re: [HACKERS] tracking commit timestamps

On Tue, Dec 10, 2013 at 2:48 PM, Robert Haas robertmh...@gmail.com wrote: Speaking of the functionality this does offer, it seems pretty limited. A commit timestamp is nice, but it isn't very interesting on its own. You really also want to know what the transaction did, who ran it, etc. ISTM

<    1   2   3   4   5   6   7   8   9   10   >