Re: [HACKERS] proposal: lock_time for pg_stat_database

2015-01-16 20:33 GMT+01:00 Jim Nasby : > On 1/16/15 12:30 PM, Pavel Stehule wrote: > >> >> >> 2015-01-16 19:24 GMT+01:00 Pavel Stehule > >: >> >> >> >> 2015-01-16 19:06 GMT+01:00 Jim Nasby > >: >> >> On 1/16/15 11:35 AM,

Re: [HACKERS] proposal: row_to_array function

2015-01-16 22:35 GMT+01:00 Andrew Dunstan : > > On 01/16/2015 12:22 PM, Pavel Stehule wrote: > >> >> >> There two possible transformations: >> >> row_to_array --> [[key1, value1],[key2, value2], ...] >> row_to_row_array --> [(key1, value1), (key2, value2), ... ] >> >> >>

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila wrote: > On Sat, Jan 17, 2015 at 10:41 AM, David Johnston < > david.g.johns...@gmail.com> wrote: > > On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila > wrote: > >> > >> On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston < > david.g.johns...@gmail.com> w

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Sat, Jan 17, 2015 at 10:41 AM, David Johnston wrote: > On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila wrote: >> >> On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston < david.g.johns...@gmail.com> wrote: >> > > You're right. >> > > pg_setting and SHOW command use value in current session rather

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila wrote: > On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston < > david.g.johns...@gmail.com> wrote: > > > You're right. > > > pg_setting and SHOW command use value in current session rather than > > > config file. > > > It might break these common infr

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Sat, Jan 17, 2015 at 10:02 AM, David G Johnston < david.g.johns...@gmail.com> wrote: > > You're right. > > pg_setting and SHOW command use value in current session rather than > > config file. > > It might break these common infrastructure. > > Two changes solve this problem in what seems to be

Re: [HACKERS] Parallel Seq Scan

On Fri, Jan 16, 2015 at 11:27 PM, Amit Kapila wrote: > On Fri, Jan 16, 2015 at 11:49 PM, Robert Haas wrote: >> As mentioned downthread, a far bigger consideration is the I/O pattern >> we create. A sequential scan is so-called because it reads the >> relation sequentially. If we destroy that pr

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

Sawada Masahiko wrote > On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila < > amit.kapila16@ > > wrote: >> On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko < > sawada.mshk@ > > >> wrote: >>> On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila < > amit.kapila16@ > > >>> wrote: >>> > >>> > One thought I h

Re: [HACKERS] Parallel Seq Scan

On Fri, Jan 16, 2015 at 11:49 PM, Robert Haas wrote: > > As mentioned downthread, a far bigger consideration is the I/O pattern > we create. A sequential scan is so-called because it reads the > relation sequentially. If we destroy that property, we will be more > than slightly sad. It might be

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Fri, Jan 16, 2015 at 9:55 PM, Sawada Masahiko wrote: > On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila wrote: > > > > I don't know how appealing it would be to others, but a new view > > like pg_file_settings which would display the settings in file could > > be meaningful for your need. > > > >

Re: [HACKERS] n_live_tup smaller than the number of rows in a table

The server did crash yesterday. It has many schemas that have the same table (different shards). Operations done on these tables are very similar, but only a few of them actually have this problem. Other than this error, we do not see other abnormalities on the box. Lisa From: Tom Lane mailto:

Re: [HACKERS] n_live_tup smaller than the number of rows in a table

Lisa Guo writes: > We are seeing a strange behavior where n_live_tup is way smaller than the > number of rows in a table. The table has > 18m rows, but n_live_tup only has > < 100K. We tried to do vacuum analyze to clear up any sticky errors, but it > didn’t correct the problem. We are running

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

On Fri, Jan 16, 2015 at 6:21 AM, Heikki Linnakangas wrote: > It looks very much like that a page has for some reason been moved to a > different block number. And that's exactly what Peter found out in his > investigation too; an index page was mysteriously copied to a different > block with ident

[HACKERS] n_live_tup smaller than the number of rows in a table

Hi, We are seeing a strange behavior where n_live_tup is way smaller than the number of rows in a table. The table has > 18m rows, but n_live_tup only has < 100K. We tried to do vacuum analyze to clear up any sticky errors, but it didn’t correct the problem. We are running Postgres 9.2. Any poi

Re: [HACKERS] [PATCH] explain sortorder

"Timmer, Marius" writes: > attached is version 8, fixing remaining issues, adding docs and tests as > requested/agreed. I've committed this with some rather substantial alterations, notably: * Having get_sortorder_by_keyno dig into the plan state node by itself seemed like a bad idea; it's cert

Re: [HACKERS] Fillfactor for GIN indexes

On Sat, Jan 17, 2015 at 2:40 AM, Robert Haas wrote: > There's only value in adding a fillfactor parameter to GIN indexes if > it improves performance. There are no benchmarks showing it does. > So, why are we still talking about this? Indeed. There is no such benchmark as of now, and I am not sur

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

On Fri, Jan 16, 2015 at 10:33 AM, Merlin Moncure 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 I'll look into taking other steps. That might be the quickest way to do it, provided you c

Re: [HACKERS] advance local xmin more aggressively

On 01/15/2015 09:57 PM, Robert Haas wrote: On Thu, Jan 15, 2015 at 3:08 AM, Michael Paquier wrote: On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas wrote: Here's an updated version, rebased over the pairing heap code that I just committed, and fixing those bugs. So, are we reaching an out

Re: [HACKERS] Logical Decoding follows timelines

On 2015-01-03 12:07:29 +0200, Heikki Linnakangas wrote: > >@@ -941,6 +936,8 @@ StartLogicalReplication(StartReplicationCmd *cmd) > > * Force a disconnect, so that the decoding code doesn't need to care > > * about an eventual switch from running in recovery, to running in a > > * nor

Re: [HACKERS] proposal: row_to_array function

On 01/16/2015 12:22 PM, Pavel Stehule wrote: There two possible transformations: row_to_array --> [[key1, value1],[key2, value2], ...] row_to_row_array --> [(key1, value1), (key2, value2), ... ] If we're going to go that route, I think it makes more sense to

Re: [HACKERS] proposal: lock_time for pg_stat_database

On 1/16/15 12:30 PM, Pavel Stehule wrote: 2015-01-16 19:24 GMT+01:00 Pavel Stehule mailto:pavel.steh...@gmail.com>>: 2015-01-16 19:06 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>: On 1/16/15 11:35 AM, Pavel Stehule wrote: 2015-01-16 18:23 GMT+01:00 Jim Na

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

On Fri, Jan 16, 2015 at 8:22 AM, Andres Freund wrote: > Hi, > > On 2015-01-16 08:05:07 -0600, Merlin Moncure wrote: >> On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan wrote: >> > On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure wrote: >> >> Running this test on another set of hardware to verify

Re: [HACKERS] proposal: lock_time for pg_stat_database

2015-01-16 19:24 GMT+01:00 Pavel Stehule : > > > 2015-01-16 19:06 GMT+01:00 Jim Nasby : > >> On 1/16/15 11:35 AM, Pavel Stehule wrote: >> >>> >>> >>> 2015-01-16 18:23 GMT+01:00 Jim Nasby >> jim.na...@bluetreble.com>>: >>> >>> On 1/16/15 11:00 AM, Pavel Stehule wrote: >>> >>> Hi all, >>

Re: [HACKERS] infinite loop in _bt_getstackbuf

On Thu, Jan 15, 2015 at 5:46 PM, Peter Geoghegan wrote: > I think that it might be a good idea to have circular _bt_moveright() > moves (the direct offender in Merlin's case, which has very similar > logic to your _bt_getstackbuf() problem case) detected. I'm pretty > sure that it's exceptional fo

Re: [HACKERS] proposal: lock_time for pg_stat_database

2015-01-16 19:06 GMT+01:00 Jim Nasby : > On 1/16/15 11:35 AM, Pavel Stehule wrote: > >> >> >> 2015-01-16 18:23 GMT+01:00 Jim Nasby > jim.na...@bluetreble.com>>: >> >> On 1/16/15 11:00 AM, Pavel Stehule wrote: >> >> Hi all, >> >> some time ago, I proposed a lock time measurement

Re: [HACKERS] Parallel Seq Scan

On Wed, Jan 14, 2015 at 9:00 PM, Jim Nasby wrote: > Simply doing > something like blkno % num_workers is going to cause imbalances, Yes. > but trying > to do this on a per-block basis seems like too much overhead. ...but no. Or at least, I doubt it. The cost of handing out blocks one at a tim

Re: [HACKERS] proposal: searching in array function - array_position

2015-01-16 18:37 GMT+01:00 Jim Nasby : > On 1/16/15 11:16 AM, Pavel Stehule wrote: > >> >> >> 2015-01-16 17:57 GMT+01:00 Jim Nasby > jim.na...@bluetreble.com>>: >> >> On 1/16/15 3:39 AM, Pavel Stehule wrote: >> >> I am proposing a simple function, that returns a position of >> element

Re: [HACKERS] proposal: lock_time for pg_stat_database

On 1/16/15 11:35 AM, Pavel Stehule wrote: 2015-01-16 18:23 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>: On 1/16/15 11:00 AM, Pavel Stehule wrote: Hi all, some time ago, I proposed a lock time measurement related to query. A main issue was a method, how to show

Re: [HACKERS] proposal: row_to_array function

2015-01-16 18:42 GMT+01:00 Jim Nasby : > On 1/16/15 11:22 AM, Pavel Stehule wrote: > >> >> >> 2015-01-16 18:03 GMT+01:00 Jim Nasby > jim.na...@bluetreble.com>>: >> >> On 1/16/15 3:45 AM, Pavel Stehule wrote: >> >> I am returning back to processing records in plpgsql. >> >> I am

Re: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code

Hi, On 2015-01-05 17:16:43 +0900, Michael Paquier wrote: > + xreflabel="restore_command_retry_interval"> > + restore_command_retry_interval > (integer) > + > +restore_command_retry_interval recovery > parameter > + > + > + > + > +If restor

Re: [HACKERS] proposal: row_to_array function

On 1/16/15 11:22 AM, Pavel Stehule wrote: 2015-01-16 18:03 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>: On 1/16/15 3:45 AM, Pavel Stehule wrote: I am returning back to processing records in plpgsql. I am thinking so it can be simply processed with transformation

Re: [HACKERS] Fillfactor for GIN indexes

On Thu, Jan 15, 2015 at 7:06 AM, Michael Paquier wrote: > Alexander Korotkov wrote: >> I'm not sure. On the one hand it's unclear why fillfactor should be >> different from 9.4. >> On the other hand it's unclear why it should be different from btree. >> I propose marking this "ready for committer"

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

Andres Freund writes: > On 2015-01-16 12:21:13 -0500, Tom Lane wrote: >> I think people felt that sending that information to the client wouldn't >> be a good idea security-wise. > It won't if issued during the right phase of the authentication: Good point. > But as I don't think sending logs t

Re: [HACKERS] proposal: searching in array function - array_position

On 1/16/15 11:16 AM, Pavel Stehule wrote: 2015-01-16 17:57 GMT+01:00 Jim Nasby mailto:jim.na...@bluetreble.com>>: On 1/16/15 3:39 AM, Pavel Stehule wrote: I am proposing a simple function, that returns a position of element in array. Yes please! FUNCTION array_posi

Re: [HACKERS] proposal: lock_time for pg_stat_database

2015-01-16 18:23 GMT+01:00 Jim Nasby : > On 1/16/15 11:00 AM, Pavel Stehule wrote: > >> Hi all, >> >> some time ago, I proposed a lock time measurement related to query. A >> main issue was a method, how to show this information. Today proposal is >> little bit simpler, but still useful. We can sh

Re: [HACKERS] speedup tidbitmap patch: cache page

Andres Freund writes: > On 2015-01-16 12:15:35 -0500, Tom Lane wrote: >> It strikes me that this patch leaves some lookups on the table, >> specifically that it fails to avoid repeated hash_search lookups >> inside tbm_page_is_lossy() in the situation where we're adding >> new TIDs to an already-l

Re: Partitioning: issues/ideas (Was: Re: [HACKERS] On partitioning)

On Wed, Jan 14, 2015 at 9:07 PM, Amit Langote wrote: > * It has been repeatedly pointed out that we may want to decouple > partitioning from inheritance because implementing partitioning as an > extension of inheritance mechanism means that we have to keep all the > existing semantics which might

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

On 2015-01-16 12:21:13 -0500, Tom Lane wrote: > Andres Freund writes: > > Why don't we just add emit a NOTICE or WARNING in the relevant place > > saying that pg_hba.conf is outdated? Then the server won't log those if > > configured appropriately, which doesn't seem like a bad thing. Note that >

Re: [HACKERS] proposal: lock_time for pg_stat_database

On 1/16/15 11:00 AM, Pavel Stehule wrote: Hi all, some time ago, I proposed a lock time measurement related to query. A main issue was a method, how to show this information. Today proposal is little bit simpler, but still useful. We can show a total lock time per database in pg_stat_database

Re: [HACKERS] proposal: row_to_array function

2015-01-16 18:03 GMT+01:00 Jim Nasby : > On 1/16/15 3:45 AM, Pavel Stehule wrote: > >> I am returning back to processing records in plpgsql. >> >> I am thinking so it can be simply processed with transformations to array. >> >> Now we have similar functions - hstore(row), row_to_json, ... but usin

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

Andres Freund writes: > Why don't we just add emit a NOTICE or WARNING in the relevant place > saying that pg_hba.conf is outdated? Then the server won't log those if > configured appropriately, which doesn't seem like a bad thing. Note that > <= ERROR messages aren't sent to the client during aut

Re: [HACKERS] speedup tidbitmap patch: cache page

On 2015-01-16 12:15:35 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2014-12-25 01:26:53 +1300, David Rowley wrote: > >> So I think v3 is the one to go with, and I can't see any problems with it, > >> so I'm marking it as ready for committer. > > > And committed. > > It strikes me that t

Re: [HACKERS] proposal: searching in array function - array_position

2015-01-16 17:57 GMT+01:00 Jim Nasby : > On 1/16/15 3:39 AM, Pavel Stehule wrote: > >> I am proposing a simple function, that returns a position of element in >> array. >> > > Yes please! > > FUNCTION array_position(anyarray, anyelement) RETURNS int >> > > That won't work on a multi-dimensional a

Re: [HACKERS] speedup tidbitmap patch: cache page

Andres Freund writes: > On 2014-12-25 01:26:53 +1300, David Rowley wrote: >> So I think v3 is the one to go with, and I can't see any problems with it, >> so I'm marking it as ready for committer. > And committed. It strikes me that this patch leaves some lookups on the table, specifically that

Re: [HACKERS] pg_rewind in contrib

On 01/16/2015 03:30 AM, Peter Eisentraut wrote: Here is a random bag of comments for the v5 patch: Addressed most of your comments, and Michael's. Another version attached. More on a few of the comments below. The option --source-server had be confused at first, because the entry above unde

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

On 2015-01-16 18:01:24 +0100, Andres Freund wrote: > Why don't we just add emit a NOTICE or WARNING in the relevant place > saying that pg_hba.conf is outdated? Then the server won't log those if > configured appropriately, which doesn't seem like a bad thing. Note that > <= ERROR messages aren't s

Re: [HACKERS] proposal: row_to_array function

On 1/16/15 3:45 AM, Pavel Stehule wrote: I am returning back to processing records in plpgsql. I am thinking so it can be simply processed with transformations to array. Now we have similar functions - hstore(row), row_to_json, ... but using of these functions can be a useless step. Any row va

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

On 2014-12-15 19:38:16 +0300, Alex Shulgin wrote: > Attached is the modified version of the original patch by Craig, > addressing the handling of the new hint_log error data field and > removing the client-side HINT. I'm not a big fan of this implementation. We're adding a fair bit of infrastructu

[HACKERS] proposal: lock_time for pg_stat_database

Hi all, some time ago, I proposed a lock time measurement related to query. A main issue was a method, how to show this information. Today proposal is little bit simpler, but still useful. We can show a total lock time per database in pg_stat_database statistics. High number can be signal about lo

Re: [HACKERS] Temporal features in PostgreSQL

What's the current status of this topic? Has someone worked on temporal tables for PostgreSQL since 2012 ? I'm giving a presentation on Fosdem later this month in Brussels, on the topic of temporal tables, and would like to give all possibly relevant information to the audience! -- Peter Van

Re: [HACKERS] proposal: searching in array function - array_position

On 1/16/15 3:39 AM, Pavel Stehule wrote: I am proposing a simple function, that returns a position of element in array. Yes please! FUNCTION array_position(anyarray, anyelement) RETURNS int That won't work on a multi-dimensional array. Ideally it needs to accept a slice or an element and r

Re: [HACKERS] [RFC] Incremental backup v3: incremental PoC

On 14/01/15 17:22, Gabriele Bartolini wrote: > > My opinion, Marco, is that for version 5 of this patch, you: > > 1) update the information on the wiki (it is outdated - I know you have > been busy with LSN map optimisation) Done. > 2) modify pg_basebackup in order to accept a directory (or tar

Re: [HACKERS] speedup tidbitmap patch: cache page

On 2014-12-25 01:26:53 +1300, David Rowley wrote: > So I think v3 is the one to go with, and I can't see any problems with it, > so I'm marking it as ready for committer. And committed. Thanks Teodor and David. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadr

Re: [HACKERS] Safe memory allocation functions

Andres Freund wrote: > On 2015-01-16 12:56:18 -0300, Alvaro Herrera wrote: > > So how about something like > > > > #define ALLOCFLAG_HUGE 0x01 > > #define ALLOCFLAG_NO_ERROR_ON_OOM 0x02 > > void * > > MemoryContextAllocFlags(MemoryContext context, Size size, int flags); >

Re: [HACKERS] Merging postgresql.conf and postgresql.auto.conf

On Fri, Jan 16, 2015 at 12:54 PM, Amit Kapila wrote: > On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko > wrote: >> On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila >> wrote: >> > >> > One thought I have in this line is that currently there doesn't seem to >> > be >> > a way to know if the setting h

Re: [HACKERS] Safe memory allocation functions

On 2015-01-16 12:56:18 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > We rely on palloc erroring out on large allocations in a couple places > > as a crosscheck. I don't think this argument holds much water. > > I don't understand what that has to do with it. Surely we're not going > to

Re: [HACKERS] PATCH: Reducing lock strength of trigger and foreign key DDL

On 2015-01-16 15:16:20 +0100, Andreas Karlsson wrote: > Indeed. As Noah and I discussed previously in this thread we would need to > do quite a bit of refactoring of ruleutils.c to make it fully MVCC. Right. > For this reason I opted to only lower the lock levels of ADD and ALTER > TRIGGER, and n

Re: [HACKERS] Safe memory allocation functions

Andres Freund wrote: > On 2015-01-16 12:09:25 -0300, Alvaro Herrera wrote: > > Robert Haas wrote: > > > On Thu, Jan 15, 2015 at 10:57 AM, Alvaro Herrera > > > wrote: > > > > > >> I do think that "safe" is the wrong suffix. Maybe palloc_soft_fail() > > > >> or palloc_null() or palloc_no_oom() or

Re: [HACKERS] Safe memory allocation functions

On 2015-01-16 12:09:25 -0300, Alvaro Herrera wrote: > Robert Haas wrote: > > On Thu, Jan 15, 2015 at 10:57 AM, Alvaro Herrera > > wrote: > > > >> I do think that "safe" is the wrong suffix. Maybe palloc_soft_fail() > > >> or palloc_null() or palloc_no_oom() or palloc_unsafe(). > > > > > > I like

Re: [HACKERS] orangutan seizes up during isolation-check

On 16 January 2015 at 01:33, Noah Misch wrote: > On Thu, Jan 15, 2015 at 09:24:01AM -0500, Robert Haas wrote: > > On Thu, Jan 15, 2015 at 1:04 AM, Noah Misch wrote: > > > On Wed, Jan 14, 2015 at 04:48:53PM -0500, Peter Eisentraut wrote: > > >> What I'm seeing now is that the unaccent regression

Re: [HACKERS] Error check always bypassed in tablefunc.c

Michael Paquier wrote: > As mentioned in $subject, commit 08c33c4 of 2003 has made the > following block of code dead in tablefunc.c:1320 because level is > incremented to at least 1: > /* First time through, do a little more setup */ > if (level == 0) >

Re: [HACKERS] orangutan seizes up during isolation-check

On Fri, Jan 16, 2015 at 05:43:44AM -0500, Dave Cramer wrote: > On 16 January 2015 at 01:33, Noah Misch wrote: > > Sure, done. Dave, orangutan should now be able to pass with --enable-nls. > > Would you restore that option? > > I can, but is this for HEAD or all versions ? All versions. -- Se

[HACKERS] Error check always bypassed in tablefunc.c

Hi all, As mentioned in $subject, commit 08c33c4 of 2003 has made the following block of code dead in tablefunc.c:1320 because level is incremented to at least 1: /* First time through, do a little more setup */ if (level == 0) {

Re: [HACKERS] Safe memory allocation functions

Robert Haas wrote: > On Thu, Jan 15, 2015 at 10:57 AM, Alvaro Herrera > wrote: > >> I do think that "safe" is the wrong suffix. Maybe palloc_soft_fail() > >> or palloc_null() or palloc_no_oom() or palloc_unsafe(). > > > > I liked palloc_noerror() better myself FWIW. > > I don't care for noerror

Re: [HACKERS] Safe memory allocation functions

On Thu, Jan 15, 2015 at 10:57 AM, Alvaro Herrera wrote: >> Hmm, I understood Tom to be opposing the idea of a palloc variant that >> returns NULL on failure, and I understand you to be supporting it. >> But maybe I'm confused. > > Your understanding seems correct to me. I was just saying that you

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

On Fri, Jan 16, 2015 at 8:22 AM, Andres Freund 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 complexity in the setup be

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

Hi, On 2015-01-16 08:05:07 -0600, Merlin Moncure wrote: > On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan wrote: > > On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure wrote: > >> Running this test on another set of hardware to verify -- if this > >> turns out to be a false alarm which it may very

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

On 01/16/2015 04:05 PM, Merlin Moncure wrote: On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan wrote: On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure 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 of

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

On Fri, Jan 16, 2015 at 8:05 AM, Merlin Moncure wrote: > On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan wrote: >> On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure wrote: >>> Running this test on another set of hardware to verify -- if this >>> turns out to be a false alarm which it may very wel

Re: [HACKERS] PATCH: Reducing lock strength of trigger and foreign key DDL

On 01/16/2015 03:01 PM, Andres Freund wrote: Hi, /* -* Grab an exclusive lock on the pk table, so that someone doesn't delete -* rows out from under us. (Although a lesser lock would do for that -* purpose, we'll need exclusive lock anyway to add triggers to the

Re: [HACKERS] Safe memory allocation functions

On 2015-01-16 23:06:12 +0900, Michael Paquier wrote: > /* > + * Wrappers for allocation functions. > + */ > +static void *set_alloc_internal(MemoryContext context, > + Size size, bool > noerror); > +static void *set_realloc_internal(Memo

Re: [HACKERS] Safe memory allocation functions

On 2015-01-16 08:47:10 +0900, Michael Paquier wrote: > On Fri, Jan 16, 2015 at 12:57 AM, Alvaro Herrera > wrote: > >> I do think that "safe" is the wrong suffix. Maybe palloc_soft_fail() > >> or palloc_null() or palloc_no_oom() or palloc_unsafe(). > > > > I liked palloc_noerror() better myself FW

Re: [HACKERS] Safe memory allocation functions

On Fri, Jan 16, 2015 at 8:47 AM, Michael Paquier wrote: > Voting for palloc_noerror() as well. And here is an updated patch using this naming, added to the next CF as well. -- Michael From b636c809c2f2cb4177bedc2e5a4883a79b61fbc6 Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Tue, 13 Jan 2

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

On Thu, Jan 15, 2015 at 5:10 PM, Peter Geoghegan wrote: > On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure 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 apologies! I've never had a new

Re: [HACKERS] PATCH: Reducing lock strength of trigger and foreign key DDL

Hi, > /* > - * Grab an exclusive lock on the pk table, so that someone doesn't > delete > - * rows out from under us. (Although a lesser lock would do for that > - * purpose, we'll need exclusive lock anyway to add triggers to the pk > - * table; trying to start with a l

Re: [HACKERS] Bug in pg_dump

On 16/01/2015 01:06, Jim Nasby wrote: > On 1/15/15 5:26 AM, Gilles Darold wrote: >> Hello, >> >> There's a long pending issue with pg_dump and extensions that have >> table members with foreign keys. This was previously reported in this >> thread >> http://www.postgresql.org/message-id/ca+tgmoyvzka

Re: [HACKERS] Turning recovery.conf into GUCs

On 2015-01-16 21:50:16 +0900, Michael Paquier wrote: > On Fri, Jan 16, 2015 at 9:45 PM, Andres Freund wrote: > > On 2015-01-16 21:43:43 +0900, Michael Paquier wrote: > >> On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut wrote: > >> > I have written similar logic, and while it's not pleasant, it's

Re: [HACKERS] parallel mode and parallel contexts

On 2015-01-05 11:27:57 -0500, Robert Haas wrote: > On Sat, Jan 3, 2015 at 7:31 PM, Andres Freund wrote: > > * I wonder if parallel contexts shouldn't be tracked via resowners > > That is a good question. I confess that I'm somewhat fuzzy about > which things should be tracked via the resowner me

Re: [HACKERS] Turning recovery.conf into GUCs

On Fri, Jan 16, 2015 at 9:45 PM, Andres Freund wrote: > On 2015-01-16 21:43:43 +0900, Michael Paquier wrote: >> On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut wrote: >> > I have written similar logic, and while it's not pleasant, it's doable. >> > This issue would really only go away if you do

Re: [HACKERS] Turning recovery.conf into GUCs

On 2015-01-16 21:43:43 +0900, Michael Paquier wrote: > On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut wrote: > > I have written similar logic, and while it's not pleasant, it's doable. > > This issue would really only go away if you don't use a file to signal > > recovery at all, which you have

Re: [HACKERS] Turning recovery.conf into GUCs

On Wed, Jan 7, 2015 at 6:22 AM, Peter Eisentraut wrote: > I have written similar logic, and while it's not pleasant, it's doable. > This issue would really only go away if you don't use a file to signal > recovery at all, which you have argued for, but which is really a > separate and more diffic

Re: [HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

On Thu, Jan 8, 2015 at 4:07 AM, Tomas Vondra wrote: > which is IMHO obviously wrong, because that accounts only for the > hashtable itself. > In those cases the patch actually does no memory accounting and as > hashcontext has no child contexts, there's no accounting overhead. > [blah] > So the p

Re: [HACKERS] segmentation fault in execTuples.c#ExecStoreVirtualTuple

On 16. Januar 2015 at 00:57:14, Tom Lane (t...@sss.pgh.pa.us) wrote: > I wrote: > > Manuel Kniep writes: > >> ok after lot’s of testing I could create a test case > >> which can be found here > >> https://gist.github.com/rapimo/3c8c1b35270e5854c524 > >> it’s written in ruby an depends on the gem

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

Hi Heikki, On 2014-09-02 21:22:29 +0300, Heikki Linnakangas wrote: > On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote: > > To make the code mentioned above (Patch 0002) tidy, rewrite the > > socket emulation code for win32 backends so that each socket > > can have its own non-blocking state.

Re: [HACKERS] More Norwegian trouble

On 01/16/2015 09:13 AM, Noah Misch wrote: On Thu, Jan 08, 2015 at 04:37:37PM +0200, Heikki Linnakangas wrote: setlocale(LC_COLLATE, NULL) -> "Norwegian (Bokmål)_Norway" but: setlocale(LC_COLLATE, "norwegian-bokmal_Norway") -> "Norwegian_Norway") Apparently the behavior changed when I upgrad

[HACKERS] proposal: row_to_array function

Hi I am returning back to processing records in plpgsql. I am thinking so it can be simply processed with transformations to array. Now we have similar functions - hstore(row), row_to_json, ... but using of these functions can be a useless step. Any row variable can be transformed to 2D text arr

[HACKERS] proposal: searching in array function - array_position

Hi I am proposing a simple function, that returns a position of element in array. FUNCTION array_position(anyarray, anyelement) RETURNS int Implementation is simple (plpgsql code) CREATE OR REPLACE FUNCTION array_position(anyarray, anyelement) RETURNS int AS $$ DECLARE i int := 0; BEGIN FOREA

[HACKERS] hamerkop is stuck

Buildfarm member hamerkop stopped reporting in after commit f6dc6dd. After commit 8d9cb0b, it resumed reporting in for 9.3 and earlier branches. It is still silent for HEAD and REL9_4_STABLE. It may have stale processes or stale lock files requiring manual cleanup. Would you check it? Thanks,

Re: [HACKERS] Async execution of postgres_fdw.

I revised the patch so that async scan will be done more aggressively, and took execution time for two very simple cases. As the result, simple seq scan gained 5% and hash join of two foreign tables gained 150%. (2.4 times faster). While measuring the performance, I noticed that each scan in a qu

Re: [HACKERS] VODKA?

On Thu, Jan 8, 2015 at 11:20 PM, Jim Nasby wrote: > On 1/7/15, 3:26 PM, Arthur Silva wrote: > >> >> On Jan 6, 2015 7:14 PM, "Josh Berkus" > j...@agliodbs.com>> wrote: >> > >> > Oleg, Teodor: >> > >> > I take it VODKA is sliding to version 9.6? >> >> This is kinda off, but I was wondering if a