Re: [HACKERS] proposal: session server side variables

2016-12-29 10:11 GMT+01:00 Fabien COELHO : > > There is big difference - you concept missing any safe point. You have to >> specify same information more times. >> > > Not necessarily, and if so maybe twice. I'm ok to recognize that it is a > difference between both

Re: [HACKERS] proposal: session server side variables

yes, I'll do it. But I'll remove some strange ideas. Why? I rather expect that you would comment that you find them strange and argue why: there is no reason to "remove" a concept idea as such at least early in a discussion process... Why persistent variables? Because *you* want

Re: [HACKERS] proposal: session server side variables

2016-12-29 11:42 GMT+01:00 Fabien COELHO : > > yes, I'll do it. >>> >> >> But I'll remove some strange ideas. >> > > Why? > > I rather expect that you would comment that you find them strange and > argue why: there is no reason to "remove" a concept idea as such at least >

Re: [HACKERS] Indirect indexes

Alvaro Herrera writes: > One exception: in htup_details.h I changed the definition of > HeapTupleHeaderIsHeapOnly() so that it returns a true boolean rather > than a random bit in a wider integer. Without this change, my compiler > complains when the result is passed as

Re: [HACKERS] Improving RLS planning

Dean Rasheed writes: > On 28 December 2016 at 19:12, Tom Lane wrote: >> [ getting back to this patch finally... ] I made the suggested change >> to that test case, and what I see is a whole lot of "NOTICE: snooped value >> = whatever" outputs. >>

Re: [HACKERS] VACUUM FULL Error

Hi there Can this be forwarded to someone who can assist with this query? Thank you, Patrick Hayes From: Hayes, Patrick Sent: 29 December 2016 12:26 To: 'pgsql-hackers@postgresql.org' Subject: FW: VACUUM FULL Error Hi there Any suggestion how to get around this

[HACKERS] FW: VACUUM FULL Error

Hi there Any suggestion how to get around this issue I am having with vacuum command I’m running on 8.1 version of prostgre SQL. The VACUUM FULL command seems to get stuck on vacuuming "pg_catalog.pg_largeobject" (last message for Verbose) Now attempting below - but not hopeful that it will

Re: [HACKERS] proposal: session server side variables

Hello Pavel, There are two concepts - both can be implemented, and used (can be used together). That is one point I would like to ascertain clearly and explicitely, so having various designs side by side, eg in the wiki page, would help if and where they interact. The second point I am

Re: [HACKERS] FW: VACUUM FULL Error

"Hayes, Patrick" writes: > Any suggestion how to get around this issue I am having with vacuum command > I’m running on 8.1 version of prostgre SQL. You realize, I hope, that 8.1 has been out of support for more than six years. > The VACUUM FULL command seems to get

Re: [HACKERS] Compiler warnings

On 12/06/2016 01:59 PM, Robert Haas wrote: > On Tue, Dec 6, 2016 at 3:46 PM, Stephen Frost wrote: >> Good thought, thanks! >> >> Updated patch attached with that change and I also added an Assert() to >> GetCachedPlan(), in case that code gets whacked around later and somehow

Re: [HACKERS] proposal: session server side variables

I newer talked about persistent data. I talked about persistent metadata. Sure, I finally understood that detail. Now if I hear "persistent variable", I by default understand that both metadata and data are persistent... It requires some effort to understand the subtelty. I really don't

Re: [HACKERS] proposal: session server side variables

2016-12-29 14:41 GMT+01:00 Pavel Stehule : > > > 2016-12-29 14:25 GMT+01:00 Fabien COELHO : > >> >> I newer talked about persistent data. I talked about persistent metadata. >>> >> >> Sure, I finally understood that detail. Now if I hear "persistent

Re: [HACKERS] proposal: session server side variables

2016-12-29 14:25 GMT+01:00 Fabien COELHO : > > I newer talked about persistent data. I talked about persistent metadata. >> > > Sure, I finally understood that detail. Now if I hear "persistent > variable", I by default understand that both metadata and data are >

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

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 change; creating such tables (or views) has never been anything but a foot-gun.

Re: [HACKERS] Improving RLS planning

On 28 December 2016 at 19:12, Tom Lane wrote: > Stephen Frost writes: >> * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >>> Hmm. I've not read any of the new code yet, but the fact that this >>> test now reduces to a one-time filter makes it effectively

Re: [HACKERS] make more use of RoleSpec struct

On 12/28/16 9:53 AM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> Here is a small cleanup patch to make more use of the RoleSpec >> struct/node throughout the parser to avoid casts and make the code more >> self-documenting. > > This makes sense to me. I started to do this at some point

Re: [HACKERS] proposal: session server side variables

Hello Jim, Yes if the private variable should be accessed. If the variable is private, then it is private and nothing is needed. Idem for public. Why force the extra busywork? Just allow for them to be public. There is no extra busywork, having possibly private session variables cost

Re: [HACKERS] proposal: session server side variables

2016-12-29 9:57 GMT+01:00 Fabien COELHO : > > Please, could you remove the part of the mail you are not responding to > and just keep the relevant part? > > Whatever the features and syntax, you can always shoot yourself in the >>> foot. >>> >> >> I disagree >> > > Hmmm... I

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

The way this patch has been written, it doesn't allow creating tables with unknown type columns, which was allowed earlier. That breaks backward compatibility. Users, who have created such tables will face problems while loading dumps from earlier versions. pg_upgrade might be an issue, but we may

Re: [HACKERS] proposal: session server side variables

2016-12-29 9:36 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > Hmmm... I know a little bit about that field, ISTM that you are speaking >>> of the current capabilities of a particular static analysis tool, but I'm >>> not sure that the tool capabilities could not be enhanced

Re: [HACKERS] proposal: session server side variables

CREATE FUNCTION setup_user(TEXT, TEXT) RETURNS BOOLEAN SECURITY DEFINER AS $$ CREATE FUNCTION isUserAuditor() RETURNS BOOLEAN SECURITY DEFINER AS $$ so what is worse - I did one new entry in pg_class and one entry in pg_attributes. You wrote two entries in pg_proc function - more you

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

On 29 December 2016 at 16:51, Craig Ringer wrote: > On 28 December 2016 at 22:16, Petr Jelinek > wrote: > >> About the patch, it looks good to me for master with the minor exception >> that: >>> + appendStringInfo(buf, "pageno %d,

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

On Thu, Dec 22, 2016 at 7:00 AM, Michael Paquier wrote: > Hi all, > > 2PC files are created using RecreateTwoPhaseFile() in two places currently: > - at replay on a XLOG_XACT_PREPARE record. > - At checkpoint with CheckPointTwoPhase(). > > Now RecreateTwoPhaseFile() is

Re: [HACKERS] proposal: session server side variables

Please, could you remove the part of the mail you are not responding to and just keep the relevant part? Whatever the features and syntax, you can always shoot yourself in the foot. I disagree Hmmm... I have succeeded in shotting myself in the foot with possibly every feature of every

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Thu, Dec 29, 2016 at 12:35 AM, Michael Paquier wrote: > On Wed, Dec 28, 2016 at 9:31 PM, Magnus Hagander > wrote: > > Conditional tests? It probably wouldn't hurt to have them, but that > would be > > something more generic (like we'd need

Re: [HACKERS] proposal: session server side variables

2016-12-29 9:46 GMT+01:00 Fabien COELHO : > > CREATE FUNCTION setup_user(TEXT, TEXT) >>> RETURNS BOOLEAN SECURITY DEFINER AS $$ >>> >> > CREATE FUNCTION isUserAuditor() >>>RETURNS BOOLEAN SECURITY DEFINER AS $$ >>> >> >> so what is worse - I did one new entry in

Re: [HACKERS] [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

On 28 December 2016 at 22:16, Petr Jelinek wrote: > About the patch, it looks good to me for master with the minor exception > that: >> + appendStringInfo(buf, "pageno %d, xid %u", >> + trunc.pageno, trunc.oldestXid); > > This should

Re: [HACKERS] proposal: session server side variables

Hello Pavel, Hmmm... I know a little bit about that field, ISTM that you are speaking of the current capabilities of a particular static analysis tool, but I'm not sure that the tool capabilities could not be enhanced to manage more things. It cannot be - the static analyze is limited to

Re: [HACKERS] proposal: session server side variables

There is big difference - you concept missing any safe point. You have to specify same information more times. Not necessarily, and if so maybe twice. I'm ok to recognize that it is a difference between both approaches, and an inconvenient of the one I'm proposing. There also see

Re: [HACKERS] proposal: session server side variables

2016-12-29 10:32 GMT+01:00 Pavel Stehule : > > > 2016-12-29 10:11 GMT+01:00 Fabien COELHO : > >> >> There is big difference - you concept missing any safe point. You have to >>> specify same information more times. >>> >> >> Not necessarily, and if so

Re: [HACKERS] proposal: session server side variables

[Oops, resent, wrong from address, please accept my apologies] Hello Pavel, There are two concepts - both can be implemented, and used (can be used together). That is one point I would like to ascertain clearly and explicitely, so having various designs side by side, eg in the wiki page,

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

1) I agree with Michael that we should make this change backward compatible. It would help PostgreSQL image if we did not break everyone's code. It costs businesses money to rewrite code (e.g. middle tier software, backup tools, etc), test and redeploy to their customers. 2) We decided to

Re: [HACKERS] gettimeofday is at the end of its usefulness?

* Tom Lane: > On Linux (RHEL6, 2.4GHz x86_64), I find that gettimeofday(), > clock_gettime(CLOCK_MONOTONIC), and clock_gettime(CLOCK_REALTIME) > all take about 40ns. Of course gettimeofday() only has 1us resolution, > but the other two have perhaps 10ns resolution (I get no duplicate > readings

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

Cynthia, * Cynthia Shang (cynthia.sh...@crunchydata.com) wrote: > 1) I agree with Michael that we should make this change backward compatible. > It would help PostgreSQL image if we did not break everyone's code. It costs > businesses money to rewrite code (e.g. middle tier software, backup

Re: [HACKERS] proposal: session server side variables

On 12/29/2016 02:23 PM, Fabien COELHO wrote: There is a singleton table :) create table foo(x integer unique not null default 1 check(x = 1), y integer); insert into foo(y) values(100); analyze foo; I know this one. It can be empty, which a singleton cannot be. For a singleton table,

Re: [HACKERS] proposal: session server side variables

2016-12-29 20:23 GMT+01:00 Fabien COELHO : > > There is a singleton table :) >> >> create table foo(x integer unique not null default 1 check(x = 1), y >> integer); >> insert into foo(y) values(100); >> analyze foo; >> > > I know this one. It can be empty, which a singleton

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

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. I'm not trying to pick a fight, I just think the pros should outweigh the cons when choosing a path forward. In this case I see

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

Cynthia, Please don't top-post on the PG mailing lists but rather write responses in-line. * 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

Re: [HACKERS] proposal: session server side variables

There is a singleton table :) create table foo(x integer unique not null default 1 check(x = 1), y integer); insert into foo(y) values(100); analyze foo; 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

Re: [HACKERS] Improving RLS planning

On 29 December 2016 at 15:55, Tom Lane wrote: > Dean Rasheed writes: >> On 28 December 2016 at 19:12, Tom Lane wrote: >>> [ getting back to this patch finally... ] I made the suggested change >>> to that test case, and what I

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Florian Weimer writes: > * Tom Lane: >> On Linux (RHEL6, 2.4GHz x86_64), I find that gettimeofday(), >> clock_gettime(CLOCK_MONOTONIC), and clock_gettime(CLOCK_REALTIME) >> all take about 40ns. Of course gettimeofday() only has 1us resolution, >> but the other two have

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Thomas Munro writes: > On Tue, Dec 27, 2016 at 10:34 AM, Tom Lane wrote: >> However, it seems that these impressive results date back only to >> June 2012, cf >> https://github.com/freebsd/freebsd/commit/13a9f42818f6b89a72b3e40923be809b490400d8

Re: [HACKERS] Increase pltcl test coverage

On 10/31/16 3:24 PM, Jim Nasby wrote: This patch increases test coverage for pltcl, from 70% to 83%. Aside from that, the work on this uncovered 2 new bugs (the trigger return one I just submitted, as well as a bug in the SRF/composite patch). Rebased patch attached. Test coverage is now at

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Tue, Dec 27, 2016 at 10:34 AM, Tom Lane wrote: > I also tried FreeBSD 11.0 on another Mac (2.3GHz x86_64), > and found that gettimeofday as well as basically all their > clock_gettime variants run in 27 to 28 ns; and clock_gettime > reliably delivers full precision, except

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

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_SEdngiNFkeXrA3xUSDPPORQvsWVPdKqnA%40mail.gmail.com I'm no longer seeing the failed

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

Thomas Munro writes: > [2. text/x-diff; fix-dsa-tranche-registration.patch] Fuzzing with the patch applied hasn't triggered the crash so far. It did happen 5 times with the same amount of fuzzing before patching. regards, Andreas -- Sent via pgsql-hackers mailing list

Re: [HACKERS] background sessions

On 12/16/16 10:38 AM, Andrew Borodin wrote: > 2016-12-16 20:17 GMT+05:00 Peter Eisentraut > : >>> And one more thing... Can we have BackgroundSessionExecute() splitted >>> into two parts: start query and wait for results? >>> It would allow pg_background to reuse

Re: [HACKERS] Faster methods for getting SPI results

On 12/27/16 9:10 PM, Craig Ringer wrote: On 28 December 2016 at 09:58, Jim Nasby wrote: I've looked at this some more, and ITSM that the only way to do this without some major surgery is to create a new type of Destination specifically for SPI that allows for the

Re: [HACKERS] gettimeofday is at the end of its usefulness?

Haribabu Kommi writes: > Attached a patch that replaces most of the getimeofday function calls, > except timeofday(user callable) and GetCurrentTimestamp functions. I looked at this for awhile and could not convince myself that it's a good idea. Trying to do

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

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 change;

Re: [HACKERS] Support for pg_receivexlog --format=plain|tar

On Thu, Dec 29, 2016 at 6:13 PM, Magnus Hagander wrote: > On Thu, Dec 29, 2016 at 12:35 AM, Michael Paquier > wrote: >> On Wed, Dec 28, 2016 at 9:31 PM, Magnus Hagander >> wrote: >> >> - I have switched the directory method to

[HACKERS] Broken atomics code on PPC with FreeBSD 10.3

In pursuit of knowledge about clock_gettime(), I installed FreeBSD 10.3 on a PowerBook I had laying about. I was disappointed to find out that HEAD fails regression tests on that platform: *** /usr/home/tgl/pgsql/src/test/regress/expected/lock.out Thu Dec 29 19:37:50 2016 ---

Re: [HACKERS] proposal: session server side variables

Not sure if term "singleton" is valid in relation database. The term is valid in mathematics: The relational model is an extension of set theory, eg the algebra includes set operators such as union, intersection, difference... In the set theory, a singleton designate is a

Re: [HACKERS] proposal: session server side variables

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 than that, if that's what you really want. Create the table with an

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

On 28 December 2016 at 20:11, Fabien COELHO wrote: > > Hello Tom, > >> [...] It's touching every single utility statement type, which is not only >> pretty invasive in itself, but will break any pending patches that add more >> utility statement types. > > > Yep, but it is

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

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 want to call

[HACKERS] What is "index returned tuples in wrong order" for recheck supposed to guard against?

I've been trying to troubleshoot the cause of this PostGIS recheck bug we have reported by two people so far. The last test was a nice simple repeatable one that triggered the issue: https://trac.osgeo.org/postgis/ticket/3418 from what I have seen this only affects cases where we are doing a

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Hello Craig, [...] It's touching every single utility statement type, which is not only pretty invasive in itself, but will break any pending patches that add more utility statement types. Yep, but it is limited to headers and the break is trivial... I'm not sure how else that part can be