[HACKERS] problem with msvc linker - cannot build orafce

Hi I am trying to build Orafce and I have problem due access to exported variable session_timezone. The build fails with message: 1> Creating library C:\Users\Pavel\orafce-VERSION_3_1_2\orafce-VERSION_3_1_2\msvc\/bin/x64/9.4/lib/orafce.lib and object

Re: [HACKERS] Rework the way multixact truncations work

On Sun, Nov 8, 2015 at 11:52 AM, Noah Misch wrote: >> I'm not following along right now - in order to make cleanups the plan is to >> revert a couple commits and then redo them prettyfied? > > Yes, essentially. Given the volume of updates, this seemed neater than > framing

[HACKERS] New email address

Yahoo recently changed their DMARC policy, and after some investigation and a support case with Yahoo, it is now clear that their email systems can no longer be used with the postgresql.org lists. I've migrated from kgri...@ymail.com to kgri...@gmail.com. In the process I noticed that some

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 24/11/15 06:31, Pavel Stehule wrote: 2015-11-23 18:04 GMT+01:00 Tom Lane >: Jim Nasby writes: > On 11/23/15 3:11 AM, Corey Huinker wrote: >> +1 to both pg_size_bytes() and ::bytesize. Both contribute to

Re: [HACKERS] Declarative partitioning

Robert Haas wrote: > I support building incrementally, but I don't see why we want to > change the catalog structure and then change it again. That seems > like it makes the project more work, not less. I agree with what you say. I thought you were saying that the implementation had to provide

Re: [HACKERS] problem with msvc linker - cannot build orafce

Pavel Stehule writes: > I am trying to build Orafce and I have problem due access to exported > variable session_timezone. > Any idea what can be broken? Lack of PGDLLIMPORT on the extern declaration, no doubt. The fact that we've not heard this before implies that

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Sun, Nov 22, 2015 at 11:24 PM, Pavel Stehule wrote: > > > 2015-11-22 23:54 GMT+01:00 Corey Huinker : > >> What about pg_size_unpretty()? >>> >> I was going to suggest pg_size_ugly(), but unpretty does emphasize the >> inverse (rather than

Re: [HACKERS] onlyvalue aggregate (was: First Aggregate Funtion?)

On Wed, Oct 28, 2015 at 5:03 PM, Marko Tiikkaja wrote: > SELECT a, sum(amount), onlyvalue(rolling_count) > FROM > ( > SELECT a, amount, count(*) OVER (ORDER BY a) AS rolling_count > FROM tbl > ) ss > GROUP BY a; The same thing would happen even in the more common case of

Re: [HACKERS] [DESIGN] ParallelAppend

On Fri, Nov 20, 2015 at 7:06 PM, Robert Haas wrote: > > On Fri, Nov 20, 2015 at 12:45 AM, Amit Kapila wrote: > > Okay, but I think that's not what I am talking about. I am talking about > > below code in cost_seqscan: > > > > - if (nworkers > 0) >

Re: [HACKERS] onlyvalue aggregate (was: First Aggregate Funtion?)

On 21 November 2015 at 03:54, Marko Tiikkaja wrote: > Here's v2 of the patch. How's this look? > Here are some initial review comments: * My first thought on reading this patch is that it is somewhat under-commented. For example, I would expect at least a block comment at the top

Re: [HACKERS] Identify user requested queries

On 23 November 2015 at 13:27, Praveen M wrote: > Hi All, > > When the user attempts to make a connection with the database , the code > will look into various pg_catalog tables internally. However the user also > can query the pg_catalog tables. Is there a way to identify the

Re: [HACKERS] documentation for wal_retrieve_retry_interval

On 11/19/15 11:26 PM, Michael Paquier wrote: > 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)

Re: [HACKERS] Declarative partitioning

On Mon, Nov 23, 2015 at 1:44 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> I support building incrementally, but I don't see why we want to >> change the catalog structure and then change it again. That seems >> like it makes the project more work, not less. > > I

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Mon, Nov 23, 2015 at 1:47 PM, Alvaro Herrera wrote: > Pavel Stehule wrote: > >> so pg_size_bytes is good enough for everybody? > > That seems good enough to me. > > I would have it accept GiB and GB and have both transform to base 2, and > have an optional boolean

[HACKERS] parallelism and sorting

Hi, I've been thinking about how parallelism interacts with sorting over the last few days and I wanted to share a few preliminary thoughts. I definitely don't have all the answers worked out here yet, so thoughts are welcome. But here are a few observations: 1. Parallel sort is useful but

Re: [HACKERS] parallelism and sorting

On Mon, Nov 23, 2015 at 05:01:43PM -0500, Robert Haas wrote: > Hi, > > [snip] > > If we had a Parallel Index Scan which worked like a Parallel Seq > Scan, That sounds like a very handy thing to have. Any idea whether it's possible for 9.6? Is there any of the Parallel Seq Scan code that looks

[HACKERS] Optimizing away second VACUUM heap scan when only BRIN indexes on table

The BRIN README notes: """ Since no heap TIDs are stored in a BRIN index, it's not necessary to scan the index when heap tuples are removed. It might be that some summary values can be tightened if heap tuples have been deleted; but this would represent an optimization opportunity only, not a

Re: [HACKERS] problem with msvc linker - cannot build orafce

On 11/23/15 15:14, Tom Lane wrote: > Pavel Stehule writes: >> I am trying to build Orafce and I have problem due access to exported >> variable session_timezone. >> Any idea what can be broken? > > Lack of PGDLLIMPORT on the extern declaration, no doubt. > > The fact

Re: [HACKERS] Identify user requested queries

Hi Craig, Thanks for the input. I guess i need to read more code and see if it is achievable. I started looking into the code very recently. Your inputs is very valuable to me. Thanks. Yes I am trying to do something similar to multi-tenancy. I will look at the row level security. Thanks

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

Thanks for the review. On Tue, Nov 24, 2015 at 6:15 AM, Alvaro Herrera wrote: > I just noticed that RecoveryTest.pm is lacking "use strict; use > warnings;". With those added, there's a number of problems reported: > Most of them are easily fixable by adding the

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

On Tue, Nov 24, 2015 at 6:27 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Thu, Nov 19, 2015 at 12:21 AM, Alvaro Herrera >> wrote: > >> > Hi, I just started looking this over a bit. The first thing I noticed >> > is that it adds a

[HACKERS] Minor comment edits in nodeGather.c

While going through nodeGather.c, I noticed portions of the file header comment that may have been obsoleted by recent revisions of the relevant parellelism code. For example, there is a reference to PartialSeqScan node which did not make it into the tree. Attached fixes it. Also, wondering if the

Re: [HACKERS] New email address

On Nov 24, 2015 01:05, "Michael Paquier" wrote: > > On Tue, Nov 24, 2015 at 3:41 AM, Kevin Grittner wrote: > > Yahoo recently changed their DMARC policy, and after some > > investigation and a support case with Yahoo, it is now clear that > > their

Re: [HACKERS] documentation for wal_retrieve_retry_interval

On Mon, Nov 23, 2015 at 11:25 PM, Peter Eisentraut wrote: > Sounds good. Thanks! Great. Thanks for considering it! -- Michael -- 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] parallelism and sorting

On Mon, Nov 23, 2015 at 5:38 PM, David Fetter wrote: > That sounds like a very handy thing to have. Any idea whether it's > possible for 9.6? Is there any of the Parallel Seq Scan code that > looks like it could be reused or slightly generalized for the > implementation? I

Re: [HACKERS] New email address

On Tue, Nov 24, 2015 at 3:41 AM, Kevin Grittner wrote: > Yahoo recently changed their DMARC policy, and after some > investigation and a support case with Yahoo, it is now clear that > their email systems can no longer be used with the postgresql.org > lists. I've migrated

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On Fri, Nov 20, 2015 at 12:11 AM, Kouhei Kaigai wrote: > >> 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

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/24 2:41, Robert Haas wrote: On Fri, Nov 20, 2015 at 12:11 AM, Kouhei Kaigai wrote: One subplan means FDW driver run an entire join sub-tree with local alternative sub-plan; that is my expectation for the majority case. What I'm imagining is that we'd add

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/20 22:45, Kouhei Kaigai wrote: I wrote: * This patch means we can define fdw_recheck_quals even for the case of foreign tables with non-NIL fdw_scan_tlist. However, we discussed in another thread [1] that such foreign tables might break EvalPlanQual tests. Where are we on that

Re: [HACKERS] parallelism and sorting

On Mon, Nov 23, 2015 at 2:01 PM, Robert Haas wrote: > I've been thinking about how parallelism interacts with sorting over > the last few days and I wanted to share a few preliminary thoughts. I > definitely don't have all the answers worked out here yet, so thoughts > are

Re: [HACKERS] New email address

Le 24 nov. 2015 01:05, "Michael Paquier" a écrit : > > On Tue, Nov 24, 2015 at 3:41 AM, Kevin Grittner wrote: > > Yahoo recently changed their DMARC policy, and after some > > investigation and a support case with Yahoo, it is now clear that > >

Re: [HACKERS] parallelism and sorting

On Mon, Nov 23, 2015 at 8:45 PM, Peter Geoghegan wrote: >> 2. Within parallel query, there are two reasons to care about data >> that is in sorted order. First, we might need to deliver the results >> to the user in a particular order, because they've specified ORDER BY >>

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/11/09 9:26, Kouhei Kaigai wrote: The attached patch is an adjusted version of the previous one. There seems to be no changes to make_foreignscan. Is that OK? Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Tue, Dec 10, 2013 at 1:30 AM, Peter Geoghegan wrote: > pg_stat_statements' fingerprinting logic considers the following two > statements as distinct: > > select 1 in (1, 2, 3); > select 1 in (1, 2, 3, 4); > > This is because the ArrayExpr jumble case jumbles any ArrayExpr's

Re: [HACKERS] custom function for converting human readable sizes to bytes

Jim Nasby writes: > On 11/23/15 3:11 AM, Corey Huinker wrote: >> +1 to both pg_size_bytes() and ::bytesize. Both contribute to making the >> statements more self-documenting. > The function seems like overkill to me if we have the type. Just my > opinion though. I'm

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

On Fri, Nov 20, 2015 at 6:53 AM, Ildus Kurbangaliev wrote: > We keep limited number of LWLocks in base shared memory, why not keep > their thanches in shared memory too? Other tranches can be in local > memory, we just have to save somewhere highest id of these

Re: [HACKERS] Declarative partitioning

On Fri, Nov 20, 2015 at 6:44 AM, Alvaro Herrera wrote: > Amit Langote wrote: >> On Fri, Nov 20, 2015 at 7:20 PM, Simon Riggs wrote: >> > Drop it?? I think he means "in this initial patch", right Amit L ? >> >> Yes, there was some notion of

Re: [HACKERS] custom function for converting human readable sizes to bytes

Pavel Stehule wrote: > so pg_size_bytes is good enough for everybody? That seems good enough to me. I would have it accept GiB and GB and have both transform to base 2, and have an optional boolean flag whose non-default value turns the GB interpretation into base 10, leaving the GiB

Re: [HACKERS] [PROPOSAL] Inputs on forcing VACUUM VERBOSE to write timestamp

On 9/3/15 1:50 PM, Jeff Janes wrote: Unconvinced - sounds like you're just re-inventing log_line_prefix. Many times I've wanted a client_log_line_prefix. If someone wants to invent that, I'd second it. It would be pretty awkward to have to turn that on and off to run a manual vacuum,

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

On 9/4/15 7:04 AM, Thom Brown wrote: But shouldn't we not be creating FSM or VM files when truncating? Maybe, but even then you still need to create a bunch of new files (at least one for the table and one for each index), and AFAIK the first page in each file will be properly initialized,

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 11/23/15 3:11 AM, Corey Huinker wrote: +1 to both pg_size_bytes() and ::bytesize. Both contribute to making the statements more self-documenting. The function seems like overkill to me if we have the type. Just my opinion though. I'm thinking the type could just be called 'size' too (or

Re: [HACKERS] [DESIGN] ParallelAppend

On Mon, Nov 23, 2015 at 7:45 AM, Amit Kapila wrote: > Without this patch, that 0.5 (or 50% of leaders effort) is considered for > Gather node irrespective of the number of workers or other factors, but > I think with Patch that is no longer true and that's what I am

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Fri, Nov 20, 2015 at 12:11 AM, Kouhei Kaigai wrote: >> 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] custom function for converting human readable sizes to bytes

2015-11-23 18:04 GMT+01:00 Tom Lane : > Jim Nasby writes: > > On 11/23/15 3:11 AM, Corey Huinker wrote: > >> +1 to both pg_size_bytes() and ::bytesize. Both contribute to making the > >> statements more self-documenting. > > > The function seems like

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

On Sat, Nov 21, 2015 at 12:38 AM, Jim Nasby wrote: > On 11/19/15 7:29 PM, Amit Langote wrote: >>> >>> Another option is to provide the means for the index scan routines to >>> >report their progress. Maybe every index AM won't use it, but it'd >>> >certainly be a lot

Re: [HACKERS] [PATCH] SQL function to report log message

Hi All, On Tue, Nov 17, 2015 at 12:10 PM, Peter Eisentraut wrote: > On 11/17/15 2:16 AM, Jim Nasby wrote: > > On 11/15/15 10:56 PM, dinesh kumar wrote: > >> So, shall we make this pg_report_log TO pg_write_log OR pg_ereport OR > >> from you. > > > > Why not pg_raise to mirror

Re: [HACKERS] more RLS oversights

Noah, * Noah Misch (n...@leadboat.com) wrote: > On Tue, Jul 28, 2015 at 04:04:29PM -0700, Joe Conway wrote: > > Pushed to HEAD and 9.5 > > I reviewed this commit, f781a0f "Create a pg_shdepend entry for each role in > TO clause of policies." Thanks for the review! > This commit rendered the

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

I just noticed that RecoveryTest.pm is lacking "use strict; use warnings;". With those added, there's a number of problems reported: Global symbol "%datadir_nodes" requires explicit package name at /pgsql/source/master/src/test/perl/RecoveryTest.pm line 66. Global symbol "%backup_nodes"

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

Michael Paquier wrote: > On Thu, Nov 19, 2015 at 12:21 AM, Alvaro Herrera > wrote: > > Hi, I just started looking this over a bit. The first thing I noticed > > is that it adds a dependency on Archive::Tar which isn't already used > > anywhere else. Did anybody check

Re: [HACKERS] RLS open items are vague and unactionable

Noah, * Noah Misch (n...@leadboat.com) wrote: > On Mon, Sep 28, 2015 at 03:03:51PM -0400, Stephen Frost wrote: > > If SELECT rights are required then apply the SELECT policies, even if > > the actual command is an UPDATE or DELETE. This covers the RETURNING > > case which was discussed