Re: [HACKERS] Pg default's verbosity?

On Tue, Jun 19, 2012 at 02:15:43AM -0400, Tom Lane wrote: > Robert Haas writes: > > There might be something to the idea of demoting a few of the things > > we've traditionally had as NOTICEs, though. IME, the following two > > messages account for a huge percentage of the chatter: > > > NOTICE:

Re: [HACKERS] Checkpointer on hot standby runs without looking checkpoint_segments

On 8 June 2012 09:14, Kyotaro HORIGUCHI wrote: > Hello, I will make this patch start again for this CF. > > The requirement for this patch is as follows. > > - What I want to get is similarity of the behaviors between >  master and (hot-)standby concerning checkpoint >  progression. Specifically,

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

Le vendredi 29 juin 2012 04:26:42, Tom Lane a écrit : > Josh Berkus writes: > > Well, I think it's "plausible but wrong under at least some common > > circumstances". In addition to seeking, it ignores FS cache effects > > (not that I have any idea how to account for these mathematically). It >

Re: [HACKERS] Notify system doesn't recover from "No space" error

[Resending as the original post didn't get through to the list] Warming up an old thread here - we ran into the same problem. Database is 9.1.4/x86_64 from Debian/testing. The client application is bucardo hammering the database with NOTIFYs (including some master-master replication conflicts, th

Re: [HACKERS] Covering Indexes

On Thu, Jun 28, 2012 at 7:02 AM, Rob Wultsch wrote: > On Thu, Jun 28, 2012 at 8:16 AM, David E. Wheeler > wrote: >> Hackers, >> >> Very interesting design document for SQLite 4: >> >>  http://www.sqlite.org/src4/doc/trunk/www/design.wiki >> >> I'm particularly intrigued by "covering indexes". Fo

Re: [HACKERS] [ADMIN] pg_basebackup blocking all queries with horrible performance

On Wed, Jun 27, 2012 at 7:58 PM, Simon Riggs wrote: > On 27 June 2012 18:24, Fujii Masao wrote: > >> will never become sync standby even >> if their name is in synchronous_standby_names. > > I don't understand why you'd want that. > > What is wrong with removing the name from synchronous_standby_

Re: [HACKERS] [ADMIN] pg_basebackup blocking all queries with horrible performance

On Wed, Jun 27, 2012 at 7:24 PM, Fujii Masao wrote: > On Thu, Jun 21, 2012 at 3:18 AM, Robert Haas wrote: >> On Wed, Jun 20, 2012 at 7:18 AM, Magnus Hagander wrote: >> You agreed to add something like NOSYNC option into START_REPLICATION >> command? > > I'm on the fence. I was h

Re: [HACKERS] Reporting hba lines

On Wed, Jun 27, 2012 at 4:27 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Jun 27, 2012 at 4:14 PM, Tom Lane wrote: >>> cases where people are modifying the wrong hba file.  Can we show >>> the source text of the hba line? > >> We don't currently keep the full source text around - but

Re: [HACKERS] [PATCH 10/16] Introduce the concept that wal has a 'origin' node

2012-06-19 09:24 keltezéssel, Andres Freund írta: On Tuesday, June 19, 2012 04:12:47 AM Steve Singer wrote: On 12-06-18 07:30 AM, Andres Freund wrote: Hrmpf #666. I will go through through the series commit-by-commit again to make sure everything compiles again. Reordinging this late definitely

Re: [HACKERS] [PATCH 11/16] Add infrastructure for manipulating multiple streams of wal on a segment handling level

Hi, trying to review this one according to http://wiki.postgresql.org/wiki/Reviewing_a_Patch # Is the patch in context diff format ? No. (Does this requirement still apply after PostgreSQL switched to GIT?) # Does it apply cleanly to the curr

Re: [HACKERS] [PATCH 10/16] Introduce the concept that wal has a 'origin' node

On Friday, June 29, 2012 02:43:49 PM Boszormenyi Zoltan wrote: > 2012-06-19 09:24 keltezéssel, Andres Freund írta: > > On Tuesday, June 19, 2012 04:12:47 AM Steve Singer wrote: > >> On 12-06-18 07:30 AM, Andres Freund wrote: > >>> Hrmpf #666. I will go through through the series commit-by-commit ag

Re: [HACKERS] [PATCH 11/16] Add infrastructure for manipulating multiple streams of wal on a segment handling level

Hi, On Friday, June 29, 2012 02:43:52 PM Boszormenyi Zoltan wrote: > trying to review this one according to > http://wiki.postgresql.org/wiki/Reviewing_a_Patch > > # Is the patch in context diff format > ? > No. (Does this requirement still apply

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

2012-06-21 23:53 keltezéssel, Simon Riggs írta: On 21 June 2012 19:13, Jaime Casanova wrote: On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai wrote: 2012/6/8 Simon Riggs : I have a prototype that has some of these characteristics, so I see our work as complementary. At present, I don't think

Re: [HACKERS] [PATCH 11/16] Add infrastructure for manipulating multiple streams of wal on a segment handling level

2012-06-29 15:01 keltezéssel, Andres Freund írta: Hi, On Friday, June 29, 2012 02:43:52 PM Boszormenyi Zoltan wrote: trying to review this one according to http://wiki.postgresql.org/wiki/Reviewing_a_Patch # Is the patch in context diff format

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

2012-04-25 11:40 keltezéssel, Kohei KaiGai írta: 2012/3/10 Simon Riggs : On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan wrote: On 03/09/2012 01:40 PM, Robert Haas wrote: On Fri, Mar 9, 2012 at 12:02 PM, David E. Wheeler wrote: On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote: 100% agree

Re: [HACKERS] Reporting hba lines

Magnus Hagander writes: > Turned out to be a bit more work than I thought, since the current > parser reads pg_hba byte by byte, and not line by line. So I had to > change that. See attached, seems reasonable? A couple of comments: * In some places you have "if ((c = *(*lineptr)++) != '\0')" and

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

2012/6/29 Boszormenyi Zoltan : > 2012-04-25 11:40 keltezéssel, Kohei KaiGai írta: > >> 2012/3/10 Simon Riggs : >>> >>> On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan >>> wrote: On 03/09/2012 01:40 PM, Robert Haas wrote: > > On Fri, Mar 9, 2012 at 12:02 PM, David E. > Whe

Re: [HACKERS] plpython issue with Win64 (PG 9.2)

Thank you. Please do let me know once fix check-in. I will test it and share feedback with you. Thanks. Best Regards, Asif Naeem On Fri, Jun 29, 2012 at 3:36 AM, Jan Urbański wrote: > On 27/06/12 13:57, Jan Urbański wrote: > >> On 27/06/12 11:51, Asif Naeem wrote: >> >>> Hi, >>> >>> On Windows

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

2012-06-29 16:44 keltezéssel, Kohei KaiGai írta: 2012/6/29 Boszormenyi Zoltan : 2012-04-25 11:40 keltezéssel, Kohei KaiGai írta: 2012/3/10 Simon Riggs : On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan wrote: On 03/09/2012 01:40 PM, Robert Haas wrote: On Fri, Mar 9, 2012 at 12:02 PM, David

Re: [HACKERS] [PATCH 13/16] Introduction of pair of logical walreceiver/sender

On 13.06.2012 14:28, Andres Freund wrote: A logical WALReceiver is started directly by Postmaster when we enter PM_RUN state and the new parameter multimaster_conninfo is set. For now only one of those is started, but the code doesn't rely on that. In future multiple ones should be allowed. Cou

Re: [HACKERS] [PATCH 13/16] Introduction of pair of logical walreceiver/sender

Heikki Linnakangas wrote: > On 13.06.2012 14:28, Andres Freund wrote: >> A logical WALReceiver is started directly by Postmaster when we >> enter PM_RUN state and the new parameter multimaster_conninfo is >> set. For now only one of those is started, but the code doesn't >> rely on that. In future

Re: [HACKERS] [PATCH 13/16] Introduction of pair of logical walreceiver/sender

On Friday, June 29, 2012 05:16:11 PM Heikki Linnakangas wrote: > On 13.06.2012 14:28, Andres Freund wrote: > > A logical WALReceiver is started directly by Postmaster when we enter > > PM_RUN state and the new parameter multimaster_conninfo is set. For now > > only one of those is started, but the

Re: [HACKERS] [PATCH 13/16] Introduction of pair of logical walreceiver/sender

On 29.06.2012 18:28, Kevin Grittner wrote: It would be nice if there was at least a thin layer of the sender portion which could by used by a stand-alone program. I can think of lots of useful reasons to "T" the WAL stream -- passing through the stream with little or no modification to at least

Re: [v9.3] Extra Daemons (Re: [HACKERS] elegant and effective way for running jobs inside a database)

On Fri, Jun 29, 2012 at 9:44 AM, Kohei KaiGai wrote: > > The auth_counter is just an proof-of-concept patch, so, it is helpful if you > could provide another use case that can make sense. > what about pgbouncer? -- Jaime Casanova         www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7

Re: [HACKERS] pg_upgrade log files

Excerpts from Tom Lane's message of vie jun 29 01:04:13 -0400 2012: > Alvaro Herrera writes: > > I propose this patch which echoes the commands to the respective log > > files. I would backpatch this to 9.2. > > OK, but the fflush just before fclose seems a bit pointless; fclose > will do that

[HACKERS] Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux

Hi, I'll reply to Jeff with a brief thank you to Robert the bottom. First of all, here's an update: I have slightly modified the patch, I'll attach what I have at the moment. The main difference are - loops around the pthread_mutex calls: As the locking function signature is to return void at

Re: [HACKERS] Posix Shared Mem patch

> According to the Google, there is absolutely no way of gettIng MacOS X > not to overcommit like crazy. Well, this is one of a long list of broken things about OSX. If you want to see *real* breakage, do some IO performance testing of HFS+ FWIW, I have this issue with Mac desktop application

Re: [HACKERS] Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux

On Friday, June 29, 2012 07:07:11 PM Nils Goroll wrote: > > Also, 20 transactions per connection is not enough of a run to make > > any evaluation on. > > As you can see I've repeated the tests 10 times. I've tested slight > variations as mentioned above, so I was looking for quick results with >

Re: [HACKERS] Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux

> You need at the very, very least 10s. ok, thanks. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] change_varattnos_of_a_node versus whole-row Vars

change_varattnos_of_a_node(), which is used to adjust expressions referencing a parent relation or LIKE source relation to refer to the child relation, ignores whole-row Vars (those with attnum zero). Thus, after processing the expression, the whole-row Var still claims to have the rowtype (varty

Re: [HACKERS] Posix Shared Mem patch

Josh Berkus writes: > The other thing which will avoid the problem for most Mac users is if we > simply allocate 10% of RAM at initdb as a default. If we do that, then > 90% of users will never touch Shmem themselves, and not have the > opportunity to mess up. If we could do that on *all* platfo

Re: [HACKERS] Posix Shared Mem patch

Tom, > If we could do that on *all* platforms, I might be for it, but we only > know how to get that number on some platforms. I don't see what's wrong with using it where we can get it, and not using it where we can't. > There's also the issue > of whether we really want to assume that the ma

Re: [HACKERS] Posix Shared Mem patch

Josh Berkus writes: >> If we could do that on *all* platforms, I might be for it, but we only >> know how to get that number on some platforms. > I don't see what's wrong with using it where we can get it, and not > using it where we can't. Because then we still need to define, and document, a

Re: [HACKERS] Posix Shared Mem patch

>> 10% isn't assuming dedicated. > > Really? Yes. As I said, the allocation for dedicated PostgreSQL servers is usually 20% to 25%, up to 8GB. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Posix Shared Mem patch

Josh Berkus writes: >>> 10% isn't assuming dedicated. >> Really? > Yes. As I said, the allocation for dedicated PostgreSQL servers is > usually 20% to 25%, up to 8GB. Any percentage is assuming dedicated, IMO. 25% might be the more common number, but you're still assuming that you can have yo

Re: [HACKERS] Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux

On Fri, Jun 29, 2012 at 12:11 PM, Andres Freund wrote: > On Friday, June 29, 2012 07:07:11 PM Nils Goroll wrote: >> > Also, 20 transactions per connection is not enough of a run to make >> > any evaluation on. >> >> As you can see I've repeated the tests 10 times. I've tested slight >> variations

Re: [HACKERS] [PATCH] lock_timeout and common SIGALRM framework

2012-06-27 10:34 keltezéssel, Boszormenyi Zoltan írta: 2012-06-26 18:49 keltezéssel, Alvaro Herrera írta: Excerpts from Boszormenyi Zoltan's message of mar jun 26 12:43:34 -0400 2012: So, should I keep the enum TimeoutName? Are global variables for keeping dynamically assigned values preferred

Re: [HACKERS] Posix Shared Mem patch

> My idea of "not dedicated" is "I can launch a dozen postmasters on this > machine, and other services too, and it'll be okay as long as they're > not doing too much". Oh, 128MB then? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] new --maintenance-db options

On Sun, Jun 24, 2012 at 01:26:58AM +0300, Peter Eisentraut wrote: > About the new --maintenance-db options: > > What is the purpose of these options? The initial discussion was > unclear on this. The documentation contains no explanation of why they > should be used. If we want to really support

Re: [HACKERS] new --maintenance-db options

On Mon, Jun 25, 2012 at 11:57:36AM -0400, Robert Haas wrote: > In retrospect, it seems as though it might have been a good idea to > make the postgres database read-only and undroppable, so that all > client utilities could count on being able to connect to it and get a > list of databases in the c

Re: [HACKERS] new --maintenance-db options

On Mon, Jun 25, 2012 at 02:58:25PM -0400, Robert Haas wrote: > On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera > wrote: > > Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012: > >> Really, I think > >> pg_upgrade needs this option too, unless we're going to kill the > >> problem

Re: [HACKERS] new --maintenance-db options

On Mon, Jun 25, 2012 at 03:12:00PM -0400, Alvaro Herrera wrote: > > Excerpts from Robert Haas's message of lun jun 25 14:58:25 -0400 2012: > > > > On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera > > wrote: > > > Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012: > > >> Really

Re: [HACKERS] Posix Shared Mem patch

Hi All, In a *very* quick patch I tested using huge pages/MAP_HUGETLB for the mmap'ed memory. That gives around 9.5% performance benefit in a read-only pgbench run (-n -S - j 64 -c 64 -T 10 -M prepared, scale 200, 6GB s_b, 8 cores, 24GB mem). It also saves a bunch of memory per process due to th

Re: [HACKERS] Posix Shared Mem patch

On Fri, Jun 29, 2012 at 2:52 PM, Andres Freund wrote: > Hi All, > > In a *very* quick patch I tested using huge pages/MAP_HUGETLB for the mmap'ed > memory. > That gives around 9.5% performance benefit in a read-only pgbench run (-n -S - > j 64 -c 64 -T 10 -M prepared, scale 200, 6GB s_b, 8 cores,

[HACKERS] elog/ereport noreturn decoration

There is continued interest in static analyzers (clang, coverity), and the main problem with those is that they don't know that elog and ereport with level >= ERROR don't return, leading to lots of false positives. I looked in the archive; there were some attempts to fix this some time ago. One w

Re: [HACKERS] Event Triggers reduced, v1

Hi, Here's an answer to your review (thanks!), with no patch attached yet even if I've been cleanup up most of what you reported. Incremental diff is available for browsing here: https://github.com/dimitri/postgres/compare/f99e8d93b7...8da156dc70 Robert Haas writes: > Some of the pg_dump hunk

Re: [HACKERS] elog/ereport noreturn decoration

Peter Eisentraut writes: > I think the issue here was that if we support two separate code paths, > we still need to do the actually unreachable /* keep compiler happy */ > bits, and that compilers that know about elog not returning would > complain about unreachable code. Yes. The problem with

Re: [HACKERS] Event Triggers reduced, v1

Robert Haas writes: > ../../../src/include/catalog/pg_event_trigger.h:34: error: expected > specifier-qualifier-list before ‘int2’ > > This needs to be changed to int16 as a result of commit > b8b2e3b2deeaab19715af063fc009b7c230b2336. Done as part of the previous work. > alter.c:73: warning: imp

Re: [HACKERS] change_varattnos_of_a_node versus whole-row Vars

I wrote: > change_varattnos_of_a_node(), which is used to adjust expressions > referencing a parent relation or LIKE source relation to refer to the > child relation, ignores whole-row Vars (those with attnum zero). > ... > My inclination, especially in the back branches, is to just throw error >

Re: [HACKERS] Posix Shared Mem patch

On Fri, Jun 29, 2012 at 1:00 PM, Merlin Moncure wrote: > On Fri, Jun 29, 2012 at 2:52 PM, Andres Freund wrote: >> Hi All, >> >> In a *very* quick patch I tested using huge pages/MAP_HUGETLB for the mmap'ed >> memory. >> That gives around 9.5% performance benefit in a read-only pgbench run (-n -S

Re: [HACKERS] foreign key locks

Excerpts from Kevin Grittner's message of mié jun 27 08:40:58 -0400 2012: > Alvaro Herrera wrote: > > > here's fklocks v14, which also merges to new master as there were > > several other conflicts. It passes make installcheck-world now. > > Recent commits broke it again, so here's a rebased

[HACKERS] Can someone help me to get ODBC fdw running on windows?

I've tried to compile ODBC fdw on Win64 with all sort of compilers without success (MingGW, gcc-win32, MS C++2005 32 and 64). I think I'm getting too old for this so many switches, too many dependencies. Could a gently soul help me get back on track, possible providing precompiled binaries that

Re: [HACKERS] elog/ereport noreturn decoration

On 29 June 2012 22:35, Tom Lane wrote: > IOW I am not on board with reducing > the number of warnings in clang by increasing the number everywhere > else. I successfully lobbied the Clang developers to remove some warnings that came from certain sites where we use a single element array at the en

Re: [HACKERS] Support for array_remove and array_replace functions

On Thu, Jun 14, 2012 at 4:41 AM, Marco Nenciarini < marco.nenciar...@2ndquadrant.it> wrote: > Hi, > > following Gabriele's email regarding our previous patch on "Foreign > Key Arrays"[1], I am sending a subset of that patch which includes only > two array functions which will be needed in that pa