Re: [HACKERS] Additional role attributes && superuser review

On 10/15/14, 12:22 AM, Stephen Frost wrote: BACKUP: pg_start_backup() pg_stop_backup() pg_switch_xlog() pg_create_restore_point() It seems odd to me that this (presumably) supports PITR but not pg_dump*. I realize that most folks probably don't use pg_dump for actual bac

Re: [HACKERS] CREATE POLICY and RETURNING

On 10/16/2014 01:44 PM, Craig Ringer wrote: > So the read-filtering policy should apply to all statements. Not just > SELECT. Oh, IIRC one wrinkle in the prior discussion about this was that doing this will prevent the implementation of policies that permit users to update/delete rows they cannot

Re: [HACKERS] Improve automatic analyze messages for inheritance trees

(2014/10/16 11:45), Simon Riggs wrote: On 6 October 2014 11:07, Etsuro Fujita wrote: I noticed that analyze messages shown by autovacuum don't discriminate between non-inherited cases and inherited cases, as shown in the below example: LOG: automatic analyze of table "postgres.public.pt" syst

Re: [HACKERS] [Segmentation fault] pg_dump binary-upgrade fail for type without element

PFA patch patch for the master branch. On Thu, Oct 16, 2014 at 11:09 AM, Rushabh Lathia wrote: > Hi All, > > pg_dump binary-upgrade fail with segmentation fault for type without > element. > > Consider the following testcase: > > rushabh@postgresql$ ./db/bin/psql postgres > psql (9.5devel) > Typ

Re: [HACKERS] CREATE POLICY and RETURNING

On 10/16/2014 12:25 PM, Fujii Masao wrote: > Hi, > > While I was checking the behavior of RLS, I found that the policy for SELECT > doesn't seem to be applied to RETURNING. Is this intentional? This is why I was opposed to having a "SELECT" policy at all. It should be "VISIBLE", "INSERT", "UPDAT

[HACKERS] [Segmentation fault] pg_dump binary-upgrade fail for type without element

Hi All, pg_dump binary-upgrade fail with segmentation fault for type without element. Consider the following testcase: rushabh@postgresql$ ./db/bin/psql postgres psql (9.5devel) Type "help" for help. postgres=# drop type typ; DROP TYPE postgres=# create type typ as (); CREATE TYPE postgres=# \q

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On Thu, Oct 16, 2014 at 8:08 AM, Simon Riggs wrote: > > > I've been trying to review this thread with the thought "what does > this give me?". I am keen to encourage contributions and also keen to > extend our feature set, but I do not wish to complicate our code base. > Dilip's developments do se

Re: [HACKERS] Locking for Rename To new_name works differently for different objects

On Wed, Oct 15, 2014 at 9:34 PM, Robert Haas wrote: > On Wed, Oct 15, 2014 at 10:04 AM, Tom Lane wrote: > > Amit Kapila writes: > >> I have observed that for renaming some of the objects > >> AccessExclusiveLock is taken on object whereas for > >> other kind of objects no lock is taken on object

[HACKERS] CREATE POLICY and RETURNING

Hi, While I was checking the behavior of RLS, I found that the policy for SELECT doesn't seem to be applied to RETURNING. Is this intentional? Please see the following example. CREATE ROLE foo LOGIN NOSUPERUSER; CREATE TABLE hoge AS SELECT col FROM generate_series(1,10) col; ALTER TABLE hoge ENAB

Re: [HACKERS] Directory/File Access Permissions for COPY and Generic File Access Functions

"Brightwell, Adam" writes: > The attached patch for review implements a directory permission system that > allows for providing a directory read/write capability to directories for > COPY TO/FROM and Generic File Access Functions to non-superusers. TBH, this sounds like it's adding a lot of mecha

[HACKERS] Directory/File Access Permissions for COPY and Generic File Access Functions

All, The attached patch for review implements a directory permission system that allows for providing a directory read/write capability to directories for COPY TO/FROM and Generic File Access Functions to non-superusers. This is not a complete solution as it does not currently contain documentati

Re: [HACKERS] Improve automatic analyze messages for inheritance trees

On 6 October 2014 11:07, Etsuro Fujita wrote: > I noticed that analyze messages shown by autovacuum don't discriminate > between non-inherited cases and inherited cases, as shown in the below > example: > > LOG: automatic analyze of table "postgres.public.pt" system usage: CPU > 0.00s/0.01u sec e

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 27 September 2014 03:55, Jeff Janes wrote: > On Fri, Sep 26, 2014 at 11:47 AM, Alvaro Herrera > wrote: >> >> Gavin Flower wrote: >> >> > Curious: would it be both feasible and useful to have multiple >> > workers process a 'large' table, without complicating things too >> > much? The could ea

Re: [HACKERS] Add shutdown_at_recovery_target option to recovery.conf

On 11 September 2014 16:02, Petr Jelinek wrote: >> What about adding something like action_at_recovery_target=pause|shutdown >> instead of increasing the number of parameters? >> > > That will also increase number of parameters as we can't remove the current > pause one if we want to be backwards

Re: [HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

On Fri, 2014-08-29 at 10:12 -0400, Tom Lane wrote: > What about removing the callback per se and just keeping the argument, > as it were. That is, a MemoryContext has a field of type "size_t *" > that is normally NULL, but if set to non-NULL, then we increment the > pointed-to value for pallocs an

Re: [HACKERS] Column Redaction

On Wed, Oct 15, 2014 at 8:59 PM, Simon Riggs wrote: > On 15 October 2014 21:03, Claudio Freire wrote: > >>> So you're familiar then with this process? So you know that an auditor >>> would trigger an investigation, resulting in deeper surveillance and >>> gathering of evidence that ends with vari

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > We lost this patch for the October commitfest, didn't we? > > > > I'm guessing you missed that a new version just got submitted..? > > Which one, reindex schema?

Re: [HACKERS] Column Redaction

On 15 October 2014 21:03, Claudio Freire wrote: >> So you're familiar then with this process? So you know that an auditor >> would trigger an investigation, resulting in deeper surveillance and >> gathering of evidence that ends with various remedial actions, such as >> court. How would that proc

Re: [HACKERS] replicating DROP commands across servers

Alvaro, On Wednesday, October 15, 2014, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > Andres Freund wrote: > > > > > Having reread the patch just now I basically see two things to > > > criticize: > > > a) why isn't this accessible at SQL level? That seems easy to address. > > > b) Arguably

Re: [HACKERS] replicating DROP commands across servers

Alvaro Herrera wrote: > Andres Freund wrote: > > > Having reread the patch just now I basically see two things to > > criticize: > > a) why isn't this accessible at SQL level? That seems easy to address. > > b) Arguably some of this could well be done in separate commits. > > Fair comments. I wi

Re: [HACKERS] jsonb generator functions

On 10/15/2014 05:47 PM, Alvaro Herrera wrote: Andrew Dunstan wrote: If we really want to change the name of json_object_two_arg, it would probably be best to change it NOW in 9.4 before it gets out into a production release at all. Doesn't it require initdb? If so, I think it's too late now.

Re: [HACKERS] jsonb generator functions

Andrew Dunstan wrote: > If we really want to change the name of json_object_two_arg, it > would probably be best to change it NOW in 9.4 before it gets out > into a production release at all. Doesn't it require initdb? If so, I think it's too late now. -- Álvaro Herrerahttp://w

Re: [HACKERS] Maximum number of WAL files in the pg_xlog directory

On 10/15/2014 02:17 PM, Guillaume Lelarge wrote: >> > If we don't count the WAL files, though, that eliminates the best way to >> > detecting when archiving is failing. >> > >> > > WAL files don't give you this directly. You may think it's an issue to get > a lot of WAL files, but it can just be a

Re: [HACKERS] Maximum number of WAL files in the pg_xlog directory

2014-10-15 23:12 GMT+02:00 Josh Berkus : > On 10/15/2014 01:25 PM, Guillaume Lelarge wrote: > > Monitoring is another matter, and I don't really think a monitoring > > solution should count the WAL files. What actually really matters is the > > database availability, and that is covered with havin

Re: [HACKERS] Maximum number of WAL files in the pg_xlog directory

On 10/15/2014 01:25 PM, Guillaume Lelarge wrote: > Monitoring is another matter, and I don't really think a monitoring > solution should count the WAL files. What actually really matters is the > database availability, and that is covered with having enough disk space in > the WALs partition. If w

Re: [HACKERS] jsonb generator functions

On 10/15/2014 03:54 PM, I wrote: On 10/15/2014 07:38 AM, Pavel Stehule wrote: I checked a code, and I have only two small objection - a name "jsonb_object_two_arg" is not good - maybe "json_object_keys_values" ? It's consistent with the existing json_object_two_arg. In all cases I think

Re: [HACKERS] Maximum number of WAL files in the pg_xlog directory

2014-10-15 22:11 GMT+02:00 Jeff Janes : > On Fri, Aug 8, 2014 at 12:08 AM, Guillaume Lelarge > wrote: > >> Hi, >> >> As part of our monitoring work for our customers, we stumbled upon an >> issue with our customers' servers who have a wal_keep_segments setting >> higher than 0. >> >> We have a mo

Re: [HACKERS] WIP: dynahash replacement for buffer table

On 2014-10-15 13:41:25 -0400, Robert Haas wrote: > On Wed, Oct 15, 2014 at 2:03 AM, Andres Freund wrote: > > The solution I'm thinking of is to essentially move away from hazard > > pointers and store something like a generation counter per > > backend. Which is updated less often, and in combinat

Re: [HACKERS] Maximum number of WAL files in the pg_xlog directory

On Fri, Aug 8, 2014 at 12:08 AM, Guillaume Lelarge wrote: > Hi, > > As part of our monitoring work for our customers, we stumbled upon an > issue with our customers' servers who have a wal_keep_segments setting > higher than 0. > > We have a monitoring script that checks the number of WAL files i

Re: [HACKERS] Column Redaction

On Wed, Oct 15, 2014 at 4:59 PM, Simon Riggs wrote: > On 15 October 2014 20:41, Claudio Freire wrote: >> On Sat, Oct 11, 2014 at 4:40 AM, Simon Riggs wrote: >>> On 10 October 2014 16:45, Rod Taylor wrote: >>> Redaction prevents accidental information loss only, forcing any loss >>> that occurs

Re: [HACKERS] Column Redaction

On 15 October 2014 20:41, Claudio Freire wrote: > On Sat, Oct 11, 2014 at 4:40 AM, Simon Riggs wrote: >> On 10 October 2014 16:45, Rod Taylor wrote: >> Redaction prevents accidental information loss only, forcing any loss >> that occurs to be explicit. It ensures that loss of information can be

Re: [HACKERS] jsonb generator functions

On 10/15/2014 07:38 AM, Pavel Stehule wrote: 2014-10-13 17:22 GMT+02:00 Andrew Dunstan >: On 10/13/2014 09:37 AM, Andrew Dunstan wrote: On 09/26/2014 04:54 PM, Andrew Dunstan wrote: Here is a patch for the generator and aggregate funct

Re: [HACKERS] replicating DROP commands across servers

Andres Freund wrote: > Having reread the patch just now I basically see two things to > criticize: > a) why isn't this accessible at SQL level? That seems easy to address. > b) Arguably some of this could well be done in separate commits. Fair comments. I will split it up. FWIW, I spent some ti

Re: [HACKERS] replicating DROP commands across servers

On 2014-10-04 21:12:24 -0400, Robert Haas wrote: > On Fri, Oct 3, 2014 at 4:58 PM, Alvaro Herrera > wrote: > > Robert Haas wrote: > >> I'm not really very convinced that it's a good idea to expose this > >> instead of just figuring out a way to parse the object identity. > > > > That's the first

Re: [HACKERS] Column Redaction

On Sat, Oct 11, 2014 at 4:40 AM, Simon Riggs wrote: > On 10 October 2014 16:45, Rod Taylor wrote: > Redaction prevents accidental information loss only, forcing any loss > that occurs to be explicit. It ensures that loss of information can be > tied clearly back to an individual, like an ink pack

Re: [HACKERS] Proposal for better support of time-varying timezone abbreviations

... and here is a draft patch for the timezone abbreviation data files. I changed all the abbreviations for which the parent zone had used more than one GMT offset since 1970. That seemed like a good cutoff to avoid wasting cycles on ancient history, especially since the IANA people themselves do

Re: [HACKERS] Column Redaction

On 15 October 2014 19:46, Robert Haas wrote: >> In IT terms, we're looking at controlling and reducing improper access >> to data by an otherwise Trusted person. The only problem is that some >> actions on data items are allowed, others are not. > > Sure, I don't disagree with any of that as a ge

Re: [HACKERS] group locking: incomplete patch, just for discussion

On 15 October 2014 17:03, Robert Haas wrote: > Well, I'm fervently in agreement with you on one point: the first > version of all this needs to be as simple as possible, or the time to > get to the first version will be longer than we can afford to wait. I > think what we're discussing here is w

Re: [HACKERS] Column Redaction

On Wed, Oct 15, 2014 at 4:04 AM, Simon Riggs wrote: > On 14 October 2014 17:43, Robert Haas wrote: >> On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs wrote: >>> As soon as you issue the above query, you have clearly indicated your >>> intention to steal. Receiving information is no longer accidenta

Re: [HACKERS] Buffer Requests Trace

On Wed, Oct 15, 2014 at 6:22 AM, Lucas Lersch wrote: > So is it a possible normal behavior that running tpcc for 10min only > access 50% of the database? Furthermore, is there a guideline of parameters > for tpcc (# of warehouses, execution time, operations weight)? > > I'm not familiar with your

Re: [HACKERS] WIP: dynahash replacement for buffer table

On Wed, Oct 15, 2014 at 2:03 AM, Andres Freund wrote: > On 2014-10-14 17:53:10 -0400, Robert Haas wrote: >> On Tue, Oct 14, 2014 at 4:42 PM, Andres Freund >> wrote: >> >> The code in CHashSearch shows the problem there: you need to STORE the >> >> hazard pointer before you begin to do the LOAD o

Re: [HACKERS] WIP: dynahash replacement for buffer table

On 15/10/2014 10:32 AM, Ants Aasma wrote: On Tue, Oct 14, 2014 at 6:19 PM, Robert Haas wrote: With regard for using a hash table for the buffer mapping lock I'm doubtful that any form of separate chaining is the right one. We currently have a quite noticeable problem with the number of cache mi

Re: [HACKERS] WIP: dynahash replacement for buffer table

On Tue, Oct 14, 2014 at 6:19 PM, Robert Haas wrote: >> With regard for using a hash table for the buffer mapping lock I'm >> doubtful that any form of separate chaining is the right one. We >> currently have a quite noticeable problem with the number of cache >> misses in the buffer mapping hash (

Re: [HACKERS] Maximum number of WAL files in the pg_xlog directory

On Fri, Aug 8, 2014 at 4:08 PM, Guillaume Lelarge wrote: > Hi, > > As part of our monitoring work for our customers, we stumbled upon an issue > with our customers' servers who have a wal_keep_segments setting higher than > 0. > > We have a monitoring script that checks the number of WAL files in

Re: [HACKERS] Locking for Rename To new_name works differently for different objects

On Wed, Oct 15, 2014 at 10:04 AM, Tom Lane wrote: > Amit Kapila writes: >> I have observed that for renaming some of the objects >> AccessExclusiveLock is taken on object whereas for >> other kind of objects no lock is taken on object before >> renaming the object. > > The usual theory for DDL up

Re: [HACKERS] group locking: incomplete patch, just for discussion

On Wed, Oct 15, 2014 at 10:12 AM, Simon Riggs wrote: > On 15 October 2014 14:46, Robert Haas wrote: >>> When my family goes to a restaurant, any member of the party may ask >>> for a table and the request is granted for the whole family. But the >>> lock is released only when I pay the bill. Once

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > We lost this patch for the October commitfest, didn't we? > > I'm guessing you missed that a new version just got submitted..? Which one, reindex schema? Isn't that a completely different patch? > I'd be fine with tod

Re: [HACKERS] Buffer Requests Trace

I got the following numbers from my tpcc database: Data size: ~6059MB Index size: ~1390MB Total size: ~7400MB Even considering index-only scans, the ratio of around 50% of the database pages being accessed seems unrealistic to me. On Wed, Oct 15, 2014 at 3:50 PM, Stephen Frost wrote: > * Luc

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > We lost this patch for the October commitfest, didn't we? I'm guessing you missed that a new version just got submitted..? I'd be fine with today's being added to the october commitfest.. Of course, there's a whole independent discussion to be

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

Stephen Frost wrote: > > >> Yes, I will update the patch. > > > > > > Still planning to do this..? > > > > > > Marking this back to waiting-for-author. > > > > Yes, but probably not for this commitfest unfortunately. > > Fair enough, I'll mark it 'returned with feedback'. We lost this patch f

Re: [HACKERS] Proposal : REINDEX SCHEMA

On Mon, Oct 13, 2014 at 11:16 PM, Robert Haas wrote: > On Sun, Oct 12, 2014 at 1:27 PM, Stephen Frost wrote: >> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >>> Sawada Masahiko wrote: >>> > Attached WIP patch adds new syntax REINEX SCHEMA which does reindexing >>> > all table of specified s

Re: [HACKERS] group locking: incomplete patch, just for discussion

On 15 October 2014 14:46, Robert Haas wrote: >> When my family goes to a restaurant, any member of the party may ask >> for a table and the request is granted for the whole family. But the >> lock is released only when I pay the bill. Once we have the table, any >> stragglers know we have locked

Re: [HACKERS] Locking for Rename To new_name works differently for different objects

Amit Kapila writes: > I have observed that for renaming some of the objects > AccessExclusiveLock is taken on object whereas for > other kind of objects no lock is taken on object before > renaming the object. The usual theory for DDL updates of all types (not just rename) is that an explicit loc

Re: [HACKERS] How to make ResourceOwnerForgetBuffer() O(1), instead of O(N^2) scale

> > On 10/03/2014 07:08 AM, Kouhei Kaigai wrote: > > > Hello, > > > > > > I recently got a trouble on development of my extension that > > > utilizes the shared buffer when it released each buffer page. > > > > > > This extension transfers contents of the shared buffers to GPU > > > device using DM

Re: [HACKERS] Proposal for better support of time-varying timezone abbreviations

Michael Meskes writes: > On 15.10.2014 00:26, Tom Lane wrote: >> * I've not touched ecpg except for cosmetic changes to keep the struct >> definitions in sync, and to fix the previously-mentioned bogus free() >> attempt. I doubt that it would be worth teaching ecpg how to access the >> zic timezo

Re: [HACKERS] Buffer Requests Trace

* Lucas Lersch (lucasler...@gmail.com) wrote: > So is it a possible normal behavior that running tpcc for 10min only access > 50% of the database? Furthermore, is there a guideline of parameters for > tpcc (# of warehouses, execution time, operations weight)? Depends- you may be aware that we supp

Re: [HACKERS] group locking: incomplete patch, just for discussion

On Wed, Oct 15, 2014 at 4:18 AM, Simon Riggs wrote: > On 15 October 2014 05:13, Tom Lane wrote: >> Robert Haas writes: >>> For parallelism, I think we need a concept of group locking. That is, >>> suppose we have a user backend and N worker backends collaborating to >>> execute some query. For

Re: [HACKERS] narwhal and PGDLLIMPORT

On 10/15/2014 01:53 AM, Craig Ringer wrote: On 10/15/2014 12:53 PM, Noah Misch wrote: Windows Server 2003 isn't even EOL yet. I'd welcome a buildfarm member with that OS and a modern toolchain. It's possible to run multiple buildfarm animals on a single Windows instance, each with a different

Re: [HACKERS] Buffer Requests Trace

So is it a possible normal behavior that running tpcc for 10min only access 50% of the database? Furthermore, is there a guideline of parameters for tpcc (# of warehouses, execution time, operations weight)? On Wed, Oct 15, 2014 at 3:09 PM, Simon Riggs wrote: > On 15 October 2014 13:44, Lucas Le

Re: [HACKERS] Buffer Requests Trace

On 15 October 2014 13:44, Lucas Lersch wrote: > I am recording the BufferDesc.tag.blockNum for the buffer along with the > spcNode, dbNode, relNode, also present in the tag. The TPC-C I/O is random, so if you run it for longer you should see a wider set. Cacheing isn't possible as a way to impr

Re: [HACKERS] Buffer Requests Trace

I am recording the BufferDesc.tag.blockNum for the buffer along with the spcNode, dbNode, relNode, also present in the tag. On Wed, Oct 15, 2014 at 2:27 PM, Simon Riggs wrote: > On 15 October 2014 12:49, Lucas Lersch wrote: > > Sorry for taking so long to answer. I am sending attached the patch

Re: [HACKERS] Proposal for better support of time-varying timezone abbreviations

On 15.10.2014 00:26, Tom Lane wrote: > * I've not touched ecpg except for cosmetic changes to keep the struct > definitions in sync, and to fix the previously-mentioned bogus free() > attempt. I doubt that it would be worth teaching ecpg how to access the > zic timezone database --- the problem of

Re: [HACKERS] Buffer Requests Trace

On 15 October 2014 12:49, Lucas Lersch wrote: > Sorry for taking so long to answer. I am sending attached the patch with the > changes I did to pgsql code. I followed the steps for compiling and > installing pgsql from: > http://www.postgresql.org/docs/current/static/install-short.html Are you re

[HACKERS] WIP: Access method extendability

Hackers, Postgres was initially designed to support access methods extendability. This extendability lives to present day. However, this is mostly internal in-core extendability. One can quite easily add new access method into PostgreSQL core. But if one try to implement access method as external

Re: [HACKERS] [9.4 bug] The database server hangs with write-heavy workload on Windows

From: "MauMau" Thank you very much. I didn't anticipate such a difficult complicated cause. The user agreed to try the patch tonight. I'll report back the result as soon as I got it from him. The test ran successfully without hang for 24 hours. It was run with your patch + the following:

Re: [HACKERS] Buffer Requests Trace

Sorry for taking so long to answer. I am sending attached the patch with the changes I did to pgsql code. I followed the steps for compiling and installing pgsql from: http://www.postgresql.org/docs/current/static/install-short.html In summary, the page_id of the page being released in ReleaseBuff

Re: [HACKERS] jsonb generator functions

2014-10-13 17:22 GMT+02:00 Andrew Dunstan : > > On 10/13/2014 09:37 AM, Andrew Dunstan wrote: > >> >> On 09/26/2014 04:54 PM, Andrew Dunstan wrote: >> >>> >>> Here is a patch for the generator and aggregate functions for jsonb that >>> we didn't manage to get done in time for 9.4. They are all equ

[HACKERS] Locking for Rename To new_name works differently for different objects

I have observed that for renaming some of the objects AccessExclusiveLock is taken on object whereas for other kind of objects no lock is taken on object before renaming the object. The object's that are renamed via AlterObjectRename_internal() takes the lock (during get_object_address() call) whe

Re: [HACKERS] Patch to support SEMI and ANTI join removal

On Thu, Oct 9, 2014 at 12:40 AM, Andres Freund wrote: > On 2014-10-09 00:21:44 +1300, David Rowley wrote: > > Ok, so I've been hacking away at this for a couple of evenings and I > think > > I have a working prototype finally! > > Cool! > > Patch attached. > > So it seems it's not quite as effi

Re: [HACKERS] proposal: plpgsql - Assert statement

2014-09-30 10:04 GMT+07:00 Jim Nasby : > On 9/17/14, 7:40 PM, Jan Wieck wrote: > >> Exactly. Doing something like >> >> ASSERT (select count(*) from foo >> where fk not in (select pk from bar)) = 0; >> >> is a perfectly fine, arbitrary boolean expression. It will probably work >> wel

Re: [HACKERS] Support UPDATE table SET(*)=...

On Wed, Oct 15, 2014 at 2:18 PM, Atri Sharma wrote: > > On Wednesday, October 15, 2014, Marti Raudsepp wrote: > >> Hi >> >> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma >> wrote: >> > Please find attached a patch which implements support for UPDATE table1 >> > SET(*)=... >> >> I presume you

Re: [HACKERS] Support UPDATE table SET(*)=...

On Wednesday, October 15, 2014, Marti Raudsepp wrote: > Hi > > On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma > wrote: > > Please find attached a patch which implements support for UPDATE table1 > > SET(*)=... > > I presume you haven't read Tom Lane's proposal and discussion about > multiple colu

Re: [HACKERS] Support UPDATE table SET(*)=...

Hi On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma wrote: > Please find attached a patch which implements support for UPDATE table1 > SET(*)=... I presume you haven't read Tom Lane's proposal and discussion about multiple column assignment in UPDATE: http://www.postgresql.org/message-id/1783.13990

Re: [HACKERS] group locking: incomplete patch, just for discussion

On 15 October 2014 05:13, Tom Lane wrote: > Robert Haas writes: >> For parallelism, I think we need a concept of group locking. That is, >> suppose we have a user backend and N worker backends collaborating to >> execute some query. For the sake of argument, let's say it's a >> parallel CLUSTER

Re: [HACKERS] Column Redaction

On 14 October 2014 17:43, Robert Haas wrote: > On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs wrote: >> As soon as you issue the above query, you have clearly indicated your >> intention to steal. Receiving information is no longer accidental, it >> is an explicit act that is logged in the auditing

[HACKERS] Support UPDATE table SET(*)=...

Hi All, Please find attached a patch which implements support for UPDATE table1 SET(*)=... The patch supports both UPDATE table SET(*)=(a,b,c) and UPDATE table1 SET(*)=(SELECT a,b,c FROM...). It solves the problem of doing UPDATE from a record variable of the same type as the table e.g. update foo

Re: [HACKERS] Buffer Requests Trace

On 14 October 2014 17:08, Lucas Lersch wrote: > Unfortunately, in the generated trace with over 2 million buffer requests, > only ~14k different pages are being accessed, out of the 800k of the whole > database. Am I missing something here? We can't tell what you're doing just by knowing the num

Re: [HACKERS] Scaling shared buffer eviction

On Tue, Oct 14, 2014 at 3:32 PM, Andres Freund wrote: > On 2014-10-14 15:24:57 +0530, Amit Kapila wrote: > > After that I observed that contention for LW_SHARED has reduced > > for this load, but it didn't help much in terms of performance, so I again > > rechecked the profile and this time most o