Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello Michael, I am planning to continue contributing to this feature in any way be it by reviewing the patch or making one. Though I haven't been able to reply to the comments or post an updated patch lately. I plan to do that soon. Thank you, Rahila On Thu, Nov 19, 2015 at 1:09 PM, Michael

Re: [HACKERS] proposal: LISTEN *

On 11/19/15 4:48 AM, Pavel Stehule wrote: 2015-11-19 4:40 GMT+01:00 Marko Tiikkaja : I've in the past wanted to listen on all notification channels in the current database for debugging purposes. But recently I came across another use case. Since having multiple postgres

Re: [HACKERS] [DESIGN] ParallelAppend

On Thu, Nov 19, 2015 at 12:27 AM, Robert Haas wrote: > > On Wed, Nov 18, 2015 at 7:25 AM, Amit Kapila wrote: > > Don't we need the startup cost incase we need to build partial paths for > > joinpaths like mergepath? > > Also, I think there are

Re: [HACKERS] warning: HS_KEY redefined (9.5 beta2)

On 2015-11-19 01:55, Mike Blackwell wrote: Google says this was present in beta1. ( http://www.postgresql.org/message-id/5596a162.30...@dunslane.net) Still seems broken, at least for me. Built with Perl 5.22. uname -m = x86_64 uname -r = 2.6.32-504.12.2.el6.x86_64 FWIW: Here, Centos 6.6

[HACKERS] Selective logical replication

Hi, I want to use logical replication for implementing multimaster (so all nodes are both sending and receiving changes). But there is one "stupid" problem: how to prevent infinite recursion and not to rereplicate replicated data. I.e. node receives change set from some other node, applies it

Re: [HACKERS] Selective logical replication

On 2015/11/19 17:48, konstantin knizhnik wrote: > Hi, > > I want to use logical replication for implementing multimaster (so all nodes > are both sending and receiving changes). > But there is one "stupid" problem: how to prevent infinite recursion and not > to rereplicate replicated data. >

[HACKERS] Typo in file header comment of replorigindesc.c

Attached fixes $SUBJECT: s/replication_origin.c/origin.c/g Thanks, Amit diff --git a/src/backend/access/rmgrdesc/replorigindesc.c b/src/backend/access/rmgrdesc/replorigindesc.c index 60cf0f6..479e3b4 100644 --- a/src/backend/access/rmgrdesc/replorigindesc.c +++

Re: [HACKERS] [DESIGN] ParallelAppend

On Thu, Nov 19, 2015 at 1:29 PM, Amit Kapila wrote: > > On Thu, Nov 19, 2015 at 12:27 AM, Robert Haas wrote: > - > Is the main reason to have add_partial_path() is that it has some > less checks or is it that current add_path will give wrong

Re: [HACKERS] Selective logical replication

On Thu, Nov 19, 2015 at 5:48 PM, konstantin knizhnik wrote: > I want to use logical replication for implementing multimaster (so all nodes > are both sending and receiving changes). > But there is one "stupid" problem: how to prevent infinite recursion and not > to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add --synchronous option to pg_receivexlog, for more reliable WA

On 9/15/15 11:04 PM, Fujii Masao wrote: > If --slot option is specified, pg_receivexlog reports a flush position to > the server even though --synchronous is not specified. So users might think > that --synchrnous option is not necessary for synchronous pg_receivexlog > setting. But that's not

Re: [HACKERS] [DESIGN] ParallelAppend

On Thu, Nov 19, 2015 at 2:59 AM, Amit Kapila wrote: > On Thu, Nov 19, 2015 at 12:27 AM, Robert Haas wrote: >> >> On Wed, Nov 18, 2015 at 7:25 AM, Amit Kapila >> wrote: >> > Don't we need the startup cost incase we need to

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote: > On November 19, 2015 8:09:38 AM PST, Robert Haas > wrote: >>On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev >> wrote: >>> The moving base tranches to shared

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Nov 18, 2015 at 5:22 PM, Greg Stark wrote: > On Wed, Nov 18, 2015 at 11:29 PM, Peter Geoghegan wrote: >> Other systems expose this explicitly, and, as I said, say in an >> unqualified way that a multi-pass merge should be avoided. Maybe the >> warning

Re: [HACKERS] COPY (INSERT/UPDATE/DELETE .. RETURNING ..)

On Thu, Nov 19, 2015 at 9:22 PM, Marko Tiikkaja wrote: > Of course, something might break if we added a new statement type which > supported RETURNING, but I'm really not worried about that. I'm not dead > set against adding some Assert(IsA()) calls here, but I don't see the point.

Re: [HACKERS] proposal: LISTEN *

Alvaro Herrera writes: > Marko Tiikkaja wrote: >> On the test server I'm running on, it doesn't look quite as bad as the >> profiles we had in production, but s_lock is still the worst offender in the >> profiles, called from: >> >> - 80.33% LWLockAcquire >> + 48.34%

Re: [HACKERS] Typo in file header comment of replorigindesc.c

On Thu, Nov 19, 2015 at 5:04 AM, Amit Langote wrote: > Attached fixes $SUBJECT: > > s/replication_origin.c/origin.c/g Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Typo in file header comment of replorigindesc.c

On 2015-11-20 10:25:20 +0900, Amit Langote wrote: > On 2015/11/20 10:24, Robert Haas wrote: > > On Thu, Nov 19, 2015 at 5:04 AM, Amit Langote > > wrote: > >> Attached fixes $SUBJECT: > >> > >> s/replication_origin.c/origin.c/g > > > > Committed. Thanks Robert and

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Nov 19, 2015 at 5:32 PM, Greg Stark wrote: > Hm. Have you tested a nearly-sorted input set around 1.5x the size of > work_mem? That should produce a single run using the heap to generate > runs but generate two runs if, AIUI, you're just filling work_mem, > running

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2015/11/20 0:57, Jim Nasby wrote: > On 11/19/15 1:18 AM, Amit Langote wrote: >> 1) General purpose interface for (maintenance?) commands to report a set > > I'm surprised no one has picked up on using this for DML. Certainly anyone > works with ETL processes would love to be able to get some

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Nov 19, 2015 at 2:53 PM, Peter Geoghegan wrote: > The latter 16MB work_mem example query/table is still faster with a > 12MB work_mem than master, even with multiple passes. Quite a bit > faster, in fact: about 37 seconds on master, to about 24.7 seconds > with the

Re: [HACKERS] Typo in file header comment of replorigindesc.c

On 2015/11/20 10:24, Robert Haas wrote: > On Thu, Nov 19, 2015 at 5:04 AM, Amit Langote > wrote: >> Attached fixes $SUBJECT: >> >> s/replication_origin.c/origin.c/g > > Committed. Thanks! Amit -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Using quicksort for every external sort run

On Fri, Nov 20, 2015 at 12:54 AM, Peter Geoghegan wrote: > * One run can be created with replacement selection, where a > hyrbid-sort merge strategy needs to create and then merge many runs. > When I started work on this patch, I was pretty sure that case would > be noticeably

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/20 6:57, Robert Haas wrote: On Wed, Nov 18, 2015 at 10:54 PM, Etsuro Fujita wrote: Noted, but let's do it that way and move on. It would be a shame if we didn't end up with a working FDW join pushdown system in 9.6 because of a disagreement on this

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Nov 18, 2015 at 6:19 PM, Robert Haas wrote: > On Wed, Nov 18, 2015 at 6:29 PM, Peter Geoghegan wrote: >> In principle, I have no problem with doing that. Through testing, I >> cannot see any actual upside, though. Perhaps I just missed something.

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Nov 19, 2015 at 8:35 PM, Greg Stark wrote: > Hm. So a bit of back-of-envelope calculation. If we have want to > buffer at least 1MB for each run -- I think we currently do more > actually -- and say that a 1GB work_mem ought to be enough to run > reasonably (that's per sort

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On 2015-11-19 14:58:05 -0500, Robert Haas wrote: > On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote: > > It's really not particularly convenient to allocate tranches right > > now. You have to store at least the identifier in shared memory and > > then redo the

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 11/19/15 11:05 AM, Robert Haas wrote: > On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera > wrote: >> In my days of Perl, it was starting to become frowned upon to call >> subroutines without parenthesizing arguments. Is that no longer the >> case? Because I notice

Re: [HACKERS] Using quicksort for every external sort run

On 19 November 2015 at 01:22, Greg Stark wrote: > Perhaps the right thing to do is report a statistic to pg_stats so > DBAs can see how often sorts are in memory, how often they're on disk, > and how often the on disk sort requires n passes. That would put them > in the same

Re: [HACKERS] Bug in numeric multiplication

On 18 November 2015 at 22:19, Tom Lane wrote: > A bit of progress on this: I've found a test case, namely > > select sqrt(99... > Wow. > Still, this proves that we are onto a real problem. > Agreed. I had a go at turning that example into something using log(base, num)

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Nov 19, 2015 at 6:56 PM, Peter Geoghegan wrote: > Yes, I really do mean it when I say that the DBA is not supposed to > see this message, no matter how much or how little memory or data is > involved. There is no nuance intended here; it isn't sensible to allow > a

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Nov 19, 2015 at 12:35 PM, Greg Stark wrote: > So I think you're kind of right and kind of wrong. The vast majority > of use cases are either sub 1TB or are in work environments designed > specifically for data warehouse queries where a user can obtain much > more memory for

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Wed, Nov 18, 2015 at 10:54 PM, Etsuro Fujita wrote: >> Noted, but let's do it that way and move on. It would be a shame if >> we didn't end up with a working FDW join pushdown system in 9.6 >> because of a disagreement on this point. > > Another idea would be to

Re: [HACKERS] Error with index on unlogged table

On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown wrote: > On 27 March 2015 at 04:54, Kyotaro HORIGUCHI > wrote: >> Hello, >> >> At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund >> wrote in

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Nov 19, 2015 at 4:26 PM, Andres Freund wrote: > On 2015-11-19 14:58:05 -0500, Robert Haas wrote: >> On Thu, Nov 19, 2015 at 11:30 AM, Andres Freund wrote: >> > It's really not particularly convenient to allocate tranches right >> > now. You have to

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Thu, Nov 19, 2015 at 6:39 AM, Kouhei Kaigai wrote: > So, are you suggesting to make a patch that allows ForeignScan to have > multiple sub-plans right now? Or, one sub-plan? Two:

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Nov 19, 2015 at 2:35 PM, Robert Haas wrote: > OK, so reversing this analysis, with the default work_mem of 4MB, we'd > need a multi-pass merge for more than 235MB/4 = 58MB of data. That is > very, very far from being a can't-happen scenario, and I would not at >

[HACKERS] ROLES and ALTER DEFAULT PRIVILEGES

Folks, The docs for ALTER DEFAULT PRIVILEGES state: You can change default privileges only for objects that will be created by yourself or by roles that you are a member of. but I have not been able to reproduce the "or by roles that you are a member of" part. The attached script

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Nov 19, 2015 at 3:43 PM, Peter Geoghegan wrote: >> I'd be interested in seeing this analysis in some detail. > > Sure. Jeff mentioned 8MB as a work_mem setting, so let's examine a > case where that's the work_mem setting, and see experimentally where > the crossover point

Re: [HACKERS] Bug in numeric multiplication

Dean Rasheed writes: > On 18 November 2015 at 22:19, Tom Lane wrote: >> Still, this proves that we are onto a real problem. > Agreed. I had a go at turning that example into something using > log(base, num) so that the result would be visible in a

Re: [HACKERS] COPY (INSERT/UPDATE/DELETE .. RETURNING ..)

On Thu, Nov 19, 2015 at 11:04 AM, Marko Tiikkaja wrote: > This was discussed in 2010 when CTEs got the same treatment, and I agree > with what was decided back then. If someone needs to make PreparableStmt > different from what COPY and CTEs support, we can split them up. But > they're

[HACKERS] pgbench unusable after crash during pgbench

Hi, I'm using git master, and if I crash the database whilst it's running pgbench, then restart the database and try to run pgbench again, I can't: thom@swift:~/Development/postgresql$ pgbench -c 1 -j 1 -T 20 -S pgbench ...crash database... connection to database "pgbench" failed: could not

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On Tue, Nov 17, 2015 at 10:22 PM, Kouhei Kaigai wrote: > > Apart from EPQ rechecks, the above aggressive push-down idea allows to send > > contents of multiple relations to the remote side. In this case, ForeignScan > > needs to have multiple sub-plans. > > > > For

Re: [HACKERS] Error with index on unlogged table

On 27 March 2015 at 04:54, Kyotaro HORIGUCHI wrote: > Hello, > > At Thu, 26 Mar 2015 18:50:24 +0100, Andres Freund > wrote in <20150326175024.gj...@alap3.anarazel.de> >> I think the problem here is that the *primary* makes no such >>

Re: [HACKERS] COPY (INSERT/UPDATE/DELETE .. RETURNING ..)

On 11/19/15 1:17 PM, Michael Paquier wrote: On Thu, Nov 19, 2015 at 11:04 AM, Marko Tiikkaja wrote: Further, if someone's going to add new stuff to PreparableStmt, she should probably think about whether it would make sense to add it to COPY and CTEs from day one, too, and in that case not

Re: [HACKERS] warning: HS_KEY redefined (9.5 beta2)

Alvaro Herrera writes: > Erik Rijkers wrote: >> make contrib: >> In file included from hstore_plperl.c:6:0: >> ../../contrib/hstore/hstore.h:79:0: warning: "HS_KEY" redefined >> #define HS_KEY(arr_,str_,i_) ((str_) + HSE_OFF((arr_)[2*(i_)])) > So we need to get this one

Re: [HACKERS] proposal: LISTEN *

Marko Tiikkaja writes: > I've in the past wanted to listen on all notification channels in the > current database for debugging purposes. But recently I came across > another use case. Since having multiple postgres backends listening for > notifications is very inefficient

[HACKERS] Minor ON CONFLICT comment tweak

Attached patch fixes minor issue with an ON CONFLICT DO UPDATE comment. -- Peter Geoghegan diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c index dabaea9..119061e 100644 --- a/src/backend/executor/nodeModifyTable.c +++

Re: [HACKERS] Parallel Seq Scan

On Thu, Nov 19, 2015 at 9:29 PM, Robert Haas wrote: > > On Wed, Nov 18, 2015 at 10:41 PM, Amit Kapila wrote: > > I think whats going on here is that when any of the session doesn't > > get any workers, we shutdown the Gather node which internally

Re: [HACKERS] documentation for wal_retrieve_retry_interval

On Fri, Nov 20, 2015 at 1:33 AM, Peter Eisentraut wrote: > There is no documentation what use case the new (in 9.5) parameter > wal_retrieve_retry_interval is for. The commit message > (5d2b45e3f78a85639f30431181c06d4c3221c5a1) alludes to something, but > even that is not clear,

Re: [HACKERS] [DESIGN] ParallelAppend

On Fri, Nov 20, 2015 at 1:25 AM, Robert Haas wrote: > > On Thu, Nov 19, 2015 at 2:59 AM, Amit Kapila wrote: > > Won't it be useful to consider parameterized paths for below kind of > > plans where we can push the jointree to worker and each worker

Re: [HACKERS] pgbench unusable after crash during pgbench

On Thu, Nov 19, 2015 at 6:03 AM, Thom Brown wrote: > I'm using git master, and if I crash the database whilst it's running > pgbench, then restart the database and try to run pgbench again, I > can't: > > thom@swift:~/Development/postgresql$ pgbench -c 1 -j 1 -T 20 -S pgbench >

Re: [HACKERS] GIN pending list clean up exposure to SQL

Alvaro Herrera wrote: > Jeff Janes wrote: > > I've written a function which allows users to clean up the pending list. > > It takes the index name and returns the number of pending list pages > > deleted. > > I just noticed that your patch uses AccessShareLock on the index. Is > that okay? I

Re: [HACKERS] [PROPOSAL] TAP test example

Jim Nasby writes: > On 11/19/15 9:57 AM, Tom Lane wrote: >> Agreed. We aren't going to accept any core tests that depend on DBI/DBD. >> Now, that might be a fine example for tests written to test something that >> uses Postgres ... but not as an example of how to write

Re: [HACKERS] [PROPOSAL] TAP test example

В письме от 19 ноября 2015 10:57:27 пользователь Tom Lane написал: > Nikolay Shaplov writes: > > But this is not the issue. We can change it any way we like. The question > > do we need such example at all, or no? > > I'm kind of -1 on the idea of a module that doesn't

Re: [HACKERS] proposal: LISTEN *

Marko Tiikkaja writes: > On 11/19/15 4:21 PM, Tom Lane wrote: >> ... and then you gotta get the notifications to the clients, so it seems >> like this just leaves the performance question hanging. > I'm not sure which performance question you think is left hanging. If > every

[HACKERS] documentation for wal_retrieve_retry_interval

There is no documentation what use case the new (in 9.5) parameter wal_retrieve_retry_interval is for. The commit message (5d2b45e3f78a85639f30431181c06d4c3221c5a1) alludes to something, but even that is not clear, and obviously in the wrong place. Could we come up with something more to put

Re: [HACKERS] proposal: LISTEN *

Marko Tiikkaja wrote: > On the test server I'm running on, it doesn't look quite as bad as the > profiles we had in production, but s_lock is still the worst offender in the > profiles, called from: > > - 80.33% LWLockAcquire > + 48.34% asyncQueueReadAllNotifications > + 23.09%

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On November 19, 2015 8:09:38 AM PST, Robert Haas wrote: >On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev > wrote: >> The moving base tranches to shared memory has been discussed many >times. >> The point is using them later in

Re: [HACKERS] GIN pending list clean up exposure to SQL

On 12 August 2015 at 20:19, Jeff Janes wrote: > > But where does this belong? Core? Its own separate extension? > I will say core. Gin indexes are in core and i don't see why this function shouldn't. FWIW, brin indexes has a similar function brin_summarize_new_values() in

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

> On Mon, Nov 16, 2015 at 9:03 PM, Kouhei Kaigai wrote: > > I guess we will put a pointer to static ExtensibleNodeMethods structure > > on ForeignScan, CustomScan, CustomScanState and etc... > > I think that makes it confusing. What I'd prefer to do is have only > the name

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On Thu, Nov 19, 2015 at 6:39 AM, Kouhei Kaigai wrote: > > So, are you suggesting to make a patch that allows ForeignScan to have > > multiple sub-plans right now? Or, one sub-plan? > > Two: > > http://www.postgresql.org/message-id/CA+TgmoYZeje+ot1kX4wdoB7R7DPS0CWXAzfqZ-

Re: [HACKERS] Error with index on unlogged table

On Fri, Nov 20, 2015 at 7:03 AM, Robert Haas wrote: > On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown wrote: >> This bug still exists. > > Hmm. This probably should have been on the open items list. I have added an open item for 9.5. That's not a cool bug to

Re: [HACKERS] [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change

On Wed, Nov 18, 2015 at 12:32 AM, Haribabu Kommi wrote: > On Wed, Nov 18, 2015 at 6:02 AM, Robert Haas wrote: >> On Mon, Nov 16, 2015 at 4:27 AM, Marti Raudsepp wrote: >>> Thank you so much for the review and patch update. I

Re: [HACKERS] Foreign Data Wrapper

Inspecting the multicorn source was helpful. For the purposes of anyone searching the mailing lists, I needed to access the quals natively. The code that helped me figure out how to do this was in the native odbc fdw here: https://github.com/ZhengYang/odbc_fdw/blob/master/odbc_fdw.c particularly

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 11/19/15 1:18 AM, Amit Langote wrote: 1) General purpose interface for (maintenance?) commands to report a set I'm surprised no one has picked up on using this for DML. Certainly anyone works with ETL processes would love to be able to get some clue on the status of a long running

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera wrote: > In my days of Perl, it was starting to become frowned upon to call > subroutines without parenthesizing arguments. Is that no longer the > case? Because I notice there are many places in this patch and pre- >

Re: [HACKERS] proposal: LISTEN *

On 11/19/15 4:21 PM, Tom Lane wrote: Marko Tiikkaja writes: I've in the past wanted to listen on all notification channels in the current database for debugging purposes. But recently I came across another use case. Since having multiple postgres backends listening for

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev wrote: > The moving base tranches to shared memory has been discussed many times. > The point is using them later in pg_stat_activity and other monitoring > views. I'm not in agreement with this idea. Actually,

Re: [HACKERS] [PROPOSAL] TAP test example

On 11/19/15 8:42 AM, Nikolay Shaplov wrote: +sub psql_ok +{ + my $db = shift; + my $sql = shift; + my $comment = shift; Isn't the preferred method of parameter assignment to use @_? Also, I'd think one of the examples should use DBI, since presumably one of the big benefits

Re: [HACKERS] [PROPOSAL] TAP test example

В письме от 19 ноября 2015 09:39:41 пользователь Jim Nasby написал: > On 11/19/15 8:42 AM, Nikolay Shaplov wrote: > > +sub psql_ok > > +{ > > + my $db = shift; > > + my $sql = shift; > > + my $comment = shift; > > Isn't the preferred method of parameter assignment to use @_? Hm... it is the

Re: [HACKERS] GIN pending list clean up exposure to SQL

Jeff Janes wrote: > I've written a function which allows users to clean up the pending list. > It takes the index name and returns the number of pending list pages > deleted. I just noticed that your patch uses AccessShareLock on the index. Is that okay? I would have assumed that you'd need

Re: [HACKERS] [PROPOSAL] TAP test example

Nikolay Shaplov writes: > But this is not the issue. We can change it any way we like. The question do > we need such example at all, or no? I'm kind of -1 on the idea of a module that doesn't actually do something *useful*. Let's write some actual tests instead, and

Re: [HACKERS] Parallel Seq Scan

On Wed, Nov 18, 2015 at 10:41 PM, Amit Kapila wrote: > I think whats going on here is that when any of the session doesn't > get any workers, we shutdown the Gather node which internally destroys > the dynamic shared memory segment as well. However the same is > needed

Re: [HACKERS] [PROPOSAL] TAP test example

On 11/19/15 9:57 AM, Tom Lane wrote: >I wrote this example based on ssl TAP test. There was no DBI there. And I >think it was done for purpose. If we add DBI to tests, then we should add it >to build dependencies. And it is not a good idea, and so not a good example. Agreed. We aren't going to

Re: [HACKERS] SPI and transactions

On Wed, Nov 18, 2015 at 5:18 AM, Konstantin Knizhnik wrote: > Hello, > > SPI was originally developed for execution SQL statements from C user > defined functions in context of existed transaction. > This is why it is not possible to execute any transaction manipulation

Re: [HACKERS] GIN pending list clean up exposure to SQL

On 19 November 2015 at 14:18, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Jeff Janes wrote: >> > I've written a function which allows users to clean up the pending list. >> > It takes the index name and returns the number of pending list pages >> > deleted. >> >> I

Re: [HACKERS] pgbench unusable after crash during pgbench

Thom Brown writes: > On 19 November 2015 at 16:11, Robert Haas wrote: >> The only explanation I can think of here is that pgbench on startup >> queries one of the tables to figure out the scale factor, and it seems >> to be coming up with scaling factor 0,

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Nov 19, 2015 at 10:05 AM, Robert Haas wrote: > On Wed, Nov 18, 2015 at 10:21 AM, Alvaro Herrera > wrote: > > In my days of Perl, it was starting to become frowned upon to call > > subroutines without parenthesizing arguments. Is that no

Re: [HACKERS] proposal: LISTEN *

On 11/19/15 5:32 PM, Tom Lane wrote: Marko Tiikkaja writes: On 11/19/15 4:21 PM, Tom Lane wrote: ... and then you gotta get the notifications to the clients, so it seems like this just leaves the performance question hanging. I'm not sure which performance question you think

Re: [HACKERS] pgbench unusable after crash during pgbench

On 19 November 2015 at 16:11, Robert Haas wrote: > On Thu, Nov 19, 2015 at 6:03 AM, Thom Brown wrote: >> I'm using git master, and if I crash the database whilst it's running >> pgbench, then restart the database and try to run pgbench again, I >> can't: >>

Re: [HACKERS] GIN pending list clean up exposure to SQL

On 19 November 2015 at 14:47, Jaime Casanova wrote: > On 19 November 2015 at 14:18, Alvaro Herrera wrote: >> Alvaro Herrera wrote: >>> Jeff Janes wrote: >>> > I've written a function which allows users to clean up the pending list. >>> >

Re: [HACKERS] Additional role attributes && superuser review

On 11/19/15 2:13 AM, Michael Paquier wrote: > On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote: >> * Michael Paquier (michael.paqu...@gmail.com) wrote: >>> It seems weird to not have a dedicated role for pg_switch_xlog. >> >> I didn't add a pg_switch_xlog default role in this patch series, but

Re: [HACKERS] warning: HS_KEY redefined (9.5 beta2)

Erik Rijkers wrote: > In file included from ../../../src/include/postgres.h:48:0, > from plperl.c:8: > plperl.c: In function ‘select_perl_context’: > ../../../src/include/utils/elog.h:41:16: warning: passing argument 1 of > ‘errmsg’ makes pointer from integer without a cast

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

Thank you for the review. I've made changes according to your comments. I don't stick on current names in the patch. I've removed all unnecerrary indirections, and added cache aligning to LWLock arrays. On Tue, 17 Nov 2015 19:36:13 +0100 "and...@anarazel.de" wrote: > On

[HACKERS] [PROPOSAL] TAP test example

Don't we need a simple example of TAP tests in src/test ? Something that test a trivial feature, but shows basic testing tricks? While explaining to my friends how does TAP test works I wrote an example TAP test. May be we we should add it to the core with sensible README explanation? --

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Nov 19, 2015 at 5:54 AM, Jeff Janes wrote: > On Wed, Nov 18, 2015 at 11:18 AM, Jeff Janes wrote: >> >> I get an error when running pg_upgrade from 9.4 to 9.6-this >> >> error while copying relation "mediawiki.archive" >>