Re: [HACKERS] Autonomous Transaction is back

> Ah, you're missing how commits in ATX are expected to work. Let me > illustrate: > > X ( >Data write A1 >call Y( > Start ATX > Data write B1 > Commit ATX >) >Data write A2 >Exception > ) > > In this workflow, B1 would be committed and persistent. Neith

Re: [HACKERS] [DESIGN] ParallelAppend

KaiGai-san, On 2015-07-27 PM 11:07, Kouhei Kaigai wrote: > > Append >--> Funnel > --> PartialSeqScan on rel1 (num_workers = 4) >--> Funnel > --> PartialSeqScan on rel2 (num_workers = 8) >--> SeqScan on rel3 > > shall be rewritten to > Funnel > --> PartialSeq

Re: [HACKERS] Feature - Index support on an lquery field (from the ltree module)

On 07/28/2015 06:40 AM, David Belle wrote: I have a requirement for a project that I am working on and was hoping to gain some discussion on the idea of implementing an index type for lquery fields (see ltree’s http://www.postgresql.org/docs/9.4/static/ltree.html

Re: [HACKERS] [DESIGN] ParallelAppend

On Tue, Jul 28, 2015 at 7:59 AM, Kouhei Kaigai wrote: > > > -Original Message- > > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai > > Sent: Monday, July 27, 2015 11:07 PM > > To: Amit Kapila > > > > > > Is there a real ne

Re: [HACKERS] proposal: multiple psql option -c

2015-07-28 5:24 GMT+02:00 Pavel Stehule : > > > 2015-07-27 21:57 GMT+02:00 Andrew Dunstan : > >> >> On 07/27/2015 02:53 PM, Pavel Stehule wrote: >> >>> >>> >>> >>> >>> I am trying to run parallel execution >>> >>> psql -At -c "select datname from pg_database" postgres | xargs -n 1 -P 3 >>> psql -c

[HACKERS] Feature - Index support on an lquery field (from the ltree module)

Hi Forgive me if this is not the right place to discuss this. I am new to the postgresql community. I have a requirement for a project that I am working on and was hoping to gain some discussion on the idea of implementing an index type for lquery fields (see ltree’s http://www.postgresql.org

Re: [HACKERS] Autonomous Transaction is back

2015-07-27 23:59 GMT+02:00 Merlin Moncure : > On Mon, Jul 27, 2015 at 4:41 PM, Joel Jacobson wrote: > > On Fri, Jul 24, 2015 at 9:39 PM, Merlin Moncure > wrote: > >> > >> On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus wrote: > >> > Batch Jobs: large data-manipulation tasks which need to be broken

Re: [HACKERS] Failing assertions in indxpath.c, placeholder.c and brin_minmax.c

Andreas Seltenreich writes: > I let sqlsmith run during the night, and it did no longer trigger the > first two. During roughly a million random queries it triggered the > already mentioned brin one 10 times, but there was also one instance of > this new one in the log: > TRAP: FailedAssertion("

Re: [HACKERS] more RLS oversights

On 07/03/2015 10:03 AM, Noah Misch wrote: >> +static void >> +dumpPolicy(Archive *fout, PolicyInfo *polinfo) > ... >> +if (polinfo->polqual != NULL) >> +appendPQExpBuffer(query, " USING %s", polinfo->polqual); > > (3) The USING clause needs parentheses; a dump+reload failed like so

Re: [HACKERS] proposal: multiple psql option -c

2015-07-27 21:57 GMT+02:00 Andrew Dunstan : > > On 07/27/2015 02:53 PM, Pavel Stehule wrote: > >> >> >> >> >> I am trying to run parallel execution >> >> psql -At -c "select datname from pg_database" postgres | xargs -n 1 -P 3 >> psql -c "select current_database()" >> >> >> > > I don't think it's

Re: [HACKERS] MultiXact member wraparound protections are now enabled

On Mon, Jul 27, 2015 at 07:59:40AM +0100, Simon Riggs wrote: > On 26 July 2015 at 20:15, Noah Misch wrote: > > On Fri, Jul 24, 2015 at 09:14:09PM -0400, Peter Eisentraut wrote: > > > On 7/22/15 4:45 PM, Robert Haas wrote: > > > > But it seemed to me that this could be rather confusing. I thought

Re: [HACKERS] CustomScan and readfuncs.c

> 2. Reproduce method table on background worker > -- > The method field of CustomPath/Scan/ScanState is expected to be > a reference to a static structure. Thus, copyObject() does not > copy the entire table, but only pointers. > However, we have no way

Re: [HACKERS] [DESIGN] ParallelAppend

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai > Sent: Monday, July 27, 2015 11:07 PM > To: Amit Kapila > Cc: pgsql-hackers@postgresql.org; Robert Haas; Kyotaro HORIGUCHI > Subject: Re: [HACKERS] [DESI

Re: [HACKERS] A little RLS oversight?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 03:05 PM, Stephen Frost wrote: > AFK at the moment, but my thinking was that we should avoid having > the error message change based on what a GUC is set to. I agree > that there should be comments which explain that. I changed back to u

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On Tue, Jul 28, 2015 at 1:15 AM, Andrew Dunstan wrote: > Well, it does create a lot of files that we don't pick up. An example list > is show below, and I am attaching their contents in a single gzipped > attachment. However, these are in the wrong location. This was a vpath build > and yet these

Re: [HACKERS] Sharing aggregate states between different aggregate functions

On 27 July 2015 at 20:11, Heikki Linnakangas wrote: > On 07/27/2015 08:34 AM, David Rowley wrote: > >> - * agg_input_types, agg_state_type, agg_result_type identify the input, >> - * transition, and result types of the aggregate. These should all be >> - * resolved to actual types (ie, none shou

Re: [HACKERS] Planner debug views

On Thu, Jul 23, 2015 at 4:11 PM, Tatsuo Ishii wrote: > Sounds like a great feature! > Thanks! Attached is a draft patch implementing the idea. To play with it, you shall create the follow two foreign tables: CREATE EXTENSION file_fdw; CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw; create for

Re: [HACKERS] more RLS oversights

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 01:13 PM, Alvaro Herrera wrote: > Hmm, these are not ACL objects, so conceptually it seems cleaner to > use a different symbol for this. I think the catalog state and the > error messages would be a bit confusing otherwise. Ok -- done

Re: [HACKERS] Several memory leaks for pg_rewind caused by missing PQclear calls

On Tue, Jul 28, 2015 at 2:45 AM, Heikki Linnakangas wrote: > On 07/23/2015 05:08 PM, Michael Paquier wrote: >> >> Hi all, >> >> After a run of valgrind on pg_rewind, I found a couple of code paths >> missing some PQclear calls after running a query. Attached is a patch >> to fix all those leaks. >

Re: [HACKERS] Autonomous Transaction is back

On 7/27/15 6:40 PM, Jim Nasby wrote: On 7/27/15 5:12 PM, Joel Jacobson wrote: Right now, when writing a function, if you raise an exception, you can be sure all writes you have made will be rollbacked, but your caller function might caught the exception and decide to carry on and commit work mad

Re: [HACKERS] Autonomous Transaction is back

On 7/27/15 5:56 PM, Josh Berkus wrote: Can you explain what use case you have where simply telling the staff "if you use ATX without clearing it, you'll be fired" is not sufficient? Possibly there's something we failed to account for in the unconference discussion. That there's no way to enfo

Re: [HACKERS] Autonomous Transaction is back

On 7/27/15 5:12 PM, Joel Jacobson wrote: Right now, when writing a function, if you raise an exception, you can be sure all writes you have made will be rollbacked, but your caller function might caught the exception and decide to carry on and commit work made before your function was called, but

Re: [HACKERS] Optimization idea: merging multiple EXISTS(...) with constraint-based join removal

On 28 July 2015 at 09:37, Frédéric TERRAZZONI wrote: > > SELECT * FROM t1 > WHERE EXISTS( > SELECT 1 FROM t2, t3, t4 > WHERE t2.id = t1.t2_id > AND t3.id = t2.t3_id > AND t4.id = t3.t4_id > AND t4.val = 'XYZ' > ) AND EXISTS( > SELECT 1 F

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 28 July 2015 at 09:17, Andres Freund wrote: > Hi, > > I recently once more noticed that timestamptz_out is really, really > slow. To quantify that, I created a bunch of similar sized tables: > > CREATE TABLE tbl_timestamp AS SELECT NOW() FROM generate_series(1, 10) > a, generate_series(1,

Re: [HACKERS] Autonomous Transaction is back

On 07/27/2015 03:12 PM, Joel Jacobson wrote: > On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus > wrote: > > Ah, you're missing how commits in ATX are expected to work. Let me > illustrate: > > X ( >Data write A1 >call Y( > Start AT

Re: [HACKERS] optimizing vacuum truncation scans

On 7/27/15 10:39 AM, Robert Haas wrote: But that's not enough: we also need to know that any tuple that survived the prune operation (that is, it wasn't redirected or marked unused) has a new-enough xmin, which isn't tracked anywhere. Wouldn't that be old-enough xmin? heap_prune_chain() is alr

Re: [HACKERS] Autonomous Transaction is back

On Mon, Jul 27, 2015 at 11:49 PM, Josh Berkus wrote: > Ah, you're missing how commits in ATX are expected to work. Let me > illustrate: > > X ( >Data write A1 >call Y( > Start ATX > Data write B1 > Commit ATX >) >Data write A2 >Exception > ) > > In thi

Re: [HACKERS] A little RLS oversight?

On Monday, July 27, 2015, Dean Rasheed wrote: > On 27 July 2015 at 22:36, Joe Conway > > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 07/27/2015 01:25 PM, Dean Rasheed wrote: > >> Looks good to me, except I'm not sure about those latest changes > >> because I don't unde

Re: [HACKERS] A little RLS oversight?

On 27 July 2015 at 22:36, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/27/2015 01:25 PM, Dean Rasheed wrote: >> Looks good to me, except I'm not sure about those latest changes >> because I don't understand the reasoning behind the logic in >> check_enable_rls() wh

Re: [HACKERS] Autonomous Transaction is back

On Mon, Jul 27, 2015 at 4:41 PM, Joel Jacobson wrote: > On Fri, Jul 24, 2015 at 9:39 PM, Merlin Moncure wrote: >> >> On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus wrote: >> > Batch Jobs: large data-manipulation tasks which need to be broken up >> > into segments, with each segment committing sepa

Re: [HACKERS] multivariate statistics / patch v7

Hello Horiguchi-san, On 07/27/2015 09:04 AM, Kyotaro HORIGUCHI wrote: Hello, At Sat, 25 Jul 2015 23:09:31 +0200, Tomas Vondra wrote in <55b3fb0b.7000...@2ndquadrant.com> Hi, On 07/16/2015 01:51 PM, Kyotaro HORIGUCHI wrote: Hi, I'd like to show you the modified constitution of multivariate

Re: [HACKERS] Autonomous Transaction is back

On 07/27/2015 02:47 AM, Rajeev rastogi wrote: >> Why have any fixed maximum? > Since we are planning to have nested autonomous transaction, so it is > required to have limit on this so that resources can be controlled. Is there a particular reason why this limit wouldn't just be max_stack_depth?

Re: [HACKERS] WIP: Make timestamptz_out less slow.

Andres Freund writes: > On 2015-07-27 17:31:41 -0400, Tom Lane wrote: >> What happens if you force use of port/snprintf.c instead of glibc's >> version? > Even worse. 15900.014 ms. Interesting. So as a separate optimization problem, we might consider "try to put snprintf.c at least on a par wit

Re: [HACKERS] Autonomous Transaction is back

On 07/27/2015 02:41 PM, Joel Jacobson wrote: > However, we should also add a way for the caller to protect against an > Autonomous Transaction in a function called by the caller. Imagine if > you're the author of function X() and within X() make use of some other > function Y() which has been writt

Re: [HACKERS] Autonomous Transaction is back

On Fri, Jul 24, 2015 at 9:39 PM, Merlin Moncure wrote: > On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus wrote: > > Batch Jobs: large data-manipulation tasks which need to be broken up > > into segments, with each segment committing separately. Example: > > updating 1 million records in batches of

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-07-27 17:31:41 -0400, Tom Lane wrote: > Andres Freund writes: > > So nearly all the time is spent somewhere inside the sprintf calls. Not > > nice. > > What happens if you force use of port/snprintf.c instead of glibc's > version? Good question. Even worse. 15900.014 ms. Andres -- S

[HACKERS] Optimization idea: merging multiple EXISTS(...) with constraint-based join removal

I've frequently encountered queries where the WHERE clause contains a lot of "EXISTS(...)" subqueries linked by logical ANDs. They are typically generated queries, and the "EXISTS(...)" fragments are composable pieces of SQL code acting as filters. Moreover, all those filters ends up being very sim

Re: [HACKERS] A little RLS oversight?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 01:25 PM, Dean Rasheed wrote: > Looks good to me, except I'm not sure about those latest changes > because I don't understand the reasoning behind the logic in > check_enable_rls() when row_security is set to OFF. > > I would expect th

Re: [HACKERS] WIP: Make timestamptz_out less slow.

Andres Freund writes: > So nearly all the time is spent somewhere inside the sprintf calls. Not > nice. What happens if you force use of port/snprintf.c instead of glibc's version? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] A little RLS oversight?

On 27 July 2015 at 21:58, Stephen Frost wrote: > Dean, > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> On 27 July 2015 at 18:13, Joe Conway wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> > >> > On 07/27/2015 10:03 AM, Joe Conway wrote: >> >> On 07/26/2015 07:59 AM, Joe

[HACKERS] WIP: Make timestamptz_out less slow.

Hi, I recently once more noticed that timestamptz_out is really, really slow. To quantify that, I created a bunch of similar sized tables: CREATE TABLE tbl_timestamp AS SELECT NOW() FROM generate_series(1, 10) a, generate_series(1, 100) b; CREATE TABLE tbl_int8 AS SELECT 1::bigint FROM gener

Re: [HACKERS] proposal: multiple psql option -c

On 7/27/15 2:57 PM, Andrew Dunstan wrote: psql -At -c "select datname from pg_database" postgres | xargs -n 1 -P 3 psql -c "select current_database()" I don't think it's going to be a hugely important feature, but I don't see a problem with creating a new option (-C seems fine) which would

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

On 7/27/15 1:46 PM, Robert Haas wrote: On Mon, Jul 27, 2015 at 2:43 PM, Alvaro Herrera wrote: Robert Haas wrote: On Mon, Jul 27, 2015 at 2:32 PM, Alvaro Herrera wrote: I think this is already possible, is it not? You just have to look for an identically-identified pg_locks entry with gran

Re: [HACKERS] copy.c handling for RLS is insecure

All, * Stephen Frost (sfr...@snowman.net) wrote: > * Andres Freund (and...@anarazel.de) wrote: > > On 2015-07-09 01:28:28 -0400, Noah Misch wrote: > > > > - Keep the OID check, shouldn't hurt to have it > > > > > > What benefit is left? > > > > A bit of defense in depth. We execute user defined

Re: [HACKERS] A little RLS oversight?

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 27 July 2015 at 18:13, Joe Conway wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 07/27/2015 10:03 AM, Joe Conway wrote: > >> On 07/26/2015 07:59 AM, Joe Conway wrote: > >>> On 07/26/2015 07:19 AM, Dean Rasheed wr

Re: [HACKERS] optimizing vacuum truncation scans

On 22 July 2015 at 17:11, Jeff Janes wrote: > On Wed, Jul 22, 2015 at 6:59 AM, Robert Haas > wrote: > >> On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes wrote: >> > Attached is a patch that implements the vm scan for truncation. It >> > introduces a variable to hold the last blkno which was skippe

Re: [HACKERS] A little RLS oversight?

On 27 July 2015 at 18:13, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/27/2015 10:03 AM, Joe Conway wrote: >> On 07/26/2015 07:59 AM, Joe Conway wrote: >>> On 07/26/2015 07:19 AM, Dean Rasheed wrote: Attached is an updated patch (still needs some docs for the

Re: [HACKERS] proposal: multiple psql option -c

On Mon, Jul 27, 2015 at 2:53 PM, Pavel Stehule wrote: > I am trying to run parallel execution > > psql -At -c "select datname from pg_database" postgres | xargs -n 1 -P 3 > psql -c "select current_database()" Put this in a shell script called run-psql: #!/bin/bash test $# = 0 && exit for f in "

Re: [HACKERS] more RLS oversights

Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/03/2015 10:03 AM, Noah Misch wrote: > > (2) CreatePolicy() and AlterPolicy() omit to create a pg_shdepend > > entry for each role in the TO clause. Test case: > > Please see the attached patch. Note that I used SHARED_

Re: [HACKERS] proposal: multiple psql option -c

On 07/27/2015 02:53 PM, Pavel Stehule wrote: I am trying to run parallel execution psql -At -c "select datname from pg_database" postgres | xargs -n 1 -P 3 psql -c "select current_database()" I don't think it's going to be a hugely important feature, but I don't see a problem with c

Re: [HACKERS] REVOKE [ADMIN OPTION FOR] ROLE

Egor, * Egor Rogov (e.ro...@postgrespro.ru) wrote: > >On Thu, Jul 23, 2015 at 8:30 AM, Egor Rogov wrote: > >>So, the question: is it a documentation bug (as it seems to me), code bug, > >>or I missed something? > >Your analysis looks right to me, but I don't know whether the code or > >the docume

Re: [HACKERS] spgist recovery assertion failure

On 07/27/2015 04:24 PM, Michael Paquier wrote: On Mon, Jul 27, 2015 at 2:33 PM, Piotr Stefaniak wrote: On 07/27/2015 07:19 AM, Michael Paquier wrote: On Mon, Jul 27, 2015 at 2:00 PM, Noah Misch wrote: When I caused a crash during the create_index regression test, recovery hit an assertion

Re: [HACKERS] proposal: multiple psql option -c

2015-07-27 20:47 GMT+02:00 Robert Haas : > On Mon, Jul 27, 2015 at 2:37 PM, Pavel Stehule > wrote: > > 2015-07-27 20:32 GMT+02:00 Robert Haas : > >> > >> On Sat, Jul 25, 2015 at 5:27 AM, Pavel Stehule > > >> wrote: > >> > It will be nice side effect, but my primary problem was a > impossibility

Re: [HACKERS] anole: assorted stability problems

On Sun, Jul 26, 2015 at 11:36 AM, Andres Freund wrote: > On 2015-07-07 13:25:24 +0200, Andres Freund wrote: >> So, it's starting to look good. Not exactly allowing for a lot of >> confidence yet, but still: >> http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=HEAD > > Since there

Re: [HACKERS] proposal: multiple psql option -c

On Mon, Jul 27, 2015 at 2:37 PM, Pavel Stehule wrote: > 2015-07-27 20:32 GMT+02:00 Robert Haas : >> >> On Sat, Jul 25, 2015 at 5:27 AM, Pavel Stehule >> wrote: >> > It will be nice side effect, but my primary problem was a impossibility >> > to >> > combine VACUUM and any other statement to one s

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

On Mon, Jul 27, 2015 at 2:43 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Mon, Jul 27, 2015 at 2:32 PM, Alvaro Herrera >> wrote: > >> > I think this is already possible, is it not? You just have to look for >> > an identically-identified pg_locks entry with granted=true. That gives >> >

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

Robert Haas wrote: > On Mon, Jul 27, 2015 at 2:32 PM, Alvaro Herrera > wrote: > > I think this is already possible, is it not? You just have to look for > > an identically-identified pg_locks entry with granted=true. That gives > > you a PID and vxid/xid. You can self-join pg_locks with that,

Re: [HACKERS] proposal: multiple psql option -c

2015-07-27 20:32 GMT+02:00 Robert Haas : > On Sat, Jul 25, 2015 at 5:27 AM, Pavel Stehule > wrote: > > It will be nice side effect, but my primary problem was a impossibility > to > > combine VACUUM and any other statement to one simple psql call. > > Seems like you can do that easily enough: > >

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

On Mon, Jul 27, 2015 at 2:32 PM, Alvaro Herrera wrote: > David Rowley wrote: >> I've not looked into the feasibility of it, but if it were also possible to >> have a "waiting_for" column which would store the process ID of the process >> that's holding a lock that this process is waiting on, then

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

David Rowley wrote: > I've not looked into the feasibility of it, but if it were also possible to > have a "waiting_for" column which would store the process ID of the process > that's holding a lock that this process is waiting on, then it would be > possible for some smart guy to write some code

Re: [HACKERS] proposal: multiple psql option -c

On Sat, Jul 25, 2015 at 5:27 AM, Pavel Stehule wrote: > It will be nice side effect, but my primary problem was a impossibility to > combine VACUUM and any other statement to one simple psql call. Seems like you can do that easily enough: [rhaas pgsql]$ (echo 'SELECT 1;'; echo 'VACUUM;'; echo 'S

Re: [HACKERS] Several memory leaks for pg_rewind caused by missing PQclear calls

On 07/23/2015 05:08 PM, Michael Paquier wrote: Hi all, After a run of valgrind on pg_rewind, I found a couple of code paths missing some PQclear calls after running a query. Attached is a patch to fix all those leaks. Fixed, thanks. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-ha

[HACKERS] Alpha 2 wrapping August 3

... so please get those fixes/overhauls in in the next week. Thanks! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- 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] A little RLS oversight?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2015 10:03 AM, Joe Conway wrote: > On 07/26/2015 07:59 AM, Joe Conway wrote: >> On 07/26/2015 07:19 AM, Dean Rasheed wrote: >>> Attached is an updated patch (still needs some docs for the >>> functions). >> >> Thanks for that. I'll add the do

Re: [HACKERS] A little RLS oversight?

On 07/26/2015 07:59 AM, Joe Conway wrote: > On 07/26/2015 07:19 AM, Dean Rasheed wrote: >> Attached is an updated patch (still needs some docs for the functions). > > Thanks for that. I'll add the docs. Documentation added. Also added comment to check_enable_rls about passing InvalidOid versus Ge

Re: [HACKERS] Reduce ProcArrayLock contention

On Sat, Jul 25, 2015 at 10:12 AM, Amit Kapila wrote: > > >> > > > > Numbers look impressive and definitely shows that the idea is worth > pursuing. I tried patch on my laptop. Unfortunately, at least for 4 and 8 > clients, I did not see any improvement. > > > > I can't help in this because I thin

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On 07/27/2015 10:06 AM, Tom Lane wrote: I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-07-04%2016%3A00%3A23 or here: h

Re: [HACKERS] Microvacuum for gist. Question about GISTPageOpaqueData flag

2015-07-27 20:05 GMT+04:00 Heikki Linnakangas : > On 07/27/2015 06:46 PM, Teodor Sigaev wrote: > >> I need an advice, what would be better: >>> - to add new flag like F_HAS_GARBAGE, >>> - or to delete all mentions of F_TUPLES_DELETED and use it in gist >>> microvacuum. >>> >> >> According to commi

Re: [HACKERS] Microvacuum for gist. Question about GISTPageOpaqueData flag

On 07/27/2015 06:46 PM, Teodor Sigaev wrote: I need an advice, what would be better: - to add new flag like F_HAS_GARBAGE, - or to delete all mentions of F_TUPLES_DELETED and use it in gist microvacuum. According to commit message: commit 2effb72e682a7dbdc9a8a60a80c22ec1fa9d8079 Author: Heikki

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

Attatched is the revised version of this patch. The first patch is not changed from before. The second is fixed a kind of bug. Ths third is the new one to allow backslash continuation for backslash commands. Ah, thanks:-) Would you consider adding the patch to the next commitfest? I may pu

Re: [HACKERS] Microvacuum for gist. Question about GISTPageOpaqueData flag

I need an advice, what would be better: - to add new flag like F_HAS_GARBAGE, - or to delete all mentions of F_TUPLES_DELETED and use it in gist microvacuum. According to commit message: commit 2effb72e682a7dbdc9a8a60a80c22ec1fa9d8079 Author: Heikki Linnakangas Date: Fri Nov 7 15:03:46 2014 +

Re: [HACKERS] optimizing vacuum truncation scans

On Sat, Jul 25, 2015 at 4:46 AM, Simon Riggs wrote: > On 22 July 2015 at 14:59, Robert Haas wrote: >> Urgh. So if we do this, that forever precludes having HOT pruning set >> the all-visible bit. > > What is the reason why we don't do that already? Surely its a one liner? I wish! It actually d

Re: [HACKERS] All-zero page in GIN index causes assertion failure

On Tue, Jul 28, 2015 at 12:21 AM, Heikki Linnakangas wrote: > > Thanks, I've pushed this, as well a fix to similar failure from B-tree > vacuum that Amit Langote reported in the other thread. > Thanks Heikki and sorry I didn't notice this new thread. Regards, Amit -- Sent via pgsql-hackers ma

Re: [HACKERS] All-zero page in GIN index causes assertion failure

On 07/23/2015 07:43 PM, Jeff Janes wrote: On Mon, Jul 20, 2015 at 1:23 PM, Heikki Linnakangas wrote: I came up with the attached, for GIN and SP-GiST. Instead of WAL-logging the page initialization in SP-GiST vacuum, I changed it so that it simply leaves the page as all-zeroes, and adds it to

Re: [HACKERS] Buildfarm TAP testing is useless as currently implemented

On 07/27/2015 05:06 PM, Tom Lane wrote: I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-07-04%2016%3A00%3A23 or here: ht

Re: [HACKERS] Reduce ProcArrayLock contention

On Sat, Jul 25, 2015 at 12:42 AM, Amit Kapila wrote: > I thought that internal API will automatically take care of it, > example for msvc it uses _InterlockedCompareExchange64 > which if doesn't work on 32-bit systems or is not defined, then > we have to use 32-bit version, but I am not certain ab

[HACKERS] Microvacuum for gist. Question about GISTPageOpaqueData flag

Hi, I'm working on microvacuum for gist access method. Briefly microvacuum includes two steps: 1. When search tells us that the tuple is invisible to all transactions it is marked LP_DEAD and page is marked as "has dead tuples", 2. Then, when insert touches full page which has dead tuples it calls

Re: [HACKERS] Buildfarm failure from overly noisy warning message

Tom Lane wrote: > Kevin Grittner writes: >> I think a LOG entry when an autovacuum process is actually canceled >> has value just in case it is happening on a particular table so >> frequently that the table starts to bloat. I see no reason to log >> anything if there is an intention to cancel

Re: [HACKERS] Failing assertions in indxpath.c, placeholder.c and brin_minmax.c

Andreas Seltenreich writes: > Tom Lane writes: >> I've fixed the first two of these --- thanks for the report! > I let sqlsmith run during the night, and it did no longer trigger the > first two. During roughly a million random queries it triggered the > already mentioned brin one 10 times, but

Re: [HACKERS] Restore-reliability mode

Noah Misch wrote: > On Thu, Jul 23, 2015 at 04:53:49PM -0300, Alvaro Herrera wrote: > > Peter Geoghegan wrote: > > > On Sat, Jun 6, 2015 at 12:58 PM, Noah Misch wrote: > > > > - Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local > > > > pin > > > > count falls to zero. Und

Re: [HACKERS] Failing assertions in indxpath.c, placeholder.c and brin_minmax.c

Tom Lane wrote: > Bottom line is that somebody failed to consider the possibility of a > null comparison value reaching the BRIN index lookup machinery. > The code stanza that's failing supposes that only IS NULL or IS NOT NULL > tests could have SK_ISNULL set, but that's just wrong. Hm, okay, wi

Re: [HACKERS] [DESIGN] ParallelAppend

> On Sun, Jul 26, 2015 at 8:43 AM, Kouhei Kaigai wrote: > > > > Hello, > > > > I'm recently working/investigating on ParallelAppend feature > > towards the next commit fest. Below is my design proposal. > > > > 1. Concept > > -- > > Its concept is quite simple anybody might consider more t

[HACKERS] Buildfarm TAP testing is useless as currently implemented

I challenge anybody to figure out what happened here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2015-07-27%2010%3A25%3A17 or here: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster&dt=2015-07-04%2016%3A00%3A23 or here: http://buildfarm.postgresql.org/cgi-bin/show

Re: [HACKERS] [DESIGN] ParallelAppend

> Hello, can I ask some questions? > > I suppose we can take this as the analog of ParalleSeqScan. I > can see not so distinction between Append(ParalleSeqScan) and > ParallelAppend(SeqScan). What difference is there between them? > Append does not start to execute the second or later node until f

Re: [HACKERS] spgist recovery assertion failure

On Mon, Jul 27, 2015 at 2:33 PM, Piotr Stefaniak wrote: > On 07/27/2015 07:19 AM, Michael Paquier wrote: >> >> On Mon, Jul 27, 2015 at 2:00 PM, Noah Misch wrote: >>> >>> When I caused a crash during the create_index regression test, recovery >>> hit an >>> assertion failure. Minimal test case: >

Re: [HACKERS] creating extension including dependencies

On Sun, Jul 26, 2015 at 1:01 AM, Petr Jelinek wrote: > Yes that's what I meant by the change of checking order in the explanation > above. I did that because I thought code would be more complicated > otherwise, but apparently I was stupid... +In case the extension specifies schema in its

Re: [HACKERS] REVOKE [ADMIN OPTION FOR] ROLE

On Thu, Jul 23, 2015 at 8:30 AM, Egor Rogov wrote: So, the question: is it a documentation bug (as it seems to me), code bug, or I missed something? Your analysis looks right to me, but I don't know whether the code or the documentation should be changed. This claim was added by Tom Lane in

[HACKERS] 9.5a1 BUG FIX: pgbench negative latencies

Under 9.5a1 "pgbench -r" negative latencies are reported on meta commands, probably as an oversight of 84f0ea3f. This patch ensures that "now" is reset on each loop inside doCustom. -- Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c index 2c3e365..cce67e8 100644 ---

Re: [HACKERS] [DESIGN] ParallelAppend

On Sun, Jul 26, 2015 at 8:43 AM, Kouhei Kaigai wrote: > > Hello, > > I'm recently working/investigating on ParallelAppend feature > towards the next commit fest. Below is my design proposal. > > 1. Concept > -- > Its concept is quite simple anybody might consider more than once. > Parallel

Re: [HACKERS] Proposal for CSN based snapshots

On Sat, Jul 25, 2015 at 11:39 AM, Simon Riggs wrote: > On 24 July 2015 at 19:21, Robert Haas wrote: > >> On Fri, Jul 24, 2015 at 1:00 PM, Simon Riggs >> wrote: >> > It depends on the exact design we use to get that. Certainly we do not >> want >> > them if they cause a significant performance r

Re: [HACKERS] raw output from copy

2015-07-27 10:41 GMT+02:00 Heikki Linnakangas : > On 07/27/2015 06:55 AM, Craig Ringer wrote: > >> On 7 July 2015 at 14:32, Pavel Stehule wrote: >> >>> Hi >>> >>> previous patch was broken, and buggy >>> >>> Here is new version with fixed upload and more tests >>> >> >> I routinely see people try

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

Hello. In the attached patch I've made a refactoring for tranches. The prefix for them was extended, and I've did a split of LWLockAssign to two functions (one with tranche and second for user defined LWLocks). -- Ildus Kurbangaliev Postgres Professional: http://www.postgrespro.com The Russian

Re: [HACKERS] Autonomous Transaction is back

On 23 July 2015 21:04, Robert Haas Wrote: On Thu, Jul 23, 2015 at 1:31 AM, Rajeev rastogi wrote: >> 2.It should be allowed to deadlock with master transaction. We >> need to work-out a solution to avoid deadlock. >This sentence seems to contradict itself. I thought the consensus was

Re: [HACKERS] We need to support ForeignRecheck for late row locking, don't we?

> On 2015/07/24 23:51, Kouhei Kaigai wrote: > >> On 2015/07/22 19:10, Etsuro Fujita wrote: > >>> While working on the issue "Foreign join pushdown vs EvalPlanQual", I > >>> happened to notice odd behaviors of late row locking in FDWs. > >> > >>> I think the reason for that is because we don't check

Re: [HACKERS] [DESIGN] ParallelAppend

Hello, can I ask some questions? I suppose we can take this as the analog of ParalleSeqScan. I can see not so distinction between Append(ParalleSeqScan) and ParallelAppend(SeqScan). What difference is there between them? If other nodes will have the same functionality as you mention at the last

Re: [HACKERS] Sharing aggregate states between different aggregate functions

On 27 July 2015 at 20:11, Heikki Linnakangas wrote: > On 07/27/2015 08:34 AM, David Rowley wrote: > > In this function I also wasn't quite sure if it was with comparing both >> non-NULL INITCOND's here. I believe my code comments may slightly >> contradict what the code actually does, as the com

Re: [HACKERS] False comment about speculative insertion

On 07/26/2015 10:30 PM, Peter Geoghegan wrote: Attached patch removes a reference to an executor README section about speculative insertion. In fact, the high-level overview of speculative insertion ended up at the top of execIndexing.c. The executor README was not touched by the ON CONFLICT patc

Re: [HACKERS] raw output from copy

On 07/27/2015 06:55 AM, Craig Ringer wrote: On 7 July 2015 at 14:32, Pavel Stehule wrote: Hi previous patch was broken, and buggy Here is new version with fixed upload and more tests I routinely see people trying to use COPY ... FORMAT binary to export a single binary field (like an image,

Re: [HACKERS] Sharing aggregate states between different aggregate functions

On 07/27/2015 08:34 AM, David Rowley wrote: - * agg_input_types, agg_state_type, agg_result_type identify the input, - * transition, and result types of the aggregate. These should all be - * resolved to actual types (ie, none should ever be ANYELEMENT etc). + * agg_input_types identifies the in

Re: [HACKERS] pg_dump -Fd and compression level

>>> >>> As per attached patch. >>> >>> Comments? >> >> It seems that the first test on the compression in pg_backup_tar.c is now >> obsolete. >> It didn't make much sense anyway. >> >> >> >>211 if (AH->compression < 0 || AH->compression > 9) >>212 AH->compression = Z_D

  1   2   >