Re: [HACKERS] ALTER SYSTEM RESET?

On 06/27/2014 08:49 AM, Vik Fearing wrote: > This third patch reformats the documentation in the way I expected it to > be committed. Amit, I added this to the next commitfest with your name as reviewer. https://commitfest.postgresql.org/action/patch_view?id=1495 Please update the status as you

Re: [Fwd: Re: [HACKERS] proposal: new long psql parameter --on-error-stop]

Hello thank you Peter, so now only setting for MS Windows is missing? Regards Pavel 2014-06-26 21:57 GMT+02:00 Petr Jelinek : > Hello, > > I went through the patch, seems mostly fine, I adjusted some wording, > removed the default .pgpass file info since it's not accurate, and replaced > coup

Re: [HACKERS] ALTER SYSTEM RESET?

On 06/27/2014 06:22 AM, Amit Kapila wrote: > On Thu, Jun 26, 2014 at 8:17 PM, Vik Fearing > wrote: >> On 06/26/2014 05:07 AM, Amit Kapila wrote: >> > I think it will make sense if we support RESET ALL as well similar >> > to Alter Database .. RESET ALL syntax. Do yo

Re: [HACKERS] review: Built-in binning functions

Hello I recheck this patch 1. applied cleanly and compilation was without warnings and errors 2. all tests was passed ok 3. documentation was rebuild without issues 4. I don't see any issue in code quality - it is well commented, well formatted, with regress tests It is ready for commit Regards

Re: [HACKERS] WAL format and API changes (9.5)

On Sun, Jun 15, 2014 at 6:11 AM, Heikki Linnakangas wrote: > On 06/14/2014 09:43 PM, Alvaro Herrera wrote: > >> Heikki Linnakangas wrote: >> >> Here's a new version, rebased against master. No other changes. >>> >> >> This is missing xlogrecord.h ... >> > > Oops, here you are. > Looking at this

Re: [HACKERS] Index-only scans and non-MVCC snapshots

On 26/06/2014 11:04 PM, Alvaro Herrera wrote: Ryan Johnson wrote: As part of a research project, I'm trying to change Read Committed isolation to use HeapTupleSatisfiesNow rather than acquiring a new snapshot at every command [1]. Are you aware of this? commit 813fb0315587d32e3b77af1051a0ef517

Re: [HACKERS] Index-only scans and non-MVCC snapshots

Ryan Johnson wrote: > As part of a research project, I'm trying to change Read Committed > isolation to use HeapTupleSatisfiesNow rather than acquiring a new > snapshot at every command [1]. Are you aware of this? commit 813fb0315587d32e3b77af1051a0ef517d187763 Author: Robert Haas Date: Thu A

[HACKERS] Index-only scans and non-MVCC snapshots

Hi, As part of a research project, I'm trying to change Read Committed isolation to use HeapTupleSatisfiesNow rather than acquiring a new snapshot at every command [1]. Things appear to have gone reasonably well so far, except certain queries fail with "ERROR: non-MVCC snapshots are not supp

Re: [HACKERS] ALTER SYSTEM RESET?

On Thu, Jun 26, 2014 at 8:17 PM, Vik Fearing wrote: > On 06/26/2014 05:07 AM, Amit Kapila wrote: > > I think it will make sense if we support RESET ALL as well similar > > to Alter Database .. RESET ALL syntax. Do you see any reason > > why we shouldn't support RESET ALL syntax for Alter System?

Re: [HACKERS] postgresql.auto.conf and reload

On Thu, Jun 26, 2014 at 1:49 PM, Christoph Berg wrote: > > Re: Amit Kapila 2014-06-26 > > On Wed, Jun 25, 2014 at 7:52 PM, Christoph Berg wrote: > > > Re: Amit Kapila 2014-06-25 < > > caa4ek1+f9ztogvvw-wyj2+vt0k8_jxtziqhp8ivb7wdo1w1...@mail.gmail.com> > > > > > > > I think maintaining values bot

Re: [HACKERS] pg_resetxlog to clear backup start/end locations.

Hello, I have finished the patches for all of 9.x. > I dont' touch what '-n' option shows and rewrite documents for > the option a bit. And '-n' won't show the changes of backup > location. -8.4: does not have backup locations in ControlFileData. 9.0-9.1: resetxlog_backuploc_9_0-9.1.patch: Add c

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

* Tom Lane (t...@sss.pgh.pa.us) wrote: > > Why wouldn't it go back all the way to 9.0? (assuming 8.4 is dead) > > People get unhappy when minor releases de-optimize queries that had > been working for them. It's not too late to change the behavior of > 9.4, but I'm hesitant to do it in already-r

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

Vik Fearing writes: > On 06/27/2014 02:49 AM, Tom Lane wrote: >> In exactly the same way, it isn't safe to push down quals into >> subqueries that use DISTINCT unless the quals are non-volatile. This >> consideration is missed by the current code, and I think that's a bug. >> Given the lack of p

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

On 06/27/2014 02:49 AM, Tom Lane wrote: > Vik Fearing writes: >> This latest patch is ready for a committer to look at now. The weird >> comments have been changed, superfluous regression tests removed, and >> nothing done about expression pushdown per (brief) discussion. > > I started to look a

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 27/06/14 09:09, Tom Dunstan wrote: On 27 June 2014 06:14, Gavin Flower mailto:gavinflo...@archidevsys.co.nz>> wrote: On 27/06/14 00:12, Rushabh Lathia wrote: INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK') returning primary key, dname; I think allowing other colu

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

Vik Fearing writes: > This latest patch is ready for a committer to look at now. The weird > comments have been changed, superfluous regression tests removed, and > nothing done about expression pushdown per (brief) discussion. I started to look at this patch and realized that there's an issue t

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 27 June 2014 06:14, Gavin Flower wrote: > On 27/06/14 00:12, Rushabh Lathia wrote: > >> INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK') returning primary >> key, dname; >> >> I think allowing other columns with PRIMARY KEY would be more useful >> syntax. >> Even in later versions if we wa

Re: [HACKERS] Extending MSVC scripts to support --with-extra-version

On Fri, Jun 27, 2014 at 8:26 AM, Asif Naeem wrote: > I have spent some time reviewing the code. It applies well and PG master > branch build fine with setting extraver or keep it undefined. > Thanks for reviewing that. > I have observed the following output applying the patch i.e. > It seems th

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

On 06/24/2014 03:20 AM, Jeff Janes wrote: I've tried your 0001 patch, reflecting this refactoring, on Linux and it caused 'make check' to hang at 'starting postmaster'. I found the bug in the code, and I have attached the a patch which you can apply on top of the patch. The regression tests pa

Re: [HACKERS] Extending MSVC scripts to support --with-extra-version

Hi, I have spent some time reviewing the code. It applies well and PG master branch build fine with setting extraver or keep it undefined. I have observed the following output applying the patch i.e. *Keeping extraver undefined* : C:\PG\postgresql\inst_withpatch_no_extra-version>bin\psql.exe -d

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-06-26 15:40:11 -0700, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-26 14:13:07 -0700, Tom Lane wrote: > >> Surely it had better be a read barrier as well? > > > I don't immediately see why it has to be read barrier? Hoisting a load > > from after the release into the locked area

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

On 06/21/2014 02:03 PM, David Rowley wrote: > I'm marking this Waiting on Author pending discussion on pushing down > entire expressions, but on the whole I think this is pretty much ready. > > > As I said above, I don't think playing around with that code is really > work for this patch.

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 26/06/14 19:57, Sawada Masahiko wrote: $ pg_resetxlog -s0 data Transaction log reset $ pg_controldata data | grep "Database system identifier" Database system identifier: 6029284919152642525 this patch dose not works fine with -s0. Yes, this is a bug, 0 input should throw error,

Re: [HACKERS] Spinlocks and compiler/memory barriers

Hi, On 2014-06-26 23:01:10 +0200, Andres Freund wrote: > I think we should rework things so that we fall back to > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what > we have right now. > That'd require to make barrier.h independent from s_lock.h, but I think > that'd be a p

Re: [HACKERS] Spinlocks and compiler/memory barriers

Andres Freund writes: > On 2014-06-26 14:13:07 -0700, Tom Lane wrote: >> Surely it had better be a read barrier as well? > I don't immediately see why it has to be read barrier? Hoisting a load > from after the release into the locked area of code should be safe? No doubt, but delaying a read ti

Re: [HACKERS] Cluster name in ps output

On 25 June 2014 08:13, Fujii Masao wrote: > On Wed, Jun 25, 2014 at 1:29 PM, Abhijit Menon-Sen > wrote: >> The patch looks OK, and works as advertised (I tested on Linux). If we >> want the feature (I like it), this patch is a good enough way to get it. > > I got the following compiler warning.

Re: [HACKERS] What's the point of json_extract_path_op etc?

Andrew Dunstan writes: > On 06/26/2014 03:11 PM, Tom Lane wrote: >> Do we actually want to document these things as both operators and >> functions? If we do, then the right answer is to list them as known >> exceptions in the opr_sanity test, not to hide the fact that we're >> violating the gene

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

On 26.6.2014 20:43, Tomas Vondra wrote: > Attached is v2 of the patch, with some cleanups / minor improvements: > > * there's a single FIXME, related to counting tuples in the Meh, I couldn't resist resolving this FIXME, so attached is v3 of the patch. This just adds a proper 'batch tuples' count

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-06-26 14:13:07 -0700, Tom Lane wrote: > Andres Freund writes: > > I think we should rework things so that we fall back to > > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what > > we have right now. > > Surely it had better be a read barrier as well? I don't immedi

Re: [HACKERS] What's the point of json_extract_path_op etc?

On 06/26/2014 03:11 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/25/2014 02:46 PM, Tom Lane wrote: Why do we have essentially duplicate pg_proc entries for json_extract_path and json_extract_path_op? Likewise for json_extract_path_text_op, jsonb_extract_path_op, and jsonb_extract_path_tex

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

On Thu, Jun 26, 2014 at 2:35 AM, Dilip kumar wrote: > > Thank you for giving your time, Please review the updated patch attached in > the mail. > > > > 1. Rebased the patch > > 2. Implemented parallel execution for new option --analyze-in-stages Hi Dilip, Thanks for rebasing. I have

Re: [HACKERS] Spinlocks and compiler/memory barriers

Andres Freund writes: > I think we should rework things so that we fall back to > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what > we have right now. Surely it had better be a read barrier as well? And S_LOCK the same? regards, tom lane -- Se

[HACKERS] Spinlocks and compiler/memory barriers

Hi, I just spent 20+ hours debugging a elusive problem which only happened under heavy concurrency. Slight changes to the code made it disappear. In the end it turned out that gcc liked to move *one* instruction across the SpinLockRelease() - and only sometimes. Unrelated changes made the vanish.

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 27/06/14 00:12, Rushabh Lathia wrote: Thanks for sharing latest patch. For me this syntax is limiting the current returning clause implementation. Because its not allowing the returning PRIMARY KEYS with other columns, and if user or application require that they need to do RETURNING *. Fo

Re: [HACKERS] review: Built-in binning functions

Here is v2, with fixed documentation and numeric version of the implementation. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index f475458..38330d4 100644 ---

Re: [Fwd: Re: [HACKERS] proposal: new long psql parameter --on-error-stop]

Hello, I went through the patch, seems mostly fine, I adjusted some wording, removed the default .pgpass file info since it's not accurate, and replaced couple of phrases with (hopefully) more informative ones. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Develop

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

On Wed, Jun 11, 2014 at 1:19 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > Hi all, > > As part of GSoC2014 I'm sending a patch to add the capability of change an > unlogged table to logged [1]. > > Hi all, As part of GSoC2014 and with agreement of my mentor and reviewer (Stephen

Re: [HACKERS] better atomics - v0.5

On Thu, Jun 26, 2014 at 1:47 PM, Tom Lane wrote: > Robert Haas writes: > Would it be practical to say that the coding rule is that you can only > use atomic ops on fields that are protected by the spinlock, ie, nobody > else is supposed to be touching those fields while you have the spinlock? > I

Re: [HACKERS] What's the point of json_extract_path_op etc?

Andrew Dunstan writes: > On 06/25/2014 02:46 PM, Tom Lane wrote: >> Why do we have essentially duplicate pg_proc entries for json_extract_path >> and json_extract_path_op? >> Likewise for json_extract_path_text_op, jsonb_extract_path_op, and >> jsonb_extract_path_text_op. > ISTR trying that and r

Re: [HACKERS] better atomics - v0.5

On 2014-06-26 11:47:15 -0700, Tom Lane wrote: > Robert Haas writes: > > On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund > > wrote: > >> On 2014-06-25 20:16:08 -0400, Robert Haas wrote: > >>> I think that's going to fall afoul of Tom's previously-articulated "no > >>> loops inside spinlocks" rule.

Re: [HACKERS] better atomics - v0.5

Robert Haas writes: > On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund wrote: >> On 2014-06-25 20:16:08 -0400, Robert Haas wrote: >>> I think that's going to fall afoul of Tom's previously-articulated "no >>> loops inside spinlocks" rule. Most atomics, by nature, are >>> loop-until-it-works. >> W

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

Attached is v2 of the patch, with some cleanups / minor improvements: * improved comments, whitespace fixed / TODOs etc. * tracking inital # of buckets (similar to initial # of batches) * adding info about buckets to EXPLAIN ANALYZE, similar to batches - I didn't want to make it overly complex,

Re: [HACKERS] better atomics - v0.5

On Thu, Jun 26, 2014 at 7:21 AM, Andres Freund wrote: > On 2014-06-25 20:22:31 -0400, Robert Haas wrote: >> On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas >> wrote: >> > I think having a separate file for each architecture is nice. I totally >> > agree that they don't belong in src/include/s

Re: [HACKERS] better atomics - v0.5

On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund wrote: > On 2014-06-25 20:16:08 -0400, Robert Haas wrote: >> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund >> wrote: >> > Since it better be legal to manipulate a atomic variable while holding a >> > spinlock we cannot simply use an arbitrary spinl

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

* Simon Riggs (si...@2ndquadrant.com) wrote: > On 26 June 2014 14:59, Stephen Frost wrote: > > I think this will paint us into a corner such that we won't be able to > > add the capabilities which the users who are most concerned about > > auditing require. > > I'm sorry, but this seems exactly t

Re: [HACKERS] Allowing NOT IN to use ANTI joins

David Rowley writes: > If there's no way to tell that the target entry comes from a left join, > then would it be a bit too quirky to just do the NOT NULL checking when > list_length(query->rtable) == 1 ? or maybe even loop over query->rtable and > abort if we find an outer join type? it seems a b

Re: [HACKERS] Set new system identifier using pg_resetxlog

Thank you for updating the patch. I think that the following behaviour of pg_resetxlog is bug. $ pg_controldata data | grep "Database system identifier" Database system identifier: 6029284919152642525 -- $ pg_resetxlog -s0 -n data Current pg_control values: pg_control version number:

Re: [HACKERS] Changes in amcanreturn() interface to support multicolumn indexes

Anastasia Lubennikova writes: > There is a question of support multicolumn index only scans for GIST. > gistcanreturn() can return true if fetch is implemented for all indexed > columns and false otherwise. > But that's not very good case for multicolumn indexes. > I think, it requires extend the

Re: [HACKERS] SQL access to database attributes

On 06/23/2014 06:45 PM, Pavel Stehule wrote: > > > > 2014-06-23 18:39 GMT+02:00 Vik Fearing >: > > On 06/23/2014 06:21 PM, Robert Haas wrote: > > On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule > mailto:pavel.steh...@gmail.com>> wrote: > >> I found

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 26 June 2014 14:59, Stephen Frost wrote: > I think this will paint us into a corner such that we won't be able to > add the capabilities which the users who are most concerned about > auditing require. I'm sorry, but this seems exactly the wrong way around to me. The point here is that we ha

Re: [HACKERS] RLS Design

On Wed, Jun 25, 2014 at 4:48 PM, Dean Rasheed wrote: >> Instead of doing it this way, we could instead do: >> >> ALTER ROLE role1 ADD POLICY p1; >> ALTER ROLE role2 ADD POLICY p2; >> >> We could possibly allow multiple policies to be set for the same user, >> but given an error (or OR the quals to

Re: [HACKERS] NUMA packaging and patch

Claudio Freire wrote: > Sadly, it excludes the OS cache explicitly (when it mentions libc.so), > which is one of the hottest sources of memory bandwidth consumption in > a database. Agreed.  On the bright side, the packagers and/or sysadmins can fix this without any changes to the PostgreSQL cod

Re: [HACKERS] What's the point of json_extract_path_op etc?

On 06/25/2014 02:46 PM, Tom Lane wrote: Why do we have essentially duplicate pg_proc entries for json_extract_path and json_extract_path_op? The latter is undocumented and seems only to be used as the infrastructure for the #> operator. I see that only the former is marked variadic, but AFAIK

Re: [HACKERS] NUMA packaging and patch

On Thu, Jun 26, 2014 at 11:18 AM, Kohei KaiGai wrote: > One thing I concern is, it may conflict with numa-balancing > features that is supported in the recent Linux kernel; that > migrates physical pages according to the location of tasks > which references the page beyond the numa zone. > # I'm n

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

Hi, Dne 2014-06-26 14:10, Pavel Stehule napsal: Hello all, today I had to work with one slow query - when I checked different scenarios I found a dependency on work_mem size - but it is atypical - bigger work_mem increased query execution 31 minutes (600MB work mem) and 1 minute (1MB). The pr

Re: [HACKERS] Re: how can i prevent materialized views from refreshing during pg_restore

I think this (pg_restore -l | pg_restore -L) will get me where I need to go for now by inserting a small shell script in between that pushes the materialized views to the end of the list, but then I will also have to manage my own dependencies for the items that I re-sort (MatViews of MatViews). Th

[HACKERS] Re: how can i prevent materialized views from refreshing during pg_restore

bithead wrote > I asked a question over on StackOverflow, and Craig Ringer told me to > report it here. > > http://stackoverflow.com/questions/24413161/how-can-i-prevent-materialized-views-from-refreshing-during-pg-restore > > I have created a dump of the database using pg_dump in "custom" format

Re: [HACKERS] ALTER SYSTEM RESET?

On 06/26/2014 05:07 AM, Amit Kapila wrote: > On Wed, Jun 25, 2014 at 9:56 PM, Vik Fearing > wrote: >> On 06/25/2014 03:04 PM, Amit Kapila wrote: >> > Currently you can achieve that by >> > "ALTER SYSTEM RESET guc = Default;". >> > However it will be good to have supp

[HACKERS] how can i prevent materialized views from refreshing during pg_restore

I asked a question over on StackOverflow, and Craig Ringer told me to report it here. http://stackoverflow.com/questions/24413161/how-can-i-prevent-materialized-views-from-refreshing-during-pg-restore I have created a dump of the database using pg_dump in "custom" format (-Fc). This format allows

Re: [HACKERS] better atomics - v0.5

On Thu, Jun 26, 2014 at 12:20:06PM +0200, Andres Freund wrote: > On 2014-06-25 20:16:08 -0400, Robert Haas wrote: > > On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund > > wrote: > > > Since it better be legal to manipulate a atomic variable while holding a > > > spinlock we cannot simply use an arb

Re: [HACKERS] NUMA packaging and patch

Hello, Let me comment on this patch. It can be applied on head of the master branch, built and run regression test successfully. What this patch tries to do is quite simple and obvious. It suggests operating system to distribute physical pages to every numa nodes on allocation. One thing I conce

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > "Which tables are audited" would be available via the reloptions > field. RLS could be implemented through reloptions too. Would it be useful to some people? Likely. Would it satisfy the users who, today, are actually asking for that featu

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

Abhijit, * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > Ian looked into the auditing capabilities of various (SQL and otherwise) > systems some time ago. Informix handles its auditing configuration > entirely outside the database. DB2 uses a mixture of in-database and > external configuration

Re: [Fwd: Re: [HACKERS] proposal: new long psql parameter --on-error-stop]

2014-06-26 15:26 GMT+02:00 MauMau : > Hello, > > From: "Pavel Stehule" > >> fixed >> > > Thank you. All is fine. > > > > should be ""Environment variables". And this section lacks description >>> for Windows, such as: >>> >>> + printf(_(" NAME=VALUE [NAME=VALUE] psql ...\n or \\setenv NAME >

Re: [HACKERS] crash with assertions and WAL_DEBUG

On 06/24/2014 05:47 PM, Alvaro Herrera wrote: diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c index 3c1c81a..4264373 100644 --- a/src/backend/storage/smgr/md.c +++ b/src/backend/storage/smgr/md.c @@ -219,6 +219,16 @@ mdinit(void)

Re: [Fwd: Re: [HACKERS] proposal: new long psql parameter --on-error-stop]

Hello, From: "Pavel Stehule" fixed Thank you. All is fine. should be ""Environment variables". And this section lacks description for Windows, such as: + printf(_(" NAME=VALUE [NAME=VALUE] psql ...\n or \\setenv NAME [VALUE] in interactive mode\n\n")); + printf(_(" PGPASSFILE

Re: [HACKERS] better atomics - v0.5

On 2014-06-26 07:44:14 -0500, Merlin Moncure wrote: > On Thu, Jun 26, 2014 at 5:20 AM, Andres Freund wrote: > > On 2014-06-25 20:16:08 -0400, Robert Haas wrote: > >> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund > >> wrote: > >> > Since it better be legal to manipulate a atomic variable while h

Re: [HACKERS] better atomics - v0.5

On Thu, Jun 26, 2014 at 5:20 AM, Andres Freund wrote: > On 2014-06-25 20:16:08 -0400, Robert Haas wrote: >> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund >> wrote: >> > Since it better be legal to manipulate a atomic variable while holding a >> > spinlock we cannot simply use an arbitrary spinl

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

Thanks for sharing latest patch. For me this syntax is limiting the current returning clause implementation. Because its not allowing the returning PRIMARY KEYS with other columns, and if user or application require that they need to do RETURNING *. Following syntax not working, which i think is v

[HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

Hello all, today I had to work with one slow query - when I checked different scenarios I found a dependency on work_mem size - but it is atypical - bigger work_mem increased query execution 31 minutes (600MB work mem) and 1 minute (1MB). db_kost07e2d9cdmg20b1takpqntobo6ghj=# set work_mem to '600

Re: [HACKERS] sorting a union over inheritance vs pathkeys

On Jun 25, 2014, at 22:14, Tom Lane wrote: > I wrote: >> Michael Glaesemann writes: >>> -- ERROR: could not find pathkey item to sort > >> Hm ... I can reproduce that in 9.3 but it seems fine in 9.4 and HEAD. >> Don't know what's going on exactly. > > Interesting --- it appears that commit >

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 25/06/14 19:43, Sawada Masahiko wrote: Hi, I send you review comment about thie patch. Hello, thanks. -- $ pg_resetxlog -s -n data | grep "Database system identifier" Database system identifier: 6028907917695471865 The -s option does not worksfine with -n option. Fixed. --

Re: [HACKERS] better atomics - v0.5

On 2014-06-25 20:22:31 -0400, Robert Haas wrote: > On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas > wrote: > > I think having a separate file for each architecture is nice. I totally > > agree that they don't belong in src/include/storage, though. s_lock.h has > > always been misplaced there,

Re: [HACKERS] better atomics - v0.5

On 2014-06-25 20:16:08 -0400, Robert Haas wrote: > On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund wrote: > > Since it better be legal to manipulate a atomic variable while holding a > > spinlock we cannot simply use an arbitrary spinlock as backing for > > atomics. That'd possibly cause us to wait

Re: [HACKERS] pg_receivexlog add synchronous mode

> The patch looks somewhat complicated and bugs can be easily introduced > because it tries to not only add new feature but also reorganize the main > loop in HandleCopyStream at the same time. To keep the patch simple, I'm > thinking to firstly apply the attached patch which just refactors the > m

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On 26 June 2014 10:31, David Rowley wrote: > If there's no way to tell that the target entry comes from a left join, then > would it be a bit too quirky to just do the NOT NULL checking when > list_length(query->rtable) == 1 ? or maybe even loop over query->rtable and > abort if we find an outer

[HACKERS] Re: [COMMITTERS] pgsql: Do all-visible handling in lazy_vacuum_page() outside its critic

On 2014-06-26 10:39:01 +0300, Heikki Linnakangas wrote: > On 06/24/2014 01:27 AM, Andres Freund wrote: > >Does your change still make > >sense to you and do you see problem with the current state (as of ecac0e2b)? > > Hmm, in the current state, it's again possible that the full-page image > doesn't

Re: [HACKERS] Allowing NOT IN to use ANTI joins

On Thu, Jun 26, 2014 at 3:52 AM, Tom Lane wrote: > Simon Riggs writes: > > To be clearer, what I mean is we use only the direct proof approach, > > for queries like this > > > SELECT * FROM a WHERE id NOT IN(SELECT unknown_col FROM b WHERE > > unknown_col IS NOT NULL); > > > and we don't try t

Re: [HACKERS] Allowing join removals for more join types

On 26 June 2014 10:01, David Rowley wrote: >> Did you comment on the transitive closure question? Should we add a >> test for that, whether or not it works yet? >> > > In my previous email. > > I could change the the following to use c.id in the targetlist and group by > clause, but I'm not reall

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 14/06/25 23:36, Stephen Frost wrote: > Other databases have had this kind of capability as a > matter of course for decades- we are far behind in this area. On a related note, MySQL/MariaDB have had some sort of auditing capability for, well, months. By no means as sophisticated as some of the

Re: [HACKERS] Allowing join removals for more join types

On Wed, Jun 25, 2014 at 10:03 AM, Simon Riggs wrote: > On 23 June 2014 12:06, David Rowley wrote: > > >> It's not clear to me where you get the term "sortclause" from. This is > >> either the groupclause or distinctclause, but in the test cases you > >> provide this shows this has nothing at all

Re: [HACKERS] idle_in_transaction_timeout

On 06/26/2014 06:45 AM, Fujii Masao wrote: >> The point of this feature, AFAICS, is to detect clients that are failing >> > to issue another query or close their transaction as a result of bad >> > client logic. It's not to protect against network glitches. > > If so, the document should explain t

[HACKERS] Re: [COMMITTERS] pgsql: Do all-visible handling in lazy_vacuum_page() outside its critic

On Tue, 2014-06-24 at 00:27 +0200, Andres Freund wrote: > > Can you explain? It looks like the master will still see the bit right > > away after the HEAP2_CLEAN record, but there is nothing in the > > HEAP2_CLEAN record to tell the standby to set all-visible. The standby > > has to wait until the

Re: [HACKERS] Allowing join removals for more join types

On Sun, Jun 22, 2014 at 11:51 PM, Simon Riggs wrote: > On 17 June 2014 11:04, David Rowley wrote: > > On Wed, Jun 4, 2014 at 12:50 AM, Noah Misch wrote: > >> > >> As a point of procedure, I recommend separating the semijoin support > into > >> its > >> own patch. Your patch is already not smal

[HACKERS] Changes in amcanreturn() interface to support multicolumn indexes

Changes in amcanreturn() interface to support multicolumn indexes. Hi, hackers I work on GSoC project Support_for_Index-only_scans_for_GIST_GSoC_2014 There is a question of support multicolumn index only scans for GI

Re: [HACKERS] postgresql.auto.conf and reload

Re: Amit Kapila 2014-06-26 > On Wed, Jun 25, 2014 at 7:52 PM, Christoph Berg wrote: > > Re: Amit Kapila 2014-06-25 < > caa4ek1+f9ztogvvw-wyj2+vt0k8_jxtziqhp8ivb7wdo1w1...@mail.gmail.com> > > > > > I think maintaining values both in postgresql.conf and by Alter System > > > is not advisable. > >

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 23 June 2014 21:51, Stephen Frost wrote: > I also wouldn't want this to become > an excuse to not improve our current logging infrastructure, which is > how we got to the place we are wrt partitioning, imv. Not the case at all. I wrote the existing partitioning code in 6 weeks in 2005, with

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 25 June 2014 15:40, Stephen Frost wrote: > * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: >> At 2014-06-25 00:10:55 -0400, sfr...@snowman.net wrote: >> > For my part, the nexts steps might be to consider how you'd migrate >> > what you've provided for configuration into catalog tables >> >>

Re: [HACKERS] ALTER SYSTEM RESET?

Re: Amit Kapila 2014-06-26 > On Wed, Jun 25, 2014 at 9:56 PM, Vik Fearing wrote: > > On 06/25/2014 03:04 PM, Amit Kapila wrote: > > > Currently you can achieve that by > > > "ALTER SYSTEM RESET guc = Default;". > > > However it will be good to have support for RESET as well. I think it > > > sh

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

At 2014-06-25 10:36:07 -0400, sfr...@snowman.net wrote: > > To me, that's ridiculous on the face of it. Other databases have had > this kind of capability as a matter of course for decades- we are far > behind in this area. OK, I've done a bit more thinking, but I'm not convinced that it's so cut

[HACKERS] Re: [COMMITTERS] pgsql: Do all-visible handling in lazy_vacuum_page() outside its critic

On 06/24/2014 01:27 AM, Andres Freund wrote: On 2014-06-23 13:00:11 -0700, Jeff Davis wrote: On Fri, 2014-06-20 at 09:10 +, Andres Freund wrote: To fix, simply move all the all-visible handling outside the critical section. Doing so means that the PD_ALL_VISIBLE on the page won't be include

Re: [HACKERS] Cluster name in ps output

On Thu, Jun 26, 2014 at 4:05 PM, Abhijit Menon-Sen wrote: > At 2014-06-25 16:13:19 +0900, masao.fu...@gmail.com wrote: >> >> Categorizing this parameter to CONN_AUTH_SETTINGS looks strange to me > > Oh yes. Sorry, I meant to respond to this point in my original review, > but forgot. Yes, CONN_AUTH

Re: [HACKERS] psql: show only failed queries

2014-06-26 8:22 GMT+02:00 Samrat Revagade : > > I am sending updated patch - buggy statement is printed via more logical > psql_error function instead printf > > Thank you for updating patch, I really appreciate your efforts. > > Now, everything is good from my side. > * it apply cleanly to the cu

Re: [HACKERS] Cluster name in ps output

At 2014-06-25 16:13:19 +0900, masao.fu...@gmail.com wrote: > > Categorizing this parameter to CONN_AUTH_SETTINGS looks strange to me Oh yes. Sorry, I meant to respond to this point in my original review, but forgot. Yes, CONN_AUTH_SETTINGS is just weird. But I couldn't find an obviously better ans