Re: [HACKERS] proposal: session server side variables

2016-12-31 1:16 GMT+01:00 Craig Ringer : > On 30 December 2016 at 21:00, Fabien COELHO wrote: > > > As for "slow", I have just tested overheads with pgbench, comparing a > direct > > arithmetic operation (as a proxy to a fast session variable >

Re: [HACKERS] use strict in all Perl programs

On Sat, Dec 31, 2016 at 3:07 PM, Peter Eisentraut wrote: > Here is a patch to add 'use strict' to all Perl programs (that I could > find), or move it to the right place where it was already there. I > think that is a pretty standard thing to do nowadays. > > I

Re: [HACKERS] sequence data type

On 9/8/16 4:06 PM, Peter Eisentraut wrote: > On 9/3/16 2:41 PM, Vik Fearing wrote: >> On 08/31/2016 06:22 AM, Peter Eisentraut wrote: >>> Here is a patch that adds the notion of a data type to a sequence. So >>> it might be CREATE SEQUENCE foo AS integer. The types are restricted to >>>

[HACKERS] cast result of copyNode()

In order to reduce the number of useless casts and make the useful casts more interesting, here is a patch that automatically casts the result of copyNode() back to the input type, if the compiler supports something like typeof(), which most current compilers appear to. That gets us some more

[HACKERS] use strict in all Perl programs

Here is a patch to add 'use strict' to all Perl programs (that I could find), or move it to the right place where it was already there. I think that is a pretty standard thing to do nowadays. I tried testing the changes in pgcheckdefines, but it just spits out nonsense before and after. --

[HACKERS] port of INSTALL file generation to XSLT

A further step toward getting rid of the DSSSL tool chain requirement, here is a patch to change the generation of the text INSTALL file to use XLST and Pandoc. The change to Pandoc is not essential to this change, but it creates much better looking output and simplifies the locale/encoding

[HACKERS] Group clear xid can leak semaphore count

During the review of Group update Clog patch [1], Dilip noticed an issue with the patch where it can leak the semaphore count in one of the corner case. I have checked and found that similar issue exists for Group clear xid (ProcArrayGroupClearXid) as well. I think the reason why this problem is

Re: [HACKERS] Add doc advice about systemd RemoveIPC

On 12/30/16 3:59 AM, Magnus Hagander wrote: > I wonder if I missed part of the discussions around this, so maybe my > understanding of the cases where this occurs is wrong, but isn't it the > case of pretty much all (or actually) all the packaged versions of > postgresql out there (debian, redhat

Re: [HACKERS] [sqlsmith] Short reads in hash indexes

On Fri, Dec 30, 2016 at 3:45 AM, Andreas Seltenreich wrote: > Amit Kapila writes: > >> Can you please try with the patch posted on hash index thread [1] to >> see if you can reproduce any of these problems? >> >> [1] - >>

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Thu, Dec 29, 2016 at 10:41 AM, Dilip Kumar wrote: > > I have done one more pass of the review today. I have few comments. > > + if (nextidx != INVALID_PGPROCNO) > + { > + /* Sleep until the leader updates our XID status. */ > + for (;;) > + { > + /* acts as a read

[HACKERS] Add support to COMMENT ON CURRENT DATABASE

Hi all, The attached patch is reworked from a previous one [1] to better deal with get_object_address and pg_get_object_address. Regards, [1] https://www.postgresql.org/message-id/20150317171836.gc10...@momjian.us -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira:

Re: [HACKERS] Unusable SP-GiST index

I wrote: > Maybe we should redefine the API as involving a TupleTableSlot that > the AM is supposed to fill --- basically, moving StoreIndexTuple > out of the common code in nodeIndexonlyscan.c and requiring the AM > to do that work. The possible breakage of third-party code is a > bit annoying,

Re: [HACKERS] Unusable SP-GiST index

Vik Fearing writes: > While trying to find a case where spgist wins over btree for text, I > came across the following behavior which I would consider a bug: > CREATE TABLE texts (value text); > INSERT INTO texts SELECT repeat('a', (2^20)::integer); > CREATE INDEX ON texts

Re: [HACKERS] Potential data loss of 2PC files

On Fri, Dec 30, 2016 at 10:59 PM, Ashutosh Bapat wrote: >> >> Well, flushing the meta-data of pg_twophase is really going to be far >> cheaper than the many pages done until CheckpointTwoPhase is reached. >> There should really be a check on serialized_xacts for

Re: [HACKERS] proposal: session server side variables

On 30 December 2016 at 21:00, Fabien COELHO wrote: > As for "slow", I have just tested overheads with pgbench, comparing a direct > arithmetic operation (as a proxy to a fast session variable consultation) to > constant returning plpgsql functions with security definer and

Re: [HACKERS] Indirect indexes

Attached is v4, which fixes a couple of relatively minor bugs. There are still things to tackle before this is committable, but coding review of the new executor node would be welcome. The big remaining item is still fitting the PK data in TIDs 6 bytes. I've been looking at reworking the btree

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 12/30/2016 06:46 PM, David Fetter wrote: > On Fri, Dec 30, 2016 at 09:57:25AM -0500, Stephen Frost wrote: > >> Let's make this a clean break/change. > > +1 +1 -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise,

[HACKERS] Unusable SP-GiST index

While trying to find a case where spgist wins over btree for text, I came across the following behavior which I would consider a bug: CREATE TABLE texts (value text); INSERT INTO texts SELECT repeat('a', (2^20)::integer); CREATE INDEX ON texts USING spgist (value); SET enable_seqscan = off; TABLE

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

Here's a version with fixed comments. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index ea579a0..19edbdf 100644 ---

Re: [HACKERS] proposal: session server side variables

2016-12-30 18:39 GMT+01:00 Fabien COELHO : > > DECLARE @var EXTERNAL >>> >>> I do not know what you mean by 'EXTERNAL'. >>> >> >> it means "used as shared in session" >> > > Shared by whom? There is no such thing in the proposal I have made on the > wiki or in mails. In

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Fri, Dec 30, 2016 at 09:57:25AM -0500, Stephen Frost wrote: > Let's make this a clean break/change. +1 If there are known management gizmos to notify, it'd be nice to try to give them some sort of warning, but even for them, the release notes should spell it out clearly. That business

Re: [HACKERS] proposal: session server side variables

DECLARE @var EXTERNAL I do not know what you mean by 'EXTERNAL'. it means "used as shared in session" Shared by whom? There is no such thing in the proposal I have made on the wiki or in mails. In the proposal variables are private to the role which creates them. It is possible to

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

Andres Freund writes: > On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane > wrote: >> and got no warnings and the attached output. I'm not very good at >> reading PPC assembler, but I think what is happening in the "char" case is >> that >> gcc is

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane wrote: >and got no warnings and the attached output. I'm not very good at >reading >PPC assembler, but I think what is happening in the "char" case is that >gcc is trying to emulate a byte-wide operation using a word-wide

Re: [HACKERS] proposal: session server side variables

2016-12-30 15:34 GMT+01:00 Fabien COELHO : > > Hello again, > > So any dynamic created object and related operations are not checkable by >>> plpgsql_check (or any tool). >>> >>> NO. Your first sentence does not imply this very general statement. >>> >> >> If you

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane wrote: >Andres Freund writes: >> On 2016-12-30 00:44:33 -0500, Tom Lane wrote: >>> Perhaps it could be argued that there's a FreeBSD compiler bug here, >>> but what I'm wondering is why configure

Re: [HACKERS] Logical Replication WIP

On 2016-12-30 11:53, Petr Jelinek wrote: I rebased this for the changes made to inheritance and merged in the 0002-Add-SUBSCRIPTION-catalog-and-DDL-v16.patch.gz (~31 KB) couple of orthography errors in messages --- ./src/backend/commands/subscriptioncmds.c.orig 2016-12-30

Re: [HACKERS] Logical Replication WIP

On 2016-12-30 11:53, Petr Jelinek wrote: I rebased this for the changes made to inheritance and merged in the 0002-Add-SUBSCRIPTION-catalog-and-DDL-v16.patch.gz (~31 KB) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

Andres Freund writes: > On 2016-12-30 00:44:33 -0500, Tom Lane wrote: >> Perhaps it could be argued that there's a FreeBSD compiler bug here, >> but what I'm wondering is why configure believes that this: >> >> [char lock = 0; >> __sync_lock_test_and_set(, 1); >>

Re: [HACKERS] Add doc advice about systemd RemoveIPC

On 30 December 2016 at 16:59, Magnus Hagander wrote: > On Wed, Dec 28, 2016 at 4:34 AM, Peter Eisentraut > wrote: >> >> Here is a patch to add some information about the systemd RemoveIPC >> issue to the documentation, sort of in the spirit

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Dec 30, 2016 at 8:08 PM, Vladimir Rusinov wrote: > > Now, I'm not sure whether it is worth maintaining function aliases. Assuming > > these are indeed trivial (can somebody point me to example?) I see roughly > >

Re: [HACKERS] proposal: session server side variables

Hello again, So any dynamic created object and related operations are not checkable by plpgsql_check (or any tool). NO. Your first sentence does not imply this very general statement. If you have not unique definition, you cannot to it. There is not possibility different between typo

Re: [HACKERS] proposal: session server side variables

2016-12-30 12:01 GMT+01:00 Pavel Stehule : > > > 2016-12-30 10:29 GMT+01:00 Craig Ringer : > >> On 30 December 2016 at 16:46, Fabien COELHO wrote: >> > >> >> Pavel's personal requirements include that it be well suited for >>

Re: [HACKERS] Microvacuum support for Hash Index

On 11/11/2016 12:11 AM, Ashutosh Sharma wrote: Hi Jesper, Some initial comments. _hash_vacuum_one_page: + END_CRIT_SECTION(); + _hash_chgbufaccess(rel, metabuf, HASH_READ, HASH_NOLOCK); The _hash_chgbufaccess() needs a comment. You also need a place where you

Re: [HACKERS] proposal: session server side variables

2016-12-30 14:45 GMT+01:00 Fabien COELHO : > > Please Pavel, could you avoid citing a whole long mail just for commenting > one point? > > * Why is it so necessary for plpgsql variables to be implemented as >>> persistent entities that are in the catalogs in order for you to

Re: [HACKERS] Potential data loss of 2PC files

> > Well, flushing the meta-data of pg_twophase is really going to be far > cheaper than the many pages done until CheckpointTwoPhase is reached. > There should really be a check on serialized_xacts for the > non-recovery code path, but considering how cheap that's going to be > compared to the

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Fri, Dec 30, 2016 at 1:30 PM, Ashutosh Bapat wrote: > On Thu, Dec 29, 2016 at 8:18 PM, Tom Lane wrote: >> Ashutosh Bapat writes: >>> The way this patch has been written, it doesn't allow creating tables >>>

Re: [HACKERS] Potential data loss of 2PC files

On Fri, Dec 30, 2016 at 5:20 PM, Ashutosh Bapat wrote: > As per the prologue of the function, it doesn't expect any 2PC files > to be written out in the function i.e. between two checkpoints. Most > of those are created and deleted between two checkpoints. Same

Re: [HACKERS] proposal: session server side variables

Please Pavel, could you avoid citing a whole long mail just for commenting one point? * Why is it so necessary for plpgsql variables to be implemented as persistent entities that are in the catalogs in order for you to achieve the static checking you want to? Is this due to limitations of

Re: [HACKERS] multivariate statistics (v19)

On 12/12/16 22:50, Tomas Vondra wrote: > On 12/12/2016 12:26 PM, Amit Langote wrote: >> >> Hi Tomas, >> >> On 2016/10/30 4:23, Tomas Vondra wrote: >>> Hi, >>> >>> Attached is v20 of the multivariate statistics patch series, doing >>> mostly >>> the changes outlined in the preceding e-mail from

Re: [HACKERS] multivariate statistics (v19)

On 12/12/16 22:50, Tomas Vondra wrote: >> + >> +SELECT pg_mv_stats_dependencies_show(stadeps) >> + FROM pg_mv_statistic WHERE staname = 's1'; >> + >> + pg_mv_stats_dependencies_show >> +--- >> + (1) => 2, (2) => 1 >> +(1 row) >> + >> >> Couldn't this somehow show

Re: [HACKERS] proposal: session server side variables

2016-12-30 11:03 GMT+01:00 Craig Ringer : > On 30 December 2016 at 17:29, Craig Ringer wrote: > > > So lets take a step back or eight and ask "why?" > > Oh, and speaking of, I see Pavel's approach as looking for a > PostgreSQL-adapted way to do

Re: [HACKERS] proposal: session server side variables

Hello Craig, A long mail with many questions, that I tried to answered clearly, the result is too long... [...] I have no opinion here, as I've not seen plpgsql_check nor do I understand the issues Pavel perceives with having dynamic definitions of variables. I understand that Pavel

Re: [HACKERS] pg_dump versus rules, once again

On 30 December 2016 at 11:58, Benedikt Grundmann wrote: > > On 17 November 2016 at 03:45, Robert Haas wrote: > >> On Wed, Nov 16, 2016 at 10:14 PM, Tom Lane wrote: >> > Robert Haas writes: >> >> On

Re: [HACKERS] pg_dump versus rules, once again

On 17 November 2016 at 03:45, Robert Haas wrote: > On Wed, Nov 16, 2016 at 10:14 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Wed, Nov 16, 2016 at 10:00 PM, Tom Lane wrote: > >>> The changes in

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Fri, Dec 30, 2016 at 8:08 PM, Vladimir Rusinov wrote: > Now, I'm not sure whether it is worth maintaining function aliases. Assuming > these are indeed trivial (can somebody point me to example?) I see roughly > the same amount of downsides both ways. > Having aliases

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Fri, Dec 30, 2016 at 2:59 AM, Stephen Frost wrote: > All backwards incompatible changes are judgement calls and people are > certainly welcome to have different opinions. I have a pretty strong > feeling about this particular change being worthwhile and also pretty > long

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

Hi, On 2016-12-30 00:44:33 -0500, Tom Lane wrote: > *** /usr/home/tgl/pgsql/src/test/regress/expected/lock.out Thu Dec 29 > 19:37:50 2016 > --- /usr/home/tgl/pgsql/src/test/regress/results/lock.out Fri Dec 30 > 00:31:01 2016 > *** > *** 63,70 > -- atomic ops tests

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Dec 29, 2016 at 5:59 PM, Stephen Frost wrote: > I have a pretty strong > feeling about this particular change being worthwhile and also pretty > long overdue. > Yeah, sorry for that. I should be able to make some progress early January. -- Vladimir Rusinov Storage

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Dec 29, 2016 at 5:48 PM, Cynthia Shang < cynthia.sh...@crunchydata.com> wrote: > I have never heard of coding standards where naming conventions required a > function/variable name match a directory or file name. It seems that would > be restrictive. > This is not about coding standard,

Re: [HACKERS] proposal: session server side variables

2016-12-30 10:29 GMT+01:00 Craig Ringer : > On 30 December 2016 at 16:46, Fabien COELHO wrote: > > > >> Pavel's personal requirements include that it be well suited for > >> static analysis of plpgsql using his plpgsql_check tool. So he wants > >>

Re: [HACKERS] proposal: session server side variables

On 30 December 2016 at 17:29, Craig Ringer wrote: > So lets take a step back or eight and ask "why?" Oh, and speaking of, I see Pavel's approach as looking for a PostgreSQL-adapted way to do something like Oracle's PL/SQL package variables. Right Pavel? If so, their

Re: [HACKERS] proposal: session server side variables

On 30 December 2016 at 16:46, Fabien COELHO wrote: > >> Pavel's personal requirements include that it be well suited for >> static analysis of plpgsql using his plpgsql_check tool. So he wants >> persistent definitions. > > > I've been in static analysis for the last 25

Re: [HACKERS] Add doc advice about systemd RemoveIPC

On Wed, Dec 28, 2016 at 4:34 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > Here is a patch to add some information about the systemd RemoveIPC > issue to the documentation, sort of in the spirit of the OOM discussion > nearby. > I wonder if I missed part of the discussions

Re: [HACKERS] proposal: session server side variables

Pavel's personal requirements include that it be well suited for static analysis of plpgsql using his plpgsql_check tool. So he wants persistent definitions. I've been in static analysis for the last 25 years, and the logic of this statement fails me. Pavel wants that the plpgsql_check

Re: [HACKERS] Potential data loss of 2PC files

On Fri, Dec 30, 2016 at 11:22 AM, Michael Paquier wrote: > On Thu, Dec 29, 2016 at 6:41 PM, Ashutosh Bapat > wrote: >> I agree with this. >> If no prepared transactions were required to be fsynced >> CheckPointTwoPhase(), do we want to

Re: [HACKERS] proposal: session server side variables

On 30 December 2016 at 14:50, Fabien COELHO wrote: > >>> I know this one. It can be empty, which a singleton cannot be. For a >>> singleton table, you should have one and only one row, you cannot insert or >>> delete, so this is only part of the real thing. >> >> >> Surely we