Re: [HACKERS] PL/pgSQL, RAISE and error context

Hi here is complete patch, that introduce context filtering on client side. The core of this patch is trivial and small - almost all of size are trivial changes in regress tests - removing useless context. Documentation, check-world Regards Pavel 2015-07-26 0:42 GMT+02:00 Pavel Stehule : > Hi

[HACKERS] [DESIGN] ParallelAppend

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. ParallelAppend node kicks background worker process to execute child nodes in par

Re: [HACKERS] markup problems in row_security GUC docs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2015 04:17 PM, Joe Conway wrote: > On 07/25/2015 03:26 PM, Kevin Grittner wrote: >> The use of the apostrophe character to quote allowed enumerated >> values seems wrong. Probably these should be replaced by >> tags. The reference to BYPAS

Re: [HACKERS] xlc 12.1 miscompiles 32-bit ginCompareItemPointers()

On Sun, Jul 19, 2015 at 04:32:16PM -0400, Noah Misch wrote: > On Sun, Jul 19, 2015 at 04:22:47PM -0400, Tom Lane wrote: > > More: if the compiler does have a bug like that, how much confidence can > > we have, really, that there are no other miscompiled places and won't be > > any in the future? I

Re: [HACKERS] markup problems in row_security GUC docs

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/25/2015 03:26 PM, Kevin Grittner wrote: > The use of the apostrophe character to quote allowed enumerated > values seems wrong. Probably these should be replaced by > tags. The reference to BYPASSRLS also seems like it > deserves markup, and p

Re: [HACKERS] PL/pgSQL, RAISE and error context

Hi I am sending a next variant of filtering context patch. postgres=# do $$ begin raise notice 'kuku'; end $$; NOTICE: kuku DO Time: 2.441 ms postgres=# do $$ begin raise exception 'kuku'; end $$; ERROR: kuku CONTEXT: PL/pgSQL function inline_code_block line 1 at RAISE Time: 0.648 ms postgres=

[HACKERS] markup problems in row_security GUC docs

The use of the apostrophe character to quote allowed enumerated values seems wrong.  Probably these should be replaced by tags. The reference to BYPASSRLS also seems like it deserves markup, and possibly an entry in the index.  Does someone who is closer to the feature want to clean that up, or sh

Re: [HACKERS] multivariate statistics / patch v7

Hi, On 07/16/2015 01:51 PM, Kyotaro HORIGUCHI wrote: Hi, I'd like to show you the modified constitution of multivariate statistics application logic. Please find the attached. They apply on your v7 patch. Sadly I do have some trouble getting it to apply correctly :-( So for now all my comments

Re: [HACKERS] Debugging buildfarm pg_upgrade check failures

On 07/25/2015 10:59 AM, Tom Lane wrote: Now that we've restored proper logging of "make check", I looked into today's failure report from axolotl: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2015-07-24%2020%3A29%3A18 What evidently happened there is that "pg_ctl start" gav

Re: [HACKERS] pg_dump -Fd and compression level

On 07/25/2015 03:07 PM, Marc Mamin wrote: I propose to tighten pg_dump's rules so that only 0..9 are accepted as arguments for -Z, and in compress_io.c:cfopen(), if compression is equal to Z_DEFAULT_COMPRESSION, not add any explicit compression value to the mode, thus using the zlib default.

Re: [HACKERS] Anyone working on the TOAST items on the TODO list?

On Sat, 25 Jul 2015 16:06:28 -0400 Tom Lane wrote: > Bill Moran writes: > > On Sat, 25 Jul 2015 11:39:15 -0700 > > Josh Berkus wrote: > >> Nope. In fact, even the one which was 90% complete (replacing zlib with > >> lz4) completely dropped off the radar. > > > Interesting ... I wasn't looking

Re: [HACKERS] extend pgbench expressions with functions

Hello Heikki, As an initial list of functions, I'd suggest: abs(x) min(x, y, ...) max(x, y, ...) random_uniform(min, max) random_gaussian(min, max, threshold) random_exponential(min, max, threshold) Would that be enough to specify e.g. the As soon as we add more functions, the way they are d

Re: [HACKERS] Anyone working on the TOAST items on the TODO list?

Bill Moran writes: > On Sat, 25 Jul 2015 11:39:15 -0700 > Josh Berkus wrote: >> Nope. In fact, even the one which was 90% complete (replacing zlib with >> lz4) completely dropped off the radar. > Interesting ... I wasn't looking at doing that, rather adjusting the > decision logic on when to co

Re: [HACKERS] Anyone working on the TOAST items on the TODO list?

On Sat, 25 Jul 2015 11:39:15 -0700 Josh Berkus wrote: > On 07/25/2015 07:05 AM, Bill Moran wrote: > > > > If not, I'm going to make a little personal project of them for myself > > (targeting 9.6). > > > > Nope. In fact, even the one which was 90% complete (replacing zlib with > lz4) complete

Re: [HACKERS] polymorphic types - enforce casting to most common type automatically

2015-07-22 10:37 GMT+02:00 Heikki Linnakangas : > On 07/11/2015 12:19 AM, Pavel Stehule wrote: > >> 2015-07-10 18:43 GMT+02:00 Tom Lane : >> >> An example of what would presumably happen if we adopted this sort of >>> rule >>> (I've not checked whether the patch as written does this, but it would

Re: [HACKERS] pg_dump -Fd and compression level

> >> >> I propose to tighten pg_dump's rules so that only 0..9 are accepted as >> arguments for -Z, and in compress_io.c:cfopen(), if compression is >> equal to Z_DEFAULT_COMPRESSION, not add any explicit compression value >> to the mode, thus using the zlib default. >> >> > > >As per attached pat

Re: [HACKERS] pg_dump -Fd and compression level

Andrew Dunstan writes: > On 07/25/2015 01:52 PM, I wrote: >> I propose to tighten pg_dump's rules so that only 0..9 are accepted as >> arguments for -Z, and in compress_io.c:cfopen(), if compression is >> equal to Z_DEFAULT_COMPRESSION, not add any explicit compression value >> to the mode, thu

Re: [HACKERS] Anyone working on the TOAST items on the TODO list?

On 07/25/2015 07:05 AM, Bill Moran wrote: > > If not, I'm going to make a little personal project of them for myself > (targeting 9.6). > Nope. In fact, even the one which was 90% complete (replacing zlib with lz4) completely dropped off the radar. -- Josh Berkus PostgreSQL Experts Inc. http:

Re: [HACKERS] pg_dump -Fd and compression level

On 07/25/2015 01:52 PM, I wrote: I propose to tighten pg_dump's rules so that only 0..9 are accepted as arguments for -Z, and in compress_io.c:cfopen(), if compression is equal to Z_DEFAULT_COMPRESSION, not add any explicit compression value to the mode, thus using the zlib default.

Re: [HACKERS] A little RLS oversight?

On 07/22/2015 02:17 PM, Dean Rasheed wrote: > On 21 July 2015 at 04:53, Michael Paquier wrote: >> On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost wrote: >>> We need to be careful to avoid the slippery slope of trying to prevent >>> all covert channels, which has been extensively discussed previous

Re: [HACKERS] pg_dump -Fd and compression level

On 07/25/2015 10:50 AM, Michael Paquier wrote: On Sat, Jul 25, 2015 at 11:09 PM, Marc Mamin wrote: On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan wrote: On 07/25/2015 03:20 AM, Andrew Dunstan wrote: On 07/25/2015 02:34 AM, Marc Mamin wrote: Andrew Dunstan writes: Hmm. Yeah. It looks

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

> On Jul 24, 2015, at 10:02 PM, Robert Haas wrote: > > Also, the patch should not invent a new array similar but not quite > identical to LockTagTypeNames[]. > > This is goofy: > > + if (tranche_id > 0) > + result->tranche = tranche_id; > + else > + resu

Re: [HACKERS] raw output from copy

2015-07-23 22:05 GMT+02:00 Dickson S. Guedes : > 2015-07-07 3:32 GMT-03:00 Pavel Stehule : > > > > Hi > > > > previous patch was broken, and buggy > > > > Here is new version with fixed upload and more tests > > > > The interesting is so I should not to modify interface or client - so it > should

Re: [HACKERS] pg_dump quietly ignore missing tables - is it bug?

Hi I am sending a new patch - without checking wildcard chars. Regards Pavel 2015-07-23 7:22 GMT+02:00 Kyotaro HORIGUCHI : > Hello, > > > > 2015-07-19 20:54 GMT+02:00 Pavel Stehule : > > >> I am sending updated version. It implements new long option > > >> "--strict-names". If this option is u

Re: [HACKERS] creating extension including dependencies

On 2015-07-25 14:37, Michael Paquier wrote: On Sat, Jul 25, 2015 at 12:59 AM, Petr Jelinek wrote: On 2015-07-22 07:12, Michael Paquier wrote: On Tue, Jul 21, 2015 at 11:20 PM, Tom Lane wrote: Petr Jelinek writes: ... My main question is if we are ok with SCHEMA having different behavior

Re: [HACKERS] pg_dump -Fd and compression level

>On Sat, Jul 25, 2015 at 11:09 PM, Marc Mamin wrote: >> >>>On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan wrote: On 07/25/2015 03:20 AM, Andrew Dunstan wrote: > > > On 07/25/2015 02:34 AM, Marc Mamin wrote: >> >> >>> Andrew Dunstan writes: Hm

[HACKERS] Debugging buildfarm pg_upgrade check failures

Now that we've restored proper logging of "make check", I looked into today's failure report from axolotl: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2015-07-24%2020%3A29%3A18 What evidently happened there is that "pg_ctl start" gave up waiting for the postmaster to start to

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

Re: [HACKERS] pg_dump -Fd and compression level

On Sat, Jul 25, 2015 at 11:09 PM, Marc Mamin wrote: > >>On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan wrote: >>> >>> On 07/25/2015 03:20 AM, Andrew Dunstan wrote: On 07/25/2015 02:34 AM, Marc Mamin wrote: > > >> Andrew Dunstan writes: >>> >>> Hmm. Yeah. It lo

Re: [HACKERS] pgbench stats per script & other stuff

Also, maybe per-command detailed stats should use the same common struct to hold data as all other stats. I did not change it because it is maintained in a different part of the code. I played just once with the --report-latencies option and was astonished that meta commands showed negative

Re: [HACKERS] pg_dump -Fd and compression level

>On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan wrote: >> >> On 07/25/2015 03:20 AM, Andrew Dunstan wrote: >>> >>> >>> On 07/25/2015 02:34 AM, Marc Mamin wrote: > Andrew Dunstan writes: >> >> Hmm. Yeah. It looks like commit >> a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911 >

Re: [HACKERS] Anyone working on the TOAST items on the TODO list?

On Sat, Jul 25, 2015 at 11:05 PM, Bill Moran wrote: > If not, I'm going to make a little personal project of them for myself > (targeting 9.6). If you mean those three ones, not that I know of: https://wiki.postgresql.org/wiki/Todo#TOAST -- Michael -- Sent via pgsql-hackers mailing list (pgsq

[HACKERS] Anyone working on the TOAST items on the TODO list?

If not, I'm going to make a little personal project of them for myself (targeting 9.6). -- Bill Moran -- 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] Supporting TAP tests with MSVC and Windows

On Sat, Jul 25, 2015 at 4:14 PM, Noah Misch wrote: > On Fri, Jul 24, 2015 at 08:27:42PM +0300, Heikki Linnakangas wrote: >> On 06/25/2015 07:40 AM, Michael Paquier wrote: >> >Attached is v7, rebased on 0b157a0. >> >> Thanks! I fiddled with this a bit more, to centralize more of the >> platform-dep

Re: [HACKERS] pg_dump -Fd and compression level

On Sat, Jul 25, 2015 at 9:56 PM, Andrew Dunstan wrote: > > On 07/25/2015 03:20 AM, Andrew Dunstan wrote: >> >> >> On 07/25/2015 02:34 AM, Marc Mamin wrote: >>> >>> Andrew Dunstan writes: > > Hmm. Yeah. It looks like commit > a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911 > changed

Re: [HACKERS] pg_dump -Fd and compression level

On 07/25/2015 03:20 AM, Andrew Dunstan wrote: On 07/25/2015 02:34 AM, Marc Mamin wrote: Andrew Dunstan writes: Hmm. Yeah. It looks like commit a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911 changed from using the default compression for libz to using the compression set in pg_dump options, whic

Re: [HACKERS] Supporting TAP tests with MSVC and Windows

On Sat, Jul 25, 2015 at 2:27 AM, Heikki Linnakangas wrote: > On 06/25/2015 07:40 AM, Michael Paquier wrote: >> >> On Tue, May 26, 2015 at 3:39 PM, Michael Paquier wrote: >>> >>> Here is v6, a rebased version on HEAD (79f2b5d). There were some >>> conflicts with the indentation and some other patch

Re: [HACKERS] creating extension including dependencies

On Sat, Jul 25, 2015 at 12:59 AM, Petr Jelinek wrote: > On 2015-07-22 07:12, Michael Paquier wrote: >> >> On Tue, Jul 21, 2015 at 11:20 PM, Tom Lane wrote: >>> >>> Petr Jelinek writes: ... My main question is if we are ok with SCHEMA having different behavior with CASCADE vs witho

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Sat, Jul 25, 2015 at 2:19 AM, Paul Ramsey wrote: > On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey > wrote: >> Here's an updated patch that clears the cache on changes to foreign >> wrappers and servers. > > Any chance one of you folks could by my official commitfest reviewer? > Appreciate all t

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

On Fri, Jul 24, 2015 at 1:12 PM, Ildus Kurbangaliev < i.kurbangal...@postgrespro.ru> wrote: > > > > On Jul 24, 2015, at 7:26 AM, Amit Kapila wrote: > > > > > > 2. > > +const char * > > +pgstat_get_wait_event_name(uint8 classId, uint8 eventId) > > { > > .. > > } > > > > I don't understand why a sin

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

2015-07-25 10:33 GMT+02:00 David G. Johnston : > On Saturday, July 25, 2015, Pavel Stehule wrote: >> >> 2015-07-23 17:52 GMT+02:00 Robert Haas : >> >>> On Fri, Jul 17, 2015 at 12:36 AM, Pavel Stehule >>> wrote: >>> >> Or just properly understand the ; ? >>> >> >>> >> -c "select * from foo; updat

Re: [HACKERS] optimizing vacuum truncation scans

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? -- Simon Riggshttp://www.2ndQuadrant.com/

Re: [HACKERS] Proposal for CSN based snapshots

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 regression. > > Yeah. I think the performance worries expressed

[HACKERS] proposal: multiple psql option -c

On Saturday, July 25, 2015, Pavel Stehule wrote: > > 2015-07-23 17:52 GMT+02:00 Robert Haas : > >> On Fri, Jul 17, 2015 at 12:36 AM, Pavel Stehule >> wrote: >> >> Or just properly understand the ; ? >> >> >> >> -c "select * from foo; update bar set baz = 'bing'; vacuum bar;" >> > >> > there is a

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

2015-07-23 17:52 GMT+02:00 Robert Haas : > On Fri, Jul 17, 2015 at 12:36 AM, Pavel Stehule > wrote: > >> Or just properly understand the ; ? > >> > >> -c "select * from foo; update bar set baz = 'bing'; vacuum bar;" > > > > there is a risk of compatibility issues - all statements runs under one >

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

On 22 July 2015 at 21:45, Robert Haas wrote: > But it seemed to me that this could be rather confusing. I thought it > would be better to be explicit about whether the protections are > enabled in all cases. That way, (1) if you see the message saying > they are enabled, they are enabled; (2)

Re: [HACKERS] PL/pgSQL, RAISE and error context

2015-07-21 16:58 GMT+02:00 Merlin Moncure : > On Tue, Jul 21, 2015 at 2:53 AM, Heikki Linnakangas > wrote: > > On 07/21/2015 10:38 AM, Pavel Stehule wrote: > >> > >> where we are with this patch? Can I do some for it? > > > > > > I still feel this approach is misguided, and we should be tweaking

Re: [HACKERS] pgbench stats per script & other stuff

I liked @ because it makes sense to read it as the word "at". Yep, why not. Prepending classic to the names does not look necessary. I would suggest "tpcb-like", "simple-update" & "select-only", or even maybe any prefix. If the bench scripts could be read from some pg directory instead of

Re: [HACKERS] Solaris testers wanted for strxfrm() behavior

On Wed, Jul 22, 2015 at 08:40:05AM +0200, Bjorn Munch wrote: > On 22/07 02.29, Noah Misch wrote: > > > I ran this program on Solaris 9 U5 (September 2006) on Sparc and got: > > > > I appreciate your testing. A few sources give December 2003 as the month > > for > > Solaris 9 Update 5; would you

Re: [HACKERS] pg_dump -Fd and compression level

On 07/25/2015 02:34 AM, Marc Mamin wrote: Andrew Dunstan writes: Hmm. Yeah. It looks like commit a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911 changed from using the default compression for libz to using the compression set in pg_dump options, which defaults to 0. This actually seems like the rig

Re: [HACKERS] Supporting TAP tests with MSVC and Windows

On Fri, Jul 24, 2015 at 08:27:42PM +0300, Heikki Linnakangas wrote: > On 06/25/2015 07:40 AM, Michael Paquier wrote: > >Attached is v7, rebased on 0b157a0. > > Thanks! I fiddled with this a bit more, to centralize more of the > platform-dependent stuff to RewindTest.pm. Also, Windows doesn't have