Re: [HACKERS] psql: show only failed queries

> 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 current git master * includes necessary docs * I think It i

Re: [HACKERS] [PATCH] log_{directory,filename} doc fixes

On Wed, Jun 25, 2014 at 11:38 PM, Christoph Berg wrote: > Hi, > > The defaults for log_directory and log_filename were undocumented, and > the log_filename docs still refered to a config example that was > removed with 8.4 deprecation of epoch-based logfilenames. Thanks! Committed. Regards, --

Re: [HACKERS] idle_in_transaction_timeout

On Thu, Jun 26, 2014 at 12:40 AM, Tom Lane wrote: > Fujii Masao writes: >> Why is IIT timeout turned on only when send_ready_for_query is true? >> I was thinking it should be turned on every time a message is received. >> Imagine the case where the session is in idle-in-transaction state and >> a

Re: [HACKERS] Re: [BUGS] BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby

Andres Freund wrote: > On 2014-06-20 17:38:16 -0400, Alvaro Herrera wrote: > > It seems to me that we need to keep the offsets files around until a > > checkpoint has written the "oldest" number to WAL. In other words we > > need additional state in shared memory: (a) what we currently store > >

Re: [HACKERS] Scaling shared buffer eviction

On Mon, Jun 9, 2014 at 9:33 AM, Amit Kapila wrote: > On Sun, Jun 8, 2014 at 7:21 PM, Kevin Grittner wrote: > > Backend processes related to user connections still > > performed about 30% of the writes, and this work shows promise > > toward bringing that down, which would be great; but please don

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

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. > > Possibly, but then the system should be w

Re: [HACKERS] ALTER SYSTEM RESET?

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 > > should not be too complicated to implement

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

On 25/06/14 16:04, Ian Barwick wrote: Hi On 14/06/25 15:13, Rushabh Lathia wrote: Hello All, I assigned my self as reviewer of the patch. I gone through the mail chain discussion and in that question has been raised about the feature and its implementation, so would like to know what is the cu

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

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 a87c729153e372f3731689a7be007bc2b53f1410 is why it works in

Re: [HACKERS] Inaccuracy in VACUUM's tuple count estimates

Given that this seems to have slipped off the hackers radar (or in too hard basket) I have constructed a horrible solution. I will stop using autovacuum for this relation , I will use our own system to monitor the relation, and I will reset pgclass.reltuples on this relation after vacuum is done t

Re: [HACKERS] Set new system identifier using pg_resetxlog

On Thu, Jun 26, 2014 at 2:43 AM, Sawada Masahiko wrote: > Hi, > > I send you review comment about thie patch. > > I found no error/warning with compling and installation. > I have executed pg_resetxlog with some input pattern. > > $ initdb -D data -E UTF8 --no-locale > $ pg_controldata data | gre

Re: [HACKERS] better atomics - v0.5

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, but we've let it be for historical reasons, but > now that

Re: [HACKERS] better atomics - v0.5

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 on ourselves or cause > deadlocks. I think that's going

Re: [HACKERS] makeAndExpr(), etc. confined to gram.y?

On Thu, Jun 26, 2014 at 12:46 AM, Tom Lane wrote: > Amit Langote writes: >> Yeah, that is true. Sorry, I am unaware as to how generic make* >> functions in gram.y are and how they differ from those in makefuncs.c. > >> So, use of make* family of functions outside parser is their abuse in >> some

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

My cut'n'pasting failed me at one point corrected below. > discussion about what is the difference between a synchronous read > versus an asynchronous read as far as non-originator waiting on it is > concerned. > > I thought a bit more about this. There are currently two differences, > one of

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

Michael Glaesemann writes: > I’ve come across an issue when creating a union over tables which includes > inheritance: > CREATE TABLE events (event_id INT NOT NULL); > -- CREATE TABLE > CREATE UNIQUE INDEX events_event_id_key ON events (event_id); > -- CREATE INDEX > CREATE TABLE legacy_events

Re: [HACKERS] better atomics - v0.5

Heikki Linnakangas wrote: > On 06/25/2014 11:36 PM, Andres Freund wrote: > > > >>>- I completely loathe the file layout you've proposed in > >>>src/include/storage. If we're going to have separate #include files > >>>for each architecture (and I'd rather we didn't go that route, because > >>>it's

[HACKERS] sorting a union over inheritance vs pathkeys

I’ve come across an issue when creating a union over tables which includes inheritance: CREATE TABLE events (event_id INT NOT NULL); -- CREATE TABLE CREATE UNIQUE INDEX events_event_id_key ON events (event_id); -- CREATE INDEX CREATE TABLE legacy_events (event_id INT NOT NULL); -- CREATE TABLE C

Re: [HACKERS] better atomics - v0.5

On 06/25/2014 11:36 PM, Andres Freund wrote: >- I completely loathe the file layout you've proposed in >src/include/storage. If we're going to have separate #include files >for each architecture (and I'd rather we didn't go that route, because >it's messy and unlike what we have now), then sho

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

On 2014-06-26 00:08:48 +0300, Heikki Linnakangas wrote: > LWLocks are implemented with semaphores, so if you can increment a semaphore > in the signal handler / callback thread, then in theory you should be able > to release a LWLock. I don't think that's a convincing argument even if semop et al

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

On 06/25/2014 09:20 PM, Claudio Freire wrote: On Tue, Jun 24, 2014 at 12:08 PM, John Lumby wrote: The question is, if you receive the notification of the I/O completion using a signal or a thread, is it safe to release the lwlock from the signal handler or a separate thread? In the forthcomin

Re: [HACKERS] RLS Design

On 25 June 2014 16:44, Robert Haas wrote: > On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost wrote: >> Let's try to outline what this would look like then. >> >> Taking your approach, we'd have: >> >> CREATE POLICY p1; >> CREATE POLICY p2; >> >> ALTER TABLE t1 SET POLICY p1 TO t1_p1_quals; >> ALTER

Re: [HACKERS] better atomics - v0.5

Hi, On 2014-06-25 15:54:37 -0400, Robert Haas wrote: > - The new argument to s_init_lock_sema() isn't used. It's used when atomics fallback to spinlocks which fall back to semaphores. c.f. atomics.c. Since it better be legal to manipulate a atomic variable while holding a spinlock we cannot simp

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

Well, the fact that initdb didn't produce a working configuration and that make installcheck failed to work properly are bad. But, yeah, it's not totally broken. I think it did create a working configuration (with the exception of postgresql.conf), because I can run psql and do stuff on the co

Re: [HACKERS] psql: show only failed queries

ECHO_HIDDEN? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Wed, Jun 25, 2014 at 1:58 PM, John Klos wrote: >> Well, the fact that initdb didn't produce a working configuration and >> that make installcheck failed to work properly are bad. But, yeah, >> it's not totally broken. > > I think it did create a working configuration (with the exception of > p

Re: [HACKERS] better atomics - v0.5

On Wed, Jun 25, 2014 at 1:14 PM, Andres Freund wrote: > [sorry for the second copy Robert] > > Attached is a new version of the atomic operations patch. Lots has > changed since the last post: > > * gcc, msvc work. acc, xlc, sunpro have blindly written support which > should be relatively easy t

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

Hello Here is next update 2014-06-25 17:17 GMT+02:00 MauMau : > OK, let me help you, though I'm only a Japanese who is never confident in > my English. > > (1) > As Fujii-san pointed out, could you add explanation for --help-variables > in doc/src/sgml/ref/psqlref.sgml? > > > (2) > > + printf(_

Re: [HACKERS] RLS Design

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost wrote: > > Let's try to outline what this would look like then. > > > > Taking your approach, we'd have: > > > > CREATE POLICY p1; > > CREATE POLICY p2; > > > > ALTER TABLE t1 SET POLICY p1 TO t1_p1_quals

Re: [HACKERS] ALTER SYSTEM RESET?

On Wed, Jun 25, 2014 at 1:26 PM, Vik Fearing wrote: > On 06/25/2014 03:04 PM, Amit Kapila wrote: > > On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg > > wrote: > >> > >> Hi, > >> > >> is there a reason there's no ALTER SYSTEM RESET? > >> > >> The natural idiom to reset SET

Re: [HACKERS] pg_filedump for 9.4?

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: > I'm thinking in run "pgindent" to better organize the source code... What > do you think? Would like that, but I'm not sure what pgindent will do with the // comments. It's been on my to-do list to switch all the comments to C89 style and then p

Re: [HACKERS] psql: show only failed queries

2014-06-25 12:32 GMT+02:00 Samrat Revagade : > Hi Pavel, > > After applying patch, on error condition it displays error message two > times as follows: > > ERROR: column "abc" does not exist at character 23 > STATEMENT: insert into ax > values(abc); > psql:a.sql:7: ERROR: column "abc" does not

Re: [HACKERS] pg_filedump for 9.4?

On Wed, Jun 25, 2014 at 1:28 PM, Tom Lane wrote: > > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: > > On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane wrote: > >> Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > >>> Will there be a pg_filedump for 9.4? I'd like to finish package tests > >>> before we

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

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 the operator machinery couldn't care less a

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

On Tue, Jun 24, 2014 at 12:08 PM, John Lumby wrote: >> The question is, if you receive the notification of the I/O completion >> using a signal or a thread, is it safe to release the lwlock from the >> signal handler or a separate thread? > > In the forthcoming new version of the patch that uses

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

Hi, I got following FAILED when I patched v3 to HEAD. $ patch -d. -p1 < ../patch/vacuumdb_parallel_v3.patch patching file doc/src/sgml/ref/vacuumdb.sgml Hunk #1 succeeded at 224 (offset 20 lines). patching file src/bin/scripts/Makefile Hunk #2 succeeded at 65 with fuzz 2 (offset -1 lines). patchi

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

Robert Haas writes: > On Wed, Jun 25, 2014 at 1:05 PM, John Klos wrote: >> While I wouldn't be surprised if you remove the VAX code because not many >> people are going to be running PostgreSQL, I'd disagree with the assessment >> that this port is broken. It compiles, it initializes databases, i

Re: [HACKERS] Set new system identifier using pg_resetxlog

Hi, I send you review comment about thie patch. I found no error/warning with compling and installation. I have executed pg_resetxlog with some input pattern. $ initdb -D data -E UTF8 --no-locale $ pg_controldata data | grep "Database system identifier" Database system identifier: 6028

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas wrote: > Well, the fact that initdb didn't produce a working configuration and > that make installcheck failed to work properly are bad. But, yeah, > it's not totally broken. Yeah it seems to me that these kinds of autoconf and initdb tests failing a

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

That's all I have time for tonight. Is there an easier way to run a testsuite? I think you're doing it right, but apparently configure is mis-identifying which flags are needed for thread-safety on your platform. It's possible configuring with --disable-thread-safety would help, or you could ma

Re: [HACKERS] better atomics - v0.5

On 2014-06-25 10:39:53 -0700, Josh Berkus wrote: > On 06/25/2014 10:14 AM, Andres Freund wrote: > > Hi, > > > > [sorry for the second copy Robert] > > > > Attached is a new version of the atomic operations patch. Lots has > > changed since the last post: > > Is this at a state where we can perfo

Re: [HACKERS] better atomics - v0.5

On 06/25/2014 10:14 AM, Andres Freund wrote: > Hi, > > [sorry for the second copy Robert] > > Attached is a new version of the atomic operations patch. Lots has > changed since the last post: Is this at a state where we can performance-test it yet? -- Josh Berkus PostgreSQL Experts Inc. http:/

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 06/25/2014 05:30 AM, John Klos wrote: >> What value did it select for shared_buffers? How much memory does a >> high-end VAX have? These days, we try to set shared_buffers = 128MB >> if the platform will support it, but it's supposed to fall back to >> smaller values if that doesn't work. It

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 25 June 2014 12:38, Toby Thain wrote: > On 24/06/14 10:16 PM, John Klos wrote: >> >> Hi, >> >>> Has anyone tried to build PostgreSQL for VAX lately? If so, did it >>> compile? Did you have to use --disable-spinlocks to get it to >>> compile? If it did compile, can you actually run it, and doe

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 24/06/14 10:16 PM, John Klos wrote: Hi, Has anyone tried to build PostgreSQL for VAX lately? If so, did it compile? Did you have to use --disable-spinlocks to get it to compile? If it did compile, can you actually run it, and does it pass the regression tests and work as expected? Would y

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

Hi, What value did it select for shared_buffers? How much memory does a high-end VAX have? These days, we try to set shared_buffers = 128MB if the platform will support it, but it's supposed to fall back to smaller values if that doesn't work. It will try allocating that much though, at least

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

Hi, Has anyone tried to build PostgreSQL for VAX lately? If so, did it compile? Did you have to use --disable-spinlocks to get it to compile? If it did compile, can you actually run it, and does it pass the regression tests and work as expected? Would you be willing to work with the Postgr

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

John Klos skrev 2014-06-25 04:16: Then the machine paniced. The serial console showed: panic: usrptmap space leakage cpu0: Begin traceback... panic: usrptmap space leakage Stack traceback : Process is executing in user space. cpu0: End traceback... Hm, can you add info about this panic

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Wed, Jun 25, 2014 at 1:05 PM, John Klos wrote: >> In any case I'm coming to the conclusion that there's little point in >> us keeping the VAX-specific code in our source tree, because in fact, >> this port is broken and doesn't work. Based on your results thus far, >> I doubt that it would be

Re: Bug in spg_range_quad_inner_consistent for adjacent operator (was Re: [HACKERS] Add a filed to PageHeaderData)

On 06/24/2014 11:22 PM, Heikki Linnakangas wrote: The real bug is in spg_range_quad_inner_consistent(), for the adjacent operator. Things go wrong when: The scan key is [100, 500) The prev centroid is [500, 510) The current centroid is [544, 554). The row that should match but isn't returned, [

Re: [HACKERS] pg_filedump for 9.4?

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: > On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane wrote: >> Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: >>> Will there be a pg_filedump for 9.4? I'd like to finish package tests >>> before we release 9.4.0. >> Probably, but I have no time for it right

Re: [HACKERS] ALTER SYSTEM RESET?

On 06/25/2014 03:04 PM, Amit Kapila wrote: > On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg > wrote: >> >> Hi, >> >> is there a reason there's no ALTER SYSTEM RESET? >> >> The natural idiom to reset SET statements is "RESET guc;", I don't >> think "SET guc = default;" is in

Re: [HACKERS] 9.3 minor release soon?

Bruce Momjian wrote: > Are we nearing a minor release deadline for 9.3? There will need to be > fix-up query in the minor release notes for pg_upgrade: > > > http://www.postgresql.org/message-id/20140530121631.ge25...@alap3.anarazel.de There's one more multixact bugfix pending, actually,

Re: [HACKERS] pg_filedump for 9.4?

On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane wrote: > > Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > > Will there be a pg_filedump for 9.4? I'd like to finish package tests > > before we release 9.4.0. > > Probably, but I have no time for it right now. > > FWIW, I believe the current "9.3" sources

Re: [HACKERS] ALTER SYSTEM RESET?

On Wed, Jun 25, 2014 at 10:04 AM, Amit Kapila wrote: > > On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg wrote: > > > > Hi, > > > > is there a reason there's no ALTER SYSTEM RESET? > > > > The natural idiom to reset SET statements is "RESET guc;", I don't > > think "SET guc = default;" is in use

Re: [HACKERS] wrapping in extended mode doesn't work well with default pager

2014-06-24 19:45 GMT+02:00 Sergey Muraviov : > Hi. > > Is there any problem with the patch? > I tested it and I had not any issue with last version So, please, commit it Regards Pavel > > > 2014-06-17 0:21 GMT+04:00 Greg Stark : > > On Mon, Jun 16, 2014 at 9:05 PM, Robert Haas >> wrote: >>

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

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 to do it for queries like this > SELECT * FROM a WHERE id NOT I

Re: [HACKERS] makeAndExpr(), etc. confined to gram.y?

Amit Langote writes: > On Wed, Jun 25, 2014 at 1:27 PM, Tom Lane wrote: >> Amit Langote writes: >>> Is there a reason why they've been left out of >>> makefuncs.h/makefuncs.c? Perhaps they are not supposed to be used >>> outside gram.y at all? For example, previously a caller (potentially) >>> o

Re: [HACKERS] RLS Design

On Tue, Jun 24, 2014 at 8:49 PM, Stephen Frost wrote: > Let's try to outline what this would look like then. > > Taking your approach, we'd have: > > CREATE POLICY p1; > CREATE POLICY p2; > > ALTER TABLE t1 SET POLICY p1 TO t1_p1_quals; > ALTER TABLE t1 SET POLICY p2 TO t1_p2_quals; This seems li

Re: [HACKERS] idle_in_transaction_timeout

Fujii Masao writes: > Why is IIT timeout turned on only when send_ready_for_query is true? > I was thinking it should be turned on every time a message is received. > Imagine the case where the session is in idle-in-transaction state and > a client gets stuck after sending Parse message and before

Re: [HACKERS] pg_filedump for 9.4?

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > Will there be a pg_filedump for 9.4? I'd like to finish package tests > before we release 9.4.0. Probably, but I have no time for it right now. FWIW, I believe the current "9.3" sources still work with HEAD/9.4. regards, tom l

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

OK, let me help you, though I'm only a Japanese who is never confident in my English. (1) As Fujii-san pointed out, could you add explanation for --help-variables in doc/src/sgml/ref/psqlref.sgml? (2) + printf(_(" --help-variables list of available configuration variables (options)

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

* 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 > > I must confess that I do not understand what needs

[HACKERS] [PATCH] log_{directory,filename} doc fixes

Hi, The defaults for log_directory and log_filename were undocumented, and the log_filename docs still refered to a config example that was removed with 8.4 deprecation of epoch-based logfilenames. Christoph -- c...@df7cb.de | http://www.df7cb.de/ diff --git a/doc/src/sgml/config.sgml b/doc/src/

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

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > > > We have some time available to work on it, but not so much that I want > > > to write any more code without a clearer idea of what might be accepted > > > e

Re: [HACKERS] RLS Design the rewriter into the planner?

Robert, all, Changing the thread topic to match the other one, and adding Dean in explicitly since we're talking about the design discussed with him. * Robert Haas (robertmh...@gmail.com) wrote: > I think role is good enough. That's the primary identifier for all > access-control related decisio

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

Re: Amit Kapila 2014-06-25 > The main reason behind such such a behaviour after restart is > that there are duplicate entries, one in postgresql.conf and > another in postgresql.conf. It always first read postgresql.conf > and then .auto file and applies the changed parameters one by one, > so w

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

On Wed, Jun 25, 2014 at 7:45 PM, Amit Kapila wrote: > > On Wed, Jun 25, 2014 at 6:47 PM, Christoph Berg wrote: > > Re: Amit Kapila 2014-06-25 < caa4ek1log98jvfov9wztqpcdewja+5jr54ttpkiz3xbngjy...@mail.gmail.com> > > > This will happen without Alter System as well, if you change > > > the value of

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

On Wed, Jun 25, 2014 at 6:47 PM, Christoph Berg wrote: > Re: Amit Kapila 2014-06-25 < caa4ek1log98jvfov9wztqpcdewja+5jr54ttpkiz3xbngjy...@mail.gmail.com> > > This will happen without Alter System as well, if you change > > the value of port in postgresql.conf and try to load conf file with SIGHUP.

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

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 I must confess that I do not understand what needs to be migrated into the catalog tables, or why. Of course,

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

Stephen Frost wrote: > Abhijit, > > * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote: > > At 2014-06-24 14:02:11 -0400, sfr...@snowman.net wrote: > > > > > > Will you (collectively) be working in this direction for 9.5? > > > > We have some time available to work on it, but not so much that I wan

Re: [HACKERS] Wait free LW_SHARED acquisition - v0.2

On Tue, Jun 24, 2014 at 9:33 AM, Amit Kapila wrote: > On Mon, Jun 23, 2014 at 9:12 PM, Andres Freund wrote: > > On 2014-06-23 19:59:10 +0530, Amit Kapila wrote: > > > 7. > > > LWLockWaitForVar() > > > { > > > .. > > > /* > > > * Add myself to wait queue. Note that this is racy, somebody else > >

Re: [HACKERS] RLS Design

* Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 25 June 2014 01:49, Stephen Frost wrote: > > I can't recall a system where managers have to request access to their > > manager role. Having another way of changing the permissions which are > > applied to a session (the existing one being 'se

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

Re: Amit Kapila 2014-06-25 > On Wed, Jun 25, 2014 at 6:11 PM, Christoph Berg wrote: > > > > I've just run into this: > > > > $ psql -p 5433 (that port is configured in postgresql.conf) > > # alter system set port = 5494; > > > > ... restart the server > > > > $ psql -p 5494 > > # select pg_rel

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

Hi, On Wed, 2014-06-25 at 18:42 +0530, Amit Kapila wrote: > This will happen without Alter System as well, if you change > the value of port in postgresql.conf and try to load conf file with > SIGHUP. You cannot reload PGC_POSTMASTER parameters without server > restart. Ok, but Christoph already

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

On Tue, Jun 24, 2014 at 12:27 PM, Stephen Frost wrote: > I feel like we are getting to the point of simply talking past each > other and so I'll try anew, and I'll include my understanding of how the > different approaches would address the specific use-case you outlined > up-thread. Thanks, you'

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

On Wed, Jun 25, 2014 at 6:11 PM, Christoph Berg wrote: > > I've just run into this: > > $ psql -p 5433 (that port is configured in postgresql.conf) > # alter system set port = 5494; > > ... restart the server > > $ psql -p 5494 > # select pg_reload_conf(); > > 2014-06-25 14:22:07 CEST [11297-4]

[HACKERS] pg_filedump for 9.4?

Hi, Will there be a pg_filedump for 9.4? I'd like to finish package tests before we release 9.4.0. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzT

Re: [HACKERS] ALTER SYSTEM RESET?

On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg wrote: > > Hi, > > is there a reason there's no ALTER SYSTEM RESET? > > The natural idiom to reset SET statements is "RESET guc;", I don't > think "SET guc = default;" is in use much, so "ALTER SYSTEM RESET guc;" > would be the natural way to try. C

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Wed, Jun 25, 2014 at 5:30 AM, John Klos wrote: > A high end VAX, such as a 4000 Model 108, can have 512 megs (as can an > 11/780, at least in theory), but most of the VAXen used here are VAXstations > such as the 4000/60 or 4000/90, 90a or 96, which have either 104 megs or 128 > megs. Hmm, not

[HACKERS] ALTER SYSTEM RESET?

Hi, is there a reason there's no ALTER SYSTEM RESET? The natural idiom to reset SET statements is "RESET guc;", I don't think "SET guc = default;" is in use much, so "ALTER SYSTEM RESET guc;" would be the natural way to try. Also, ALTER SYSTEM SET/RESET seems to be what oracle does: http://docs.

[HACKERS] postgresql.auto.conf and reload

I've just run into this: $ psql -p 5433 (that port is configured in postgresql.conf) # alter system set port = 5494; ... restart the server $ psql -p 5494 # select pg_reload_conf(); 2014-06-25 14:22:07 CEST [11297-4] LOG: received SIGHUP, reloading configuration files 2014-06-25 14:22:07 CE

Re: [HACKERS] RLS Design

On 25 June 2014 01:49, Stephen Frost wrote: > Dean, all, > > Changing the subject of this thread (though keeping it threaded) as > we've really moved on to a much broader discussion. > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> On 24 June 2014 17:27, Stephen Frost wrote: >> > Single po

[HACKERS] 9.3 minor release soon?

Are we nearing a minor release deadline for 9.3? There will need to be fix-up query in the minor release notes for pg_upgrade: http://www.postgresql.org/message-id/20140530121631.ge25...@alap3.anarazel.de -- Bruce Momjian http://momjian.us EnterpriseDB

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

On 24 June 2014 23:22, Simon Riggs wrote: >> On a more positive or even slightly exciting note I think I've managed to >> devise a way that ANTI JOINS can be used for NOT IN much more often. It >> seems that find_nonnullable_vars will analyse a quals list to find >> expressions that mean that the

Re: [HACKERS] Quantify small changes to predicate evaluation

On Tue, Jun 17, 2014 at 5:23 PM, Dennis Butterstein wrote: > I tried the proposed tweaks and > see some differences regarding the measurements. > Unfortunately the variance between the runs seems to remain high. Using these techniques I managed to get standard deviation below 1.5% in my read-only

Re: [HACKERS] psql: show only failed queries

Hi Pavel, After applying patch, on error condition it displays error message two times as follows: ERROR: column "abc" does not exist at character 23 STATEMENT: insert into ax values(abc); psql:a.sql:7: ERROR: column "abc" does not exist LINE 2: values(abc); user may confuse because of repea

Re: [HACKERS] pg_receivexlog add synchronous mode

On Wed, Jun 25, 2014 at 3:50 AM, Fujii Masao wrote: > On Tue, Jun 24, 2014 at 3:18 PM, wrote: >>> I found that this patch breaks --status-interval option of >>> pg_receivexlog when -m option which the patch introduced is supplied. >>> When -m is set, pg_receivexlog tries to send the feedback mes

Re: [HACKERS] makeAndExpr(), etc. confined to gram.y?

On Wed, Jun 25, 2014 at 1:27 PM, Tom Lane wrote: > Amit Langote writes: >> Is there a reason why they've been left out of >> makefuncs.h/makefuncs.c? Perhaps they are not supposed to be used >> outside gram.y at all? For example, previously a caller (potentially) >> outside parser could do a make

Re: [HACKERS] Cluster name in ps output

>> * cluster_name moved to config group CONN_AUTH_SETTINGS, on the >> basis that it's similar to bonjour_name, but it isn't >> really... open to suggestions for a better config_group! Categorizing this parameter to CONN_AUTH_SETTINGS looks strange to me because it's not directly related to con

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

Hi On 14/06/25 15:13, Rushabh Lathia wrote: > Hello All, > > I assigned my self as reviewer of the patch. I gone through the > mail chain discussion and in that question has been raised about > the feature and its implementation, so would like to know what is > the current status of this project/