Re: pgsql: Integrate recovery.conf into postgresql.conf

2018-11-26 Thread David Steele
On 11/26/18 10:35 AM, Abhijit Menon-Sen wrote: At 2018-11-26 10:18:52 -0500, sfr...@snowman.net wrote: This came originally to check that recovery.conf handles correctly its recovery targets when multiple ones are defined with the last one winning […] Ugh, no, I don't agree that this

Re: Constraint documentation

2018-11-26 Thread Alvaro Herrera
I have pushed this. On 2018-Nov-26, David Fetter wrote: > On Thu, Nov 22, 2018 at 03:16:11PM +0100, Patrick Francelle wrote: > > > To address your remark, I added a small message in the CREATE TABLE > > reference page to be more explicit about the topic, so that it would be > > a warning for the

Re: pgsql: Integrate recovery.conf into postgresql.conf

2018-11-26 Thread Abhijit Menon-Sen
At 2018-11-26 10:18:52 -0500, sfr...@snowman.net wrote: > > > This came originally to check that recovery.conf handles correctly > > its recovery targets when multiple ones are defined with the last > > one winning […] > > Ugh, no, I don't agree that this property makes sense to keep and > since

Re: csv format for psql

2018-11-26 Thread David G. Johnston
On Sun, Nov 25, 2018 at 6:27 PM Tom Lane wrote: > I think there are two remaining points to settle: > > 1. Are we limiting the separator to be a single-byte character or not? I agree with what others have said that expanding functionality in this direction is more likely to mask errors than be

Re: pgsql: Integrate recovery.conf into postgresql.conf

2018-11-26 Thread Stephen Frost
Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Mon, Nov 26, 2018 at 02:06:36PM +0100, Peter Eisentraut wrote: > > What is the reason for allowing multiple recovery_target_* settings and > > taking the last one? > > This came originally to check that recovery.conf handles

Re: Updated backup APIs for non-exclusive backups

2018-11-26 Thread Stephen Frost
Greetings, * David Steele (da...@pgmasters.net) wrote: > On 11/26/18 12:31 AM, Laurenz Albe wrote: > >If there is a crash during the backup procedure, the backup is bad. > >Doesn't matter during which part of the backup procedure it happens. > > Yes, but in this case with exclusive backups your

Re: Updated backup APIs for non-exclusive backups

2018-11-26 Thread David Steele
On 11/26/18 12:31 AM, Laurenz Albe wrote: On Sun, 2018-11-25 at 16:04 -0500, Stephen Frost wrote: There isn’t any need to write the backup label before you restore the database, just as you write recovery.conf then. Granted. But it is pretty convenient, and writing it to the data directory

Re: Doc patch on psql output formats

2018-11-26 Thread Tom Lane
"Daniel Verite" writes: > Tom Lane wrote: >> As of HEAD, it's impossible to select latex output format >> at all: >> regression=# \pset format latex >> \pset: ambiguous abbreviation "latex" matches both "latex" and >> "latex-longtable" > Oops! >> We could fix that by adding a special case

Re: COPY FROM WHEN condition

2018-11-26 Thread Surafel Temesgen
On Sat, Nov 24, 2018 at 5:09 AM Tomas Vondra wrote: > > 1) While comparing this to the FILTER clause we already have for > aggregates, I've noticed the aggregate version is > > FILTER '(' WHERE a_expr ')' > > while here we have > > FILTER '(' a_expr ')' > > For a while I was thinking

Re: pgsql: Integrate recovery.conf into postgresql.conf

2018-11-26 Thread Sergei Kornilov
Hi > What is the reason for allowing multiple recovery_target_* settings and > taking the last one? Could we change this aspect to make this behave > better? Correct response to user configuration, similar to old recovery.conf logic or other GUC - we allow redefine with rule "latest win". I

Re: pgsql: Integrate recovery.conf into postgresql.conf

2018-11-26 Thread Michael Paquier
On Mon, Nov 26, 2018 at 02:06:36PM +0100, Peter Eisentraut wrote: > What is the reason for allowing multiple recovery_target_* settings and > taking the last one? This came originally to check that recovery.conf handles correctly its recovery targets when multiple ones are defined with the last

Re: pgsql: Integrate recovery.conf into postgresql.conf

2018-11-26 Thread Peter Eisentraut
On 26/11/2018 13:32, Sergei Kornilov wrote: >> Timed out while waiting for standby to catch up at >> t/003_recovery_targets.pl line 34. > > I can reproduce this and notice wrong assign settings order. For example > standby_6 has >> recovery_target_name = '$recovery_name' >>

Re: COPY FROM WHEN condition

2018-11-26 Thread Surafel Temesgen
On Sat, Nov 24, 2018 at 12:02 PM Dean Rasheed wrote: > Right now we have 2 syntaxes for filtering rows in queries, both of > which use WHERE immediately before the condition: > > 1). SELECT ... FROM ... WHERE condition > > 2). SELECT agg_fn FILTER (WHERE condition) FROM ... > > I'm not a huge

Re: A WalSnd issue related to state WALSNDSTATE_STOPPING

2018-11-26 Thread Michael Paquier
On Thu, Nov 22, 2018 at 06:31:04PM +0800, Paul Guo wrote: > Yes, please see the attached patch. Thanks, I have reviewed your patch, and could not resist to change SyncRepReleaseWaiters() on top of the rest with a comment to not be confused about the WAL sender states allowed to release waiters.

Re: SQL/JSON: functions

2018-11-26 Thread Dmitry Dolgov
> On Tue, Jul 3, 2018 at 2:57 PM Pavel Stehule wrote: > > 2018-07-03 14:30 GMT+02:00 Nikita Glukhov : >> >> Attached 16th version of the patches: >> * changed type of new SQL keyword STRING >>(STRING is used as a function parameter name in Pl/Tcl tests) >> * removed implicit coercion via

Re: SQL/JSON: JSON_TABLE

2018-11-26 Thread Dmitry Dolgov
> On Tue, Jul 3, 2018 at 4:50 PM Nikita Glukhov wrote: > > Attached 16th version of JSON_TABLE patches. > > Changed only results of regression tests after the implicit coercion via I/O > was removed from JSON_VALUE. Thank you for working on this patch! Unfortunately, the current version of patch

Re: pgsql: Integrate recovery.conf into postgresql.conf

2018-11-26 Thread Sergei Kornilov
Hi > The buildfarm is unhappy after this one: > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=culicidae=HEAD > > If I use -DEXEC_BACKEND when compiling the tests complain about a > timeout in 003_recovery_targets. Here is what the buildfarm reports, I > can see the failure by myself

RE: Global shared meta cache

2018-11-26 Thread Ideriha, Takeshi
Hi, >From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com] >Sent: Wednesday, October 3, 2018 3:18 PM >At this moment this patch only allocates catalog cache header and CatCache >data on >the shared memory area. On this allocation stuffs I'm trying to handle it in another thread [1] in a

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

2018-11-26 Thread Vik Fearing
On 23/11/2018 00:09, Haribabu Kommi wrote: > > On Fri, Nov 23, 2018 at 1:54 AM Peter Eisentraut > > wrote: > > On 19/11/2018 06:18, Haribabu Kommi wrote: > > Amit suggested another option in another mail, so total viable  > > solutions that

Re: Doc patch on psql output formats

2018-11-26 Thread Daniel Verite
Tom Lane wrote: > As of HEAD, it's impossible to select latex output format > at all: > > regression=# \pset format latex > \pset: ambiguous abbreviation "latex" matches both "latex" and > "latex-longtable" Oops! > We could fix that by adding a special case to accept an exact match >

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

2018-11-26 Thread Amit Kapila
On Fri, Nov 23, 2018 at 4:40 AM Haribabu Kommi wrote: > > > On Fri, Nov 23, 2018 at 1:54 AM Peter Eisentraut > wrote: >> >> On 19/11/2018 06:18, Haribabu Kommi wrote: >> > Amit suggested another option in another mail, so total viable >> > solutions that are discussed as of now are, >> > >> >

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

2018-11-26 Thread Amit Kapila
On Thu, Nov 22, 2018 at 7:51 PM Amit Kapila wrote: > > On Thu, Nov 22, 2018 at 7:48 PM Amit Kapila wrote: > > > > On Thu, Nov 22, 2018 at 7:02 PM Alvaro Herrera > > wrote: > > > > > > On 2018-Nov-20, Haribabu Kommi wrote: > > > > > > > > > 4. Single API with -1 as invalid value, treat NULL as

Re: WIP: Avoid creation of the free space map for small tables

2018-11-26 Thread Amit Kapila
On Mon, Nov 26, 2018 at 3:46 PM John Naylor wrote: > > On 11/24/18, Amit Kapila wrote: > > On Fri, Nov 23, 2018 at 11:56 AM John Naylor wrote: > >> On 11/16/18, Amit Kapila wrote: > >> > >> > > >> > 3. > >> > static int fsm_set_and_search(Relation rel, FSMAddress addr, uint16 > >> > slot, >

Re: csv format for psql

2018-11-26 Thread Daniel Verite
Tom Lane wrote: > And, in fact, right now *none* of psql's table output formats is both > unambiguous and reasonably simple/popular to use. So the astonishing > thing about this patch, IMO, is that we didn't do it a decade ago. Yeah, that's what motivated this submission in the first

RE: Shared Memory: How to use SYSV rather than MMAP ?

2018-11-26 Thread REIX, Tony
Hi Thomas, About reliability, I've compiled/tested with GCC/XLCC on 2 machines in order to check that my patches are OK (no impact to PostgreSQL tests, OK both with GCC & XLC). We do not have yet performance comparison between GCC & XLC since, though we experimented with both, we moved from

Re: WIP: Avoid creation of the free space map for small tables

2018-11-26 Thread John Naylor
On 11/24/18, Amit Kapila wrote: > On Fri, Nov 23, 2018 at 11:56 AM John Naylor wrote: >> On 11/16/18, Amit Kapila wrote: >> >> > >> > 3. >> > static int fsm_set_and_search(Relation rel, FSMAddress addr, uint16 >> > slot, >> > -uint8 newValue, uint8 minValue); >> > + uint8 newValue, uint8

Re: Continue work on changes to recovery.conf API

2018-11-26 Thread Michael Paquier
On Sun, Nov 25, 2018 at 04:56:13PM +0100, Peter Eisentraut wrote: > Committed with that addition. Thanks for adding that! -- Michael signature.asc Description: PGP signature

Re: allow online change primary_conninfo

2018-11-26 Thread Sergei Kornilov
Hi >>  I think we have no futher reason to have a copy of conninfo and slot name >> in WalRcvData, so i propose remove these fields from >> pg_stat_get_wal_receiver() (and pg_stat_wal_receiver view). This data can be >> accesible now via regular GUC commands. > > Is that wise? It seems

Re: Updated backup APIs for non-exclusive backups

2018-11-26 Thread Magnus Hagander
On Mon, Nov 26, 2018 at 6:44 AM Laurenz Albe wrote: > On Sun, 2018-11-25 at 22:01 +0100, Magnus Hagander wrote: > [about managing backups from pre- and post-file-system-backup scrips] > > I agree with your point that it's not an uncommon thing to need. If a > good solution > > for it can be

Re: csv format for psql

2018-11-26 Thread Magnus Hagander
n Mon, Nov 26, 2018 at 5:53 AM Pavel Stehule wrote: > > > po 26. 11. 2018 v 5:36 odesílatel Andrew Gierth < > and...@tao11.riddles.org.uk> napsal: > >> > "Tom" == Tom Lane writes: >> >> Tom> Or we could kill both issues by hard-wiring the separator as ','. >> >> Using ';' for the delimiter

Re: Undo logs

2018-11-26 Thread Amit Kapila
On Tue, Nov 20, 2018 at 7:37 PM Dilip Kumar wrote: > Along with that I have merged latest changes in zheap branch committed > by Rafia Sabih for cleaning up the undo buffer information in abort > path. > Thanks, few more comments: 1. @@ -2627,6 +2653,7 @@ AbortTransaction(void)

Re: [HACKERS] Block level parallel vacuum

2018-11-26 Thread Masahiko Sawada
On Sun, Nov 25, 2018 at 2:35 PM Amit Kapila wrote: > > On Sat, Nov 24, 2018 at 5:47 PM Amit Kapila wrote: > > On Tue, Oct 30, 2018 at 2:04 PM Masahiko Sawada > > wrote: > > > > > Thank you for the comment. > > I could see that you have put a lot of effort on this patch and still > > we are

Re: inconsistency and inefficiency in setup_conversion()

2018-11-26 Thread John Naylor
v7 is a rebase over recent catalog changes. -John Naylor From 52aff43dcc91733c1b941fed4582d9c0602004d0 Mon Sep 17 00:00:00 2001 From: John Naylor Date: Sat, 13 Oct 2018 19:28:08 +0700 Subject: [PATCH v7 1/2] Add pg_language lookup. This didn't seem worth doing before, but an upcoming commit

Re: Add extension options to control TAP and isolation tests

2018-11-26 Thread Michael Paquier
On Mon, Nov 26, 2018 at 10:50:35AM +0300, Nikolay Shaplov wrote: > I see there PGXS mentioned several times as "a build infrastructure > for extensions" and as an environment variable it is mentioned only in > code sample As a variable PGXS stands for the location of the makefile which holds all

<    1   2