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
> consultation) to
> > constant returning plpgsql func
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 tried testing the changes in pgcheck
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
>>> int{2,4,8
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 type
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.
--
Pete
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 handli
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
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 e
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] -
>> https://www.postgresql.org/message-id/CAA4eK1Kf6tOY0oVz_SEdngiNFkeXrA3xUSDP
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 barrier */
> + PGSemaphoreLock
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: http://ww
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, b
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 USING spgist (value);
>
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 the
>> non-recovery code path, but
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 security
> invoker, on
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 co
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, Formatio
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
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
--- a/src/backen
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 the proposal variables
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 where
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 fin
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 trying to emulate a byte-wide operation usin
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 one,
>ie an lwarx/stw
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 have not unique definit
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 believes that this:
>>>
>>> [char lock = 0;
>>
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 16:44:31.95729843
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:
http://ww
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(&lock, 1);
>> __sync_lock_release(&lock);]
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 of the OOM discussion
>> nearby.
>
>
> I wonder if I mis
* 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
> > the same amount of dow
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 and
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
>> >> static analysis of plpgsql using his plpgsql_check tool. So he wants
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 cal
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
>>> achieve the static
>
> 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 res
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
>>> with unknown type columns, which was allowed earlier.
>>
>> Yes, that's an intentional
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 would
> be true for recovery as well
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
you
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 Octo
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 actual
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 something like Oracle's PL/SQL package
> variab
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 assu
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 Wed, Nov 16, 2016 at 10:00 PM, Tom Lane wrote:
>> >>> The changes in pg_backup_archiver.c would
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 pg_backup_archiver.c would have to be back-patched
> >>> into all versions supporting --if-ex
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 raises additional question
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 overdue.
The renamin
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
>
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 SRE, Google Ireland
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, t
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
> >> persistent definitions.
> >
> >
> > I've been in
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 properties are, as far
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 years, and the logic of thi
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 aro
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 tool
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 still fsync the directory?
>> Probably not.
>>
>> May be you
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 can do a bit better t
57 matches
Mail list logo