Re: [HACKERS] Compression of full-page-writes

On 30.08.2013 05:55, Fujii Masao wrote: * Result [tps] 1386.8 (compress_backup_block = off) 1627.7 (compress_backup_block = on) It would be good to check how much of this effect comes from reducing the amount of data that needs to be CRC'd, because there has been some talk of replaci

Re: [HACKERS] Compression of full-page-writes

On Fri, Aug 30, 2013 at 2:37 PM, Nikhil Sontakke wrote: > Hi Fujii-san, > > I must be missing something really trivial, but why not try to compress all > types of WAL blocks and not just FPW? The size of non-FPW WAL is small, compared to that of FPW. I thought that compression of such a small WAL

Re: [HACKERS] Compression of full-page-writes

On Thu, Aug 29, 2013 at 10:55 PM, Fujii Masao wrote: >> I suppose that the cost of the random I/O involved would >> probably dominate just as with compress_backup_block = off. That said, >> you've used an SSD here, so perhaps not. > > Oh, maybe my description was confusing. full_page_writes was en

Re: [HACKERS] Behaviour of take over the synchronous replication

On Wed, Aug 28, 2013 at 10:59 PM, Amit Kapila wrote: > On Tue, Aug 27, 2013 at 4:51 PM, Sawada Masahiko > wrote: >> On Sun, Aug 25, 2013 at 3:21 PM, Amit Kapila wrote: >>> On Sat, Aug 24, 2013 at 2:46 PM, Sawada Masahiko >>> wrote: On Sat, Aug 24, 2013 at 3:14 AM, Josh Berkus wrote: >>>

Re: [HACKERS] Compression of full-page-writes

On Fri, Aug 30, 2013 at 2:32 PM, KONDO Mitsumasa wrote: > (2013/08/30 11:55), Fujii Masao wrote: >> >> * Benchmark >>pgbench -c 32 -j 4 -T 900 -M prepared >>scaling factor: 100 >> >>checkpoint_segments = 1024 >>checkpoint_timeout = 5min >>(every checkpoint during benchmark were

Re: [HACKERS] Compression of full-page-writes

On Fri, Aug 30, 2013 at 1:43 PM, Amit Kapila wrote: > On Fri, Aug 30, 2013 at 8:25 AM, Fujii Masao wrote: >> Hi, >> >> Attached patch adds new GUC parameter 'compress_backup_block'. >> When this parameter is enabled, the server just compresses FPW >> (full-page-writes) in WAL by using pglz_compre

Re: [HACKERS] Compression of full-page-writes

On Fri, Aug 30, 2013 at 11:55 AM, Fujii Masao wrote: > My idea is very simple, just compress FPW because FPW is > a big part of WAL. I used pglz_compress() as a compression method, > but you might think that other method is better. We can add > something like FPW-compression-hook for that later. T

Re: [HACKERS] Compression of full-page-writes

On Fri, Aug 30, 2013 at 12:43 PM, Peter Geoghegan wrote: > On Thu, Aug 29, 2013 at 7:55 PM, Fujii Masao wrote: >> [the amount of WAL generated during running pgbench] >> 4302 MB (compress_backup_block = off) >> 1521 MB (compress_backup_block = on) > > Interesting. > > I wonder, what is the

[HACKERS] proposal: allow a execution of VOID function without PERFORM keyword.

Hello A perform keyword is semantically useless for VOID functions. So it can be optional for start of any function. The function type cannot be checked in compile time - so result will be checked in execution time. I hope so 9.4 will be support deep checking in some step between compilation and

Re: [HACKERS] Compression of full-page-writes

Hi Fujii-san, I must be missing something really trivial, but why not try to compress all types of WAL blocks and not just FPW? Regards, Nikhils On Fri, Aug 30, 2013 at 8:25 AM, Fujii Masao wrote: > Hi, > > Attached patch adds new GUC parameter 'compress_backup_block'. > When this parameter i

Re: [HACKERS] Compression of full-page-writes

(2013/08/30 11:55), Fujii Masao wrote: * Benchmark pgbench -c 32 -j 4 -T 900 -M prepared scaling factor: 100 checkpoint_segments = 1024 checkpoint_timeout = 5min (every checkpoint during benchmark were triggered by checkpoint_timeout) Did you execute munual checkpoint before star

Re: [HACKERS] Variadic aggregates vs. project policy

2013/8/30 Andrew Dunstan > > On 08/29/2013 05:37 PM, Josh Berkus wrote: > >> Tom, >> >> On further reflection, what the "policy" was actually about was not that >>> we should forbid users from creating potentially-confusing aggregates >>> themselves, but only that we'd avoid having any *built in

Re: [HACKERS] Compression of full-page-writes

On Fri, Aug 30, 2013 at 8:25 AM, Fujii Masao wrote: > Hi, > > Attached patch adds new GUC parameter 'compress_backup_block'. > When this parameter is enabled, the server just compresses FPW > (full-page-writes) in WAL by using pglz_compress() before inserting it > to the WAL buffers. Then, the com

Re: [HACKERS] Compression of full-page-writes

On Thu, Aug 29, 2013 at 7:55 PM, Fujii Masao wrote: > [the amount of WAL generated during running pgbench] > 4302 MB (compress_backup_block = off) > 1521 MB (compress_backup_block = on) Interesting. I wonder, what is the impact on recovery time under the same conditions? I suppose that the

Re: [HACKERS] Compression of full-page-writes

(2013/08/30 12:07), Satoshi Nagayasu wrote: (2013/08/30 11:55), Fujii Masao wrote: Hi, Attached patch adds new GUC parameter 'compress_backup_block'. When this parameter is enabled, the server just compresses FPW (full-page-writes) in WAL by using pglz_compress() before inserting it to the

Re: [HACKERS] Compression of full-page-writes

(2013/08/30 11:55), Fujii Masao wrote: Hi, Attached patch adds new GUC parameter 'compress_backup_block'. When this parameter is enabled, the server just compresses FPW (full-page-writes) in WAL by using pglz_compress() before inserting it to the WAL buffers. Then, the compressed FPW is decomp

[HACKERS] Compression of full-page-writes

Hi, Attached patch adds new GUC parameter 'compress_backup_block'. When this parameter is enabled, the server just compresses FPW (full-page-writes) in WAL by using pglz_compress() before inserting it to the WAL buffers. Then, the compressed FPW is decompressed in recovery. This is very simple pat

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thu, Aug 29, 2013 at 9:13 AM, Robert Haas wrote: > I think the goals of this patch should be to (1) let users of other > clients manipulate the startup configuration just as easily as we can > already do using pgAdmin and (2) remove some of the concurrency > hazards that pgAdmin introduces, for

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost wrote: > > I'm not talking about malicious DBAs but rather a generally > > knowledgable DBA who changed shared_buffers up too high and then leaves on > > vacation, while the OPs guys need to do a database

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

Robert, Was working on replying to this, but got distracted.. * Robert Haas (robertmh...@gmail.com) wrote: > To be honest, I think the argument that this is dangerous is pretty > ridiculous. AFAICS, the only argument anyone's advanced for this > being dangerous is the theory that you might accid

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thu, Aug 29, 2013 at 8:07 PM, Stephen Frost wrote: > Having 400 emails about it means it's contentious. That's quite different > from having a large demand. It does speak to the author's persistence as > well, but that shouldn't be a surprise. Yet you can't ignore the fact that many people on

Re: [HACKERS] WAL CPU overhead/optimization (was Master-slave visibility order)

On Fri, Aug 30, 2013 at 3:02 AM, Andres Freund wrote: > I am not sure "hot cache large buffer performance" is really the > interesting case. Most of the XLogInsert()s are pretty small in the > common workloads. I vaguely recall trying 8 and getting worse > performance on many workloads, but that m

Re: [HACKERS] dynamic shared memory

On 8/13/13 8:09 PM, Robert Haas wrote: is removed, the segment automatically goes away (we could allow for server-lifespan segments as well with only trivial changes, but I'm not sure whether there are compelling use cases for that). To clarify... you're talking something that would intentional

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thursday, August 29, 2013, Andres Freund wrote: > > To quote Robert two mails up: > > > Huh? The problem with adminpack is that it doesn't let you modify > > individual configuration settings. All you can do is rewrite an > > entire file. That's clearly fixable. > I guess somebody could wri

Re: [HACKERS] Properly initialize negative/empty cache entries in relfilenodemap

Hi, On Thu, Aug 29, 2013 at 2:35 PM, MauMau wrote: > > Great! Could anybody find the root cause for the following memory leak > problem, and if possible, fix this? > > http://www.postgresql.org/**message-id/**214653D8DF574BFEAA6ED53E545E99** > E4@maumau

Re: [HACKERS] WAL CPU overhead/optimization (was Master-slave visibility order)

On 2013-08-30 02:53:54 +0300, Ants Aasma wrote: > On Fri, Aug 30, 2013 at 1:30 AM, Andres Freund wrote: > > On 2013-08-30 01:10:40 +0300, Ants Aasma wrote: > >> On Fri, Aug 30, 2013 at 12:33 AM, Andres Freund > >> wrote: > >> > FWIW, WAL is still the major bottleneck for INSERT heavy workloads.

Re: [HACKERS] WAL CPU overhead/optimization (was Master-slave visibility order)

On Fri, Aug 30, 2013 at 1:30 AM, Andres Freund wrote: > On 2013-08-30 01:10:40 +0300, Ants Aasma wrote: >> On Fri, Aug 30, 2013 at 12:33 AM, Andres Freund >> wrote: >> > FWIW, WAL is still the major bottleneck for INSERT heavy workloads. The >> > per CPU overhead actually minimally increased (at

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/30/2013 12:04 AM, Pavel Stehule wrote: > > > > 2013/8/29 David E. Wheeler > > > On Aug 29, 2013, at 2:48 PM, Andres Freund > wrote: > > >> You have yet to supply any arguments which support this position. > > >

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On 2013-08-29 18:42:13 -0400, Stephen Frost wrote: > On Thursday, August 29, 2013, Andres Freund wrote: > > The energy wasted in a good part of this massive 550+ messages thread is > > truly saddening. We all (c|sh)ould have spent that time making PG more > > awesome instead. > Perhaps not underst

Re: [HACKERS] Variadic aggregates vs. project policy

On 08/29/2013 05:37 PM, Josh Berkus wrote: Tom, On further reflection, what the "policy" was actually about was not that we should forbid users from creating potentially-confusing aggregates themselves, but only that we'd avoid having any *built in* aggregates with this hazard. So maybe I'm o

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thursday, August 29, 2013, Andres Freund wrote: > On 2013-08-29 15:07:35 -0400, Robert Haas wrote: > > I don't really see a compelling reason why it can't or shouldn't be in > > core. But having something better in contrib would still be an > > improvement on the status quo. > > I don't see mu

Re: [HACKERS] Variadic aggregates vs. project policy

On 2013-08-29 18:29:34 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-08-29 15:55:13 -0400, Tom Lane wrote: > >> For context see the thread starting here: > >> http://www.postgresql.org/message-id/aanlktikv5ok2ts8t6v+gsapte3n6tjq1jpphmzhg2...@mail.gmail.com > >> In that thread we agree

Re: [HACKERS] Variadic aggregates vs. project policy

Andres Freund writes: > On 2013-08-29 15:55:13 -0400, Tom Lane wrote: >> For context see the thread starting here: >> http://www.postgresql.org/message-id/aanlktikv5ok2ts8t6v+gsapte3n6tjq1jpphmzhg2...@mail.gmail.com >> In that thread we agreed that this "policy" might be rather squishy, >> but we

[HACKERS] WAL CPU overhead/optimization (was Master-slave visibility order)

On 2013-08-30 01:10:40 +0300, Ants Aasma wrote: > On Fri, Aug 30, 2013 at 12:33 AM, Andres Freund > wrote: > > FWIW, WAL is still the major bottleneck for INSERT heavy workloads. The > > per CPU overhead actually minimally increased (at least in my tests), it > > just scales noticeably better tha

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On 2013-08-29 15:07:35 -0400, Robert Haas wrote: > On Thu, Aug 29, 2013 at 1:42 PM, Stephen Frost wrote: > > To be honest, I don't find the arguments of "pgAdmin does it badly" > > nor "psql users want this ability" (which I find difficult to believe) > > to be particularlly compelling reasons to

Re: [HACKERS] Master-slave visibility order

On Fri, Aug 30, 2013 at 12:59 AM, Tom Lane wrote: > Andres Freund writes: >> But I think that actually coordinating a consistent visibility order >> between commit, wal insertion and the procarray would have bigger >> scalability impact than the second record. I might be missing some >> clever tr

Re: [HACKERS] Variadic aggregates vs. project policy

On 2013-08-29 15:55:13 -0400, Tom Lane wrote: > So I was hacking away at supporting variadic aggregates (per an internal > request at Salesforce), and had it pretty much working, when I came across > this old comment in opr_sanity.sql: > > -- Check that there are not aggregates with the same name

Re: [HACKERS] Master-slave visibility order

On Fri, Aug 30, 2013 at 12:33 AM, Andres Freund wrote: > FWIW, WAL is still the major bottleneck for INSERT heavy workloads. The > per CPU overhead actually minimally increased (at least in my tests), it > just scales noticeably better than before. Interesting. Do you have any insight what is beh

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 Andres Freund > On 2013-08-29 23:54:28 +0200, Pavel Stehule wrote: > > > No think so PERFORM is a significant problem. A mayor problem for > > > beginners is usually a fact, so PL/pgSQL is ALGOL like languages - and > they > > > don't know with these languages. Second problem is missing

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/29/2013 05:31 PM, David E. Wheeler wrote: On Aug 29, 2013, at 2:22 PM, Pavel Stehule wrote: Still I don't think so correct solution is enabling a unbound SELECTs, but correct is a fix a PERFORM and remove a necessity to use a PERFORM for call of VOID functions. Well, in this thread,

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 David E. Wheeler > On Aug 29, 2013, at 2:48 PM, Andres Freund wrote: > > >> You have yet to supply any arguments which support this position. > > > > I am not convinced that's enough of a reason, but the requirement to use > > PERFORM for SELECTs that aren't stored anywhere actually ha

Re: [HACKERS] Variadic aggregates vs. project policy

Josh Berkus wrote: > Tom, > > > On further reflection, what the "policy" was actually about was not that > > we should forbid users from creating potentially-confusing aggregates > > themselves, but only that we'd avoid having any *built in* aggregates with > > this hazard. So maybe I'm overthink

Re: [HACKERS] Master-slave visibility order

Andres Freund writes: > But I think that actually coordinating a consistent visibility order > between commit, wal insertion and the procarray would have bigger > scalability impact than the second record. I might be missing some > clever tricks here though. Yeah. ISTM the only way to really gua

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 2013-08-29 23:54:28 +0200, Pavel Stehule wrote: > > No think so PERFORM is a significant problem. A mayor problem for > > beginners is usually a fact, so PL/pgSQL is ALGOL like languages - and they > > don't know with these languages. Second problem is missing a more dynamic > > data structures.

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 Pavel Stehule > > > > 2013/8/29 Josh Berkus > >> On 08/29/2013 02:22 PM, Pavel Stehule wrote: >> > Still I don't think so correct solution is enabling a unbound SELECTs, >> but >> > correct is a fix a PERFORM and remove a necessity to use a PERFORM for >> call >> > of VOID functions. >

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:48 PM, Andres Freund wrote: >> You have yet to supply any arguments which support this position. > > I am not convinced that's enough of a reason, but the requirement to use > PERFORM for SELECTs that aren't stored anywhere actually has prevented > bugs for me. I am not con

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 Josh Berkus > On 08/29/2013 02:22 PM, Pavel Stehule wrote: > > Still I don't think so correct solution is enabling a unbound SELECTs, > but > > correct is a fix a PERFORM and remove a necessity to use a PERFORM for > call > > of VOID functions. > > You have yet to supply any arguments w

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 2013-08-29 14:40:24 -0700, Josh Berkus wrote: > On 08/29/2013 02:22 PM, Pavel Stehule wrote: > > Still I don't think so correct solution is enabling a unbound SELECTs, but > > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > > of VOID functions. > > You have yet to

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/29/2013 11:01 PM, David E. Wheeler wrote: > On Aug 29, 2013, at 1:11 PM, Pavel Stehule wrote: > >> I cannot to say what is good design for PL/pgSQL - only I feel so some >> variant of RETURN statement is not good, because semantic is significantly >> different. And I see a increasing incon

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:41 PM, Pavel Stehule wrote: > I am thinking, so I propose a enough solution for you - when you use CTE for > execution of VOID function, then result vill be VOID set, what we can accept > as undefined result, and in this case a PERFORM should not be required. If > CTE wil

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 David E. Wheeler > On Aug 29, 2013, at 2:22 PM, Pavel Stehule > wrote: > > > Still I don't think so correct solution is enabling a unbound SELECTs, > but correct is a fix a PERFORM and remove a necessity to use a PERFORM for > call of VOID functions. > > Well, in this thread, I believe

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/29/2013 02:22 PM, Pavel Stehule wrote: > Still I don't think so correct solution is enabling a unbound SELECTs, but > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > of VOID functions. You have yet to supply any arguments which support this position. Several pe

Re: [HACKERS] Variadic aggregates vs. project policy

Tom, > On further reflection, what the "policy" was actually about was not that > we should forbid users from creating potentially-confusing aggregates > themselves, but only that we'd avoid having any *built in* aggregates with > this hazard. So maybe I'm overthinking this, and the correct readi

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 2013-08-29 14:31:55 -0700, David E. Wheeler wrote: > On Aug 29, 2013, at 2:22 PM, Pavel Stehule wrote: > > > Still I don't think so correct solution is enabling a unbound SELECTs, but > > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > > of VOID functions. > >

Re: [HACKERS] Master-slave visibility order

On 2013-08-30 00:22:49 +0300, Ants Aasma wrote: > Hi, thanks for your reply. > > On Thu, Aug 29, 2013 at 6:40 PM, Robert Haas wrote: > > I think approach #2 is dead on arrival, at least as a default policy. > > It essentially amounts to requiring two commit records per transaction > > rather than

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 2:22 PM, Pavel Stehule wrote: > Still I don't think so correct solution is enabling a unbound SELECTs, but > correct is a fix a PERFORM and remove a necessity to use a PERFORM for call > of VOID functions. Well, in this thread, I believe you are the only person who feels th

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/29 David E. Wheeler > On Aug 29, 2013, at 1:11 PM, Pavel Stehule > wrote: > > > I cannot to say what is good design for PL/pgSQL - only I feel so some > variant of RETURN statement is not good, because semantic is significantly > different. And I see a increasing inconsistency between a o

Re: [HACKERS] Master-slave visibility order

Hi, thanks for your reply. On Thu, Aug 29, 2013 at 6:40 PM, Robert Haas wrote: > I think approach #2 is dead on arrival, at least as a default policy. > It essentially amounts to requiring two commit records per transaction > rather than one, and I think that has no chance of being acceptable. >

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On Aug 29, 2013, at 1:11 PM, Pavel Stehule wrote: > I cannot to say what is good design for PL/pgSQL - only I feel so some > variant of RETURN statement is not good, because semantic is significantly > different. And I see a increasing inconsistency between a original ADA and > PL/pgSQL. So

Re: [HACKERS] Variadic aggregates vs. project policy

2013/8/29 Tom Lane > Pavel Stehule writes: > > 2013/8/29 Tom Lane > >> So the question I'm now wondering about is whether this consideration > >> makes variadic aggregates a bad idea all around, even if we don't have > >> any built-in ones. Is the risk of user confusion (in the use of their >

Re: [HACKERS] Variadic aggregates vs. project policy

Pavel Stehule writes: > 2013/8/29 Tom Lane >> So the question I'm now wondering about is whether this consideration >> makes variadic aggregates a bad idea all around, even if we don't have >> any built-in ones. Is the risk of user confusion (in the use of their >> own aggregate) sufficient reas

Re: [HACKERS] Variadic aggregates vs. project policy

2013/8/29 Tom Lane > So I was hacking away at supporting variadic aggregates (per an internal > request at Salesforce), and had it pretty much working, when I came across > this old comment in opr_sanity.sql: > > -- Check that there are not aggregates with the same name and different > -- numbers

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/28 Robert Haas > On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule > wrote: > > what is magical? > > > > Stored procedures - we talk about this technology was a originally simple > > script moved from client side to server side. > > > > so if I write on client side > > > > BEGIN; > > SELEC

[HACKERS] Variadic aggregates vs. project policy

So I was hacking away at supporting variadic aggregates (per an internal request at Salesforce), and had it pretty much working, when I came across this old comment in opr_sanity.sql: -- Check that there are not aggregates with the same name and different -- numbers of arguments. While not techni

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/28 Hannu Krosing > On 08/28/2013 12:10 AM, Pavel Stehule wrote: > > > > > > so if I write on client side > > > > BEGIN; > > SELECT 1,2; > > SELECT 2; > > SELECT 3,4; > > END; > > > > then I expect results > > > > 1,2 > > 2 > > 3,4 > And you are perfectly ok to discard the results > A

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thu, Aug 29, 2013 at 1:42 PM, Stephen Frost wrote: > To be honest, I don't find the arguments of "pgAdmin does it badly" > nor "psql users want this ability" (which I find difficult to believe) > to be particularlly compelling reasons to have a dangerous > implementation (even if it's better th

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > The sorts of watered-down half-features being proposed here are not > going to do anything to address that situation. If there are > restrictions on what GUCs can be changed with this feature, or if the > feature is disabled by default, or if

Re: [HACKERS] [v9.4] row level security

On Thu, Aug 29, 2013 at 10:05:14AM -0400, Tom Lane wrote: > Alexander Korotkov writes: > > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote: > >> It is out of scope for this feature. We usually calls this type > >> of information leakage "covert channel"; that is not avoidable in > >> principl

Re: [HACKERS] [v9.4] row level security

Josh Berkus writes: >> That would close only one covert channel. Others were already pointed out >> upthread, and I'll bet there are more ... > Mind you, fundamentally this is no different from allowing INSERT > permission on a table but denying SELECT, or denying SELECT on certain > columns. I

Re: [HACKERS] [v9.4] row level security

>> I'm not sure what the solution would be, exactly. Deny permission for >> EXPLAIN on certain tables? > > That would close only one covert channel. Others were already pointed out > upthread, and I'll bet there are more ... Mind you, fundamentally this is no different from allowing INSERT per

Re: [HACKERS] [v9.4] row level security

Josh Berkus writes: > It's one thing to day "we can't solve this covert channel issue right > now in this patch", but saying "we don't plan to solve it at all" is > likely to doom the patch. > I'm not sure what the solution would be, exactly. Deny permission for > EXPLAIN on certain tables? Tha

Re: [HACKERS] [v9.4] row level security

* Kohei KaiGai (kai...@kaigai.gr.jp) wrote: > Although I didn't touch this task by myself, my senior colleague said that we > calculated some possible bandwidth of leakage as an evident when we ship > supercomputer system with MAC feature for customer who worry about security. > I'm not sure how to

Re: [HACKERS] [v9.4] row level security

Kaigai, > Although I didn't touch this task by myself, my senior colleague said that we > calculated some possible bandwidth of leakage as an evident when we ship > supercomputer system with MAC feature for customer who worry about security. > I'm not sure how to measure it. However, if we assume

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Wed, Aug 28, 2013 at 3:10 PM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Stephen Frost writes: >> > While I appreciate that there are bootstrap-type issues with this, I >> > really don't like this idea of "later stuff can just override earlier >> > stuff". >> >> > include

Re: [HACKERS] Master-slave visibility order

On Wed, Aug 28, 2013 at 10:58 AM, Ants Aasma wrote: > I currently see the following courses of action: > > 1. Do nothing about the inconsistency, use a transient global counter > for master commit order and commit record LSN for slaves. >Pro: doesn't change any semantics >Con: we are not m

Re: [HACKERS] pg_system_identifier()

On 8/26/13 8:48 AM, Fujii Masao wrote: I think it's also noteworthy that Slony and londiste both rely on the user >>specifying node identifiers. They don't try to be magic about it. I think >>there's 2 advantages there: >> >>- Code is simpler >>- Users can choose a naming schema that makes sense

Re: [HACKERS] Support for REINDEX CONCURRENTLY

On Wed, Aug 28, 2013 at 9:02 AM, Andres Freund wrote: >> During swap phase, process was waiting for transactions with older >> snapshots than the one taken by transaction doing the swap as they >> might hold the old index information. I think that we can get rid of >> it thanks to the MVCC snapsho

Re: [HACKERS] [v9.4] row level security

2013/8/29 k...@rice.edu : > On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote: >> 2013/8/29 Alexander Korotkov : >> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote: >> >> >> >> 2013/8/28 Oleg Bartunov : >> >> > btw, there is serious problem with row-level security and constraints.

Re: [HACKERS] [v9.4] row level security

On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote: > 2013/8/29 Alexander Korotkov : > > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote: > >> > >> 2013/8/28 Oleg Bartunov : > >> > btw, there is serious problem with row-level security and constraints. > >> > For > >> > example, user

Re: [HACKERS] [v9.4] row level security

2013/8/29 Alexander Korotkov : > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote: >> >> 2013/8/28 Oleg Bartunov : >> > btw, there is serious problem with row-level security and constraints. >> > For >> > example, user with low security level could use unique constraint to >> > know >> > about

Re: [HACKERS] [v9.4] row level security

Alexander Korotkov writes: > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote: >> It is out of scope for this feature. We usually calls this type of >> information leakage "covert channel"; that is not avoidable in principle. > I think there is another "covert channel" much more serious than

Re: [HACKERS] Properly initialize negative/empty cache entries in relfilenodemap

On 2013-08-29 21:35:13 +0900, MauMau wrote: > >Andres Freund wrote: > >>Hi, > >> > >>Thanks to the valgrind instrumentation I found a small oversight in the > >>relfilenodemap patch which is fixed in the attached patch. > Great! Could anybody find the root cause for the following memory leak > pr

Re: [HACKERS] Properly initialize negative/empty cache entries in relfilenodemap

Andres Freund wrote: Hi, Thanks to the valgrind instrumentation I found a small oversight in the relfilenodemap patch which is fixed in the attached patch. Great! Could anybody find the root cause for the following memory leak problem, and if possible, fix this? http://www.postgresql.org/m

Re: [HACKERS] [9.3 doc fix] clarification of Solaris versions

From: "Alvaro Herrera" Robert Haas escribió: Just because OpenSolaris is discontinued doesn't mean we don't support it. It looks like it has been unsupported for ~3 years at this point - not sure if that is long enough to remove the documentation reference. That part of the operating system

Re: [HACKERS] [v9.4] row level security

On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote: > 2013/8/28 Oleg Bartunov : > > btw, there is serious problem with row-level security and constraints. > For > > example, user with low security level could use unique constraint to know > > about existence of a row with higher security. I don

Re: Spinlock implementation on x86_64 (was Re: [HACKERS] Better LWLocks with compare-and-swap (9.4))

On 28.08.2013 20:21, Tom Lane wrote: Heikki Linnakangas writes: So, my plan is to apply the attached non-locked-tas-spin-x86_64.patch to master. But I would love to get feedback from people running different x86_64 hardware. Surely this patch should update the existing comment at line 209? O

Re: [HACKERS] [v9.4] row level security

Any constraints could be "covert channel". On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote: > 2013/8/28 Oleg Bartunov : > > btw, there is serious problem with row-level security and constraints. > For > > example, user with low security level could use unique constraint to know > > about ex

Re: [HACKERS] Extension Templates S03E11

Dimitri Fontaine writes: > Alvaro Herrera writes: >> "make check" in contrib/pg_upgrade should do the trick. > > PASSED > > Even after I added extension to the serial_schedule. I don't know if I > need to do anything specific on that area, will wait about some feedback > on that before sending a

Re: [HACKERS] error out when building pg_xlogdump with pgxs

Le jeudi 29 août 2013 11:52:36 Andres Freund a écrit : > On 2013-08-29 11:49:00 +0200, Cédric Villemain wrote: > > Le mercredi 28 août 2013 00:12:22 Andres Freund a écrit : > > > Hi Alvaro, > > > > > > On 2013-08-27 14:47:49 -0400, Alvaro Herrera wrote: > > > > Andres Freund wrote: > > > > > pg_xl

Re: [HACKERS] error out when building pg_xlogdump with pgxs

On 2013-08-29 11:49:00 +0200, Cédric Villemain wrote: > Le mercredi 28 août 2013 00:12:22 Andres Freund a écrit : > > Hi Alvaro, > > > > On 2013-08-27 14:47:49 -0400, Alvaro Herrera wrote: > > > Andres Freund wrote: > > > > pg_xlogdump cannot properly be built with pgxs since it needs a > > > > so

Re: [HACKERS] error out when building pg_xlogdump with pgxs

Le mercredi 28 août 2013 00:12:22 Andres Freund a écrit : > Hi Alvaro, > > On 2013-08-27 14:47:49 -0400, Alvaro Herrera wrote: > > Andres Freund wrote: > > > pg_xlogdump cannot properly be built with pgxs since it needs a > > > sourcetree around. That already has confused some users... > > > > >