Re: Add extension options to control TAP and isolation tests

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 t

Re: inconsistency and inefficiency in setup_conversion()

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 will

Re: [HACKERS] Block level parallel vacuum

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 no

Re: Undo logs

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) AtEOXact_HashTa

Re: csv format for psql

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: Updated backup APIs for non-exclusive backups

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 propo

Re: allow online change primary_conninfo

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 possible

Re: Continue work on changes to recovery.conf API

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: WIP: Avoid creation of the free space map for small tables

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 mi

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

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: csv format for psql

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 pla

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

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: New function pg_stat_statements_reset_query() to reset statistics of a specific query

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 n

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

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, >> > >> > 1.

Re: Doc patch on psql output formats

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 > im

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

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 ar

RE: Global shared meta cache

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: pgsql: Integrate recovery.conf into postgresql.conf

Hi > The buildfarm is unhappy after this one: > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=culicidae&br=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 myse

Re: SQL/JSON: JSON_TABLE

> 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: SQL/JSON: functions

> 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 I/O

Re: A WalSnd issue related to state WALSNDSTATE_STOPPING

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. T

Re: COPY FROM WHEN condition

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 fan

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

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' >> recovery_tar

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

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 on

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

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 think

Re: COPY FROM WHEN condition

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 that

Re: Doc patch on psql output formats

"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: Updated backup APIs for non-exclusive backups

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 rig

Re: Updated backup APIs for non-exclusive backups

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 c

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

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 correctly

Re: csv format for psql

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 us

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

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 w

Re: Constraint documentation

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

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 propert

Re: csv format for psql

"David G. Johnston" writes: > On Sun, Nov 25, 2018 at 6:27 PM Tom Lane wrote: >> 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 useful. OK, reasona

Re: Covering GiST indexes

> On Mon, Jul 30, 2018 at 7:50 AM Andrey Borodin wrote: > > Thanks, Thomas! > > > 30 июля 2018 г., в 3:58, Thomas Munro > > написал(а): > > > > On Sun, Jul 29, 2018 at 10:50 PM, Andrey Borodin > > wrote: > >> Thanks! The problem appeared with commit 701fd0b [0] which dropped > >> validation ru

Re: Updated backup APIs for non-exclusive backups

Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Sun, 2018-11-25 at 16:04 -0500, Stephen Frost wrote: > > > Yes, you can come up with a post-backup script that somehow communicates > > > with your pre-backup script to get the information, but it sure is > > > inconvenient. Simplic

[PATCH] Improve tab completion for CREATE TABLE

Hi hackers, Please find attached a patch that adds the following tab completions for CREATE TABLE: - ( or PARTITION OF after the name - options after the column list - ON COMMIT actions for temp tables Regards, ilmari -- "The surreality of the universe tends towards a maximum" -- Skud's Law "N

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

Hello > I would think we'd have the different GUCs and then the check functions > would only validate that they're valid inputs and then when we get to > the point where we're starting to do recovery we check and make sure > we've been given a sane overall configuration- which means that only > *o

Re: B-tree cache prefetches

Hi, Thomas! > 31 авг. 2018 г., в 2:40, Thomas Munro > написал(а): > > [1] https://arxiv.org/pdf/1509.05053.pdf I've implemented all of the strategies used in that paper. On a B-tree page we have a line pointers ordered in key order and tuples residing at the end of the page. Tuples at the end

[PATCH] Tiny CREATE STATISTICS tab-completion cleanup

Hi Hackers, As I was hacking on the CREATE TABLE tab completions, I noticed that the CREATE STATISTICS completion was checking manually for the start and end of the parenthesised list instead of using the "(*)" wildcard (because it predates that functionality). Attached is a patch that updates it

Re: Covering GiST indexes

Hi, Dmitry! > 26 нояб. 2018 г., в 21:20, Dmitry Dolgov <9erthali...@gmail.com> написал(а): > > Looks like this time the patch was picked up correctly, but there are some > conflicts with the current master branch: > http://cfbot.cputube.org/patch_20_1615.log > Could you please rebase it one more

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

Hi Thomas, You said: I think we should respect the huge_pages GUC, as we do on Linux and Windows (since there are downsides to using large pages, maybe not everyone would want that). It could even be useful to allow different page sizes to be requested by GUC (I see that DB2 has an option to u

Re: Constraint documentation

Hi all, Thank you for helping us to make that patch better. It didn't > seem worth blocking this patch for your proposed change (particularly > since Lætitia seems to have given up on it already). > > I haven't given up. As I said in the begining, Patrick and I were working together on that patch

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

Greetings, * Sergei Kornilov (s...@zsrv.org) wrote: > > I would think we'd have the different GUCs and then the check functions > > would only validate that they're valid inputs and then when we get to > > the point where we're starting to do recovery we check and make sure > > we've been given a

Re: Handling of REGRESS_OPTS in MSVC for regression tests

On 11/26/18 12:43 AM, Michael Paquier wrote: Hi all, As mentioned on this thread, I have been fighting a bit with the buildfarm when trying to introduce new PGXS options for isolation and TAP tests: https://www.postgresql.org/message-id/e1gr4d0-0002yj...@gemulon.postgresql.org However it happ

Re: allow online change primary_conninfo

Hi, On 2018-11-26 12:30:06 +0300, Sergei Kornilov wrote: > Hmm... I considered SIGHUP processing was in fast loop and therefore shutdown > should be fast. But i recheck code and found a possible long loop without > processing SIGHUP (in case we receive new data faster than writes to disk). > Ok

Re: csv format for psql

Tom Lane wrote: > OK, reasonable arguments were made why not to allow multi-character > separators. Should we then match the server and insist on a single-byte > separator? It's a bit inconsistent if psql can be made to emit "csv" > files that COPY can't read, especially when it's otherw

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

On 2018-Nov-26, Stephen Frost wrote: > I would think we'd have the different GUCs and then the check functions > would only validate that they're valid inputs and then when we get to > the point where we're starting to do recovery we check and make sure > we've been given a sane overall configurat

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

On 2018-11-26 15:09:43 -0300, Alvaro Herrera wrote: > On 2018-Nov-26, Stephen Frost wrote: > > > I would think we'd have the different GUCs and then the check functions > > would only validate that they're valid inputs and then when we get to > > the point where we're starting to do recovery we ch

Re: allow online change primary_conninfo

Hi >>  Hmm... I considered SIGHUP processing was in fast loop and therefore >> shutdown should be fast. But i recheck code and found a possible long loop >> without processing SIGHUP (in case we receive new data faster than writes to >> disk). Ok, i will revert back. >>  How about write to WalR

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

Greetings, On Mon, Nov 26, 2018 at 13:15 Andres Freund wrote: > On 2018-11-26 15:09:43 -0300, Alvaro Herrera wrote: > > On 2018-Nov-26, Stephen Frost wrote: > > > > > I would think we'd have the different GUCs and then the check functions > > > would only validate that they're valid inputs and t

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

On 2018-11-26 13:30:18 -0500, Stephen Frost wrote: > Well, we could start with: that isn’t how things work today, nor how it > used to work before this patch, and we’ve not had anyone asking for it > except for people on this thread making things up. Thanks for assuming good faith.

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

Hello > I think I would have done 'if (targetSettingsCount != 1)' here. Streaming replication does not have any recovery_target. Well, i can check StandbyModeRequested too and allow 0 recovery_target only for standby mode. >>  -# Multiple targets >>  -# Last entry has priority (note that an arra

Re: Copy function for logical replication slots

Hi, On 26/11/2018 01:29, Masahiko Sawada wrote: > On Sun, Nov 25, 2018 at 12:27 AM Petr Jelinek > wrote: >> >> The more serious thing is: >> >>> + if (MyReplicationSlot) >>> + ReplicationSlotRelease(); >>> + >>> + /* Release the saved slot if exist while preventing double rele

Re: csv format for psql

I wrote: > A proposed fix is attached. print_csv_vertical() is left unchanged > because it's not possible currently to end up with \. alone > on a line with the expanded display On second thought, it is possible postgres=# \pset format csv Output format is csv. postgres=# \pset fieldsep

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

Greetings, * Sergei Kornilov (s...@zsrv.org) wrote: > > I think I would have done 'if (targetSettingsCount != 1)' here. > Streaming replication does not have any recovery_target. > Well, i can check StandbyModeRequested too and allow 0 recovery_target only > for standby mode. Ah. Agreed. > >>

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

On 11/26/18 1:15 PM, Andres Freund wrote: > On 2018-11-26 15:09:43 -0300, Alvaro Herrera wrote: >> On 2018-Nov-26, Stephen Frost wrote: >> >>> I would think we'd have the different GUCs and then the check functions >>> would only validate that they're valid inputs and then when we get to >>> the po

Re: Make foo=null a warning by default.

> On Tue, Aug 7, 2018 at 11:19 PM Bruce Momjian wrote: > > On Mon, Jul 16, 2018 at 11:37:28AM -0400, Tom Lane wrote: > > Heikki Linnakangas writes: > > > On 16/07/18 18:10, Tom Lane wrote: > > >> TBH I'm not really excited about investing any work in this area at all. > > >> Considering how seldo

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

Hello Updated patch attached: - added testcase to verify database does not start with multiple recovery targets - recovery_target = immediate was replaced with recovery_target_immediate bool GUC thank you! regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index db

Re: csv format for psql

"Daniel Verite" writes: >> A proposed fix is attached. print_csv_vertical() is left unchanged >> because it's not possible currently to end up with \. alone >> on a line with the expanded display > On second thought, it is possible > postgres=# \pset format csv > Output format is csv. > postgres=

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

Greetings, * Sergei Kornilov (s...@zsrv.org) wrote: > Updated patch attached: > - added testcase to verify database does not start with multiple recovery > targets > - recovery_target = immediate was replaced with recovery_target_immediate > bool GUC I'd encourage you to look through the diff a

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

Hi > I'd encourage you to look through the diff after you're finished hacking > before sending it to the list, in case things get left in that should be > removed, as below... I am so sorry. I have a look before sending, but... It's night in my timezone. I will fix tomorrow. >>  + if (targetSetti

Re: Inadequate executor locking of indexes

On Mon, 26 Nov 2018 at 18:57, Amit Langote wrote: > On 2018/11/26 14:25, David Rowley wrote: > > I'm making efforts to delay per-partition work even further in the > > executor, for example locking of the per-partition result relations > > until after run-time pruning would be a significant win fo

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

Greetings, * Sergei Kornilov (s...@zsrv.org) wrote: > > I'd encourage you to look through the diff after you're finished hacking > > before sending it to the list, in case things get left in that should be > > removed, as below... > I am so sorry. I have a look before sending, but... > It's night

IMMUTABLE and PARALLEL SAFE function markings

I have defined a function "is_not_distinct" for the purpose of creating a custom operator "===". CREATE FUNCTION is_not_distinct(a anyelement, b anyelement) returns boolean language sql as $$ select a is not distinct from b; $$ IMMUTABLE; CREATE OPERATOR === ( LEFTARG = anyelement, RIGHTARG

Re: csv format for psql

> > Pushed with that correction and some other last-minute review. > Great! Thank you Pavel > > regards, tom lane > >

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On Mon, Sep 3, 2018 at 11:17 AM Tomas Vondra wrote: > Attached is an updated version of the patch series, adopting a couple of > improvements - both for MCV lists and histograms. Hello Tomas, FYI, here are a couple of warnings from GCC (I just noticed because I turned on -Werror on cfbot so your

Re: Refactoring the checkpointer's fsync request queue

On Fri, Nov 23, 2018 at 5:45 PM Thomas Munro wrote: > I do have a new plan though... Ugh. The plan in my previous email doesn't work, I was confused about the timing of the buffer header update. Back to the drawing board. -- Thomas Munro http://www.enterprisedb.com

Re: [RFC] Removing "magic" oids

Hi, On 2018-11-22 17:12:31 -0500, Andrew Dunstan wrote: > > On 11/22/18 4:14 PM, Andres Freund wrote: > > Hi, > > > > On 2018-11-21 23:32:07 -0500, Andrew Dunstan wrote: > > > On 11/21/18 7:14 PM, Andres Freund wrote: > > > >Could you check whether you > > > > still encounter the issue after

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 11/26/18 11:29 PM, Thomas Munro wrote: > On Mon, Sep 3, 2018 at 11:17 AM Tomas Vondra > wrote: >> Attached is an updated version of the patch series, adopting a couple of >> improvements - both for MCV lists and histograms. > > Hello Tomas, > > FYI, here are a couple of warnings from GCC (I j

Re: pg_stat_ssl additions

On Thu, Oct 18, 2018 at 11:05 AM Peter Eisentraut wrote: > - Adds tests under src/test/ssl/ for the pg_stat_ssl view. Hi Peter, Your new tests fail when run by cfbot (Ubuntu), and also on my Debian buster machine, but pass on my FreeBSD 13-CURRENT box. I think the problem is that you match ciph

Re: [RFC] Removing "magic" oids

Hi, On 2018-11-21 16:30:07 +0100, Andreas Karlsson wrote: > On 11/21/18 1:07 AM, Andres Freund wrote: > > Let's see what I broke :/ > > There is a small typo in the old release notes. Thanks, pushed! Greetings, Andres Freund

Re: IMMUTABLE and PARALLEL SAFE function markings

On 26/11/2018 22:23, Gajus Kuizinas wrote: > I was wondering what is the reason IMMUTABLE functions are not by > default PARALLEL SAFE and if the default behaviour could be changed to > make IMMUTABLE functions PARALLEL SAFE? I think I have to concur with this. When is an immutable function not p

Re: IMMUTABLE and PARALLEL SAFE function markings

Hi, On 2018-11-27 00:33:10 +0100, Vik Fearing wrote: > On 26/11/2018 22:23, Gajus Kuizinas wrote: > > I was wondering what is the reason IMMUTABLE functions are not by > > default PARALLEL SAFE and if the default behaviour could be changed to > > make IMMUTABLE functions PARALLEL SAFE? > > I thin

pg_config wrongly marked as not parallel safe?

Hi, Triggered by the thread at [1] I looked for functions marked as immutable but not parallel safe. postgres[19492][1]=# SELECT oid::regprocedure, provolatile, proparallel FROM pg_proc WHERE provolatile = 'i' AND proparallel != 's'; ┌─┬─┬─┐ │ oid │ pr

Re: IMMUTABLE and PARALLEL SAFE function markings

On 27/11/2018 00:39, Andres Freund wrote: > Hi, > > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote: >> On 26/11/2018 22:23, Gajus Kuizinas wrote: >>> I was wondering what is the reason IMMUTABLE functions are not by >>> default PARALLEL SAFE and if the default behaviour could be changed to >>> ma

Re: IMMUTABLE and PARALLEL SAFE function markings

On 2018-11-27 00:47:47 +0100, Vik Fearing wrote: > On 27/11/2018 00:39, Andres Freund wrote: > > Hi, > > > > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote: > >> On 26/11/2018 22:23, Gajus Kuizinas wrote: > >>> I was wondering what is the reason IMMUTABLE functions are not by > >>> default PARALL

Re: [PATCH] Tiny CREATE STATISTICS tab-completion cleanup

Hi, On 11/26/18 5:49 PM, Dagfinn Ilmari Mannsåker wrote: > Hi Hackers, > > As I was hacking on the CREATE TABLE tab completions, I noticed that the > CREATE STATISTICS completion was checking manually for the start and end > of the parenthesised list instead of using the "(*)" wildcard (because >

Re: pg_config wrongly marked as not parallel safe?

On 11/26/18 6:45 PM, Andres Freund wrote: > Hi, > > Triggered by the thread at [1] I looked for functions marked as > immutable but not parallel safe. > > postgres[19492][1]=# SELECT oid::regprocedure, provolatile, proparallel FROM > pg_proc WHERE provolatile = 'i' AND proparallel != 's'; > ┌───

Re: IMMUTABLE and PARALLEL SAFE function markings

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-27 00:47:47 +0100, Vik Fearing wrote: > > On 27/11/2018 00:39, Andres Freund wrote: > > > On 2018-11-27 00:33:10 +0100, Vik Fearing wrote: > > >> On 26/11/2018 22:23, Gajus Kuizinas wrote: > > >>> I was wondering what is the reaso

Re: pg_config wrongly marked as not parallel safe?

On 2018-11-26 19:04:46 -0500, Joe Conway wrote: > On 11/26/18 6:45 PM, Andres Freund wrote: > > Hi, > > > > Triggered by the thread at [1] I looked for functions marked as > > immutable but not parallel safe. > > > > postgres[19492][1]=# SELECT oid::regprocedure, provolatile, proparallel > > FRO

Re: IMMUTABLE and PARALLEL SAFE function markings

On 27/11/2018 01:05, Stephen Frost wrote: > That said, I do *not* think we should make any assumptions here- users > incorrectly mark things all the time but we shouldn't encourage that and > we shouldn't assume that functions marked as immutable are parallel > safe. Does that mean we also shouldn

Re: IMMUTABLE and PARALLEL SAFE function markings

Hi, On 2018-11-26 19:05:02 -0500, Stephen Frost wrote: > Agreed, but I could see us having a regression test which complains if > it finds any which are marked as immutable but aren't parallel safe. That doesn't help if a user writes a query to review the not parallel safe functions in their inst

Re: IMMUTABLE and PARALLEL SAFE function markings

Greetings, * Vik Fearing (vik.fear...@2ndquadrant.com) wrote: > On 27/11/2018 01:05, Stephen Frost wrote: > > That said, I do *not* think we should make any assumptions here- users > > incorrectly mark things all the time but we shouldn't encourage that and > > we shouldn't assume that functions m

Re: IMMUTABLE and PARALLEL SAFE function markings

On 27/11/2018 01:10, Stephen Frost wrote: > Greetings, > > * Vik Fearing (vik.fear...@2ndquadrant.com) wrote: >> On 27/11/2018 01:05, Stephen Frost wrote: >>> That said, I do *not* think we should make any assumptions here- users >>> incorrectly mark things all the time but we shouldn't encourage

Re: IMMUTABLE and PARALLEL SAFE function markings

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-26 19:05:02 -0500, Stephen Frost wrote: > > Agreed, but I could see us having a regression test which complains if > > it finds any which are marked as immutable but aren't parallel safe. > > That doesn't help if a user writes a

Re: pg_config wrongly marked as not parallel safe?

On 11/26/18 7:08 PM, Andres Freund wrote: > On 2018-11-26 19:04:46 -0500, Joe Conway wrote: >> Not intentional. Though, sitting here chatting with Stephen about it, I >> am now wondering if pg_config() should actually be marked immutable: >> >> select * from pg_config() where name = 'VERSION'; >>

Re: IMMUTABLE and PARALLEL SAFE function markings

Greetings, * Vik Fearing (vik.fear...@2ndquadrant.com) wrote: > On 27/11/2018 01:10, Stephen Frost wrote: > > * Vik Fearing (vik.fear...@2ndquadrant.com) wrote: > >> On 27/11/2018 01:05, Stephen Frost wrote: > >>> That said, I do *not* think we should make any assumptions here- users > >>> incorre

Re: pg_config wrongly marked as not parallel safe?

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-26 19:04:46 -0500, Joe Conway wrote: > > So the correct answer is probably to mark pg_config() stable, but it > > still seems to be parallel safe to me. > > I don't think we should consider immutability to mean anything across >

Re: IMMUTABLE and PARALLEL SAFE function markings

On 2018-11-26 19:13:17 -0500, Stephen Frost wrote: > Greetings, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2018-11-26 19:05:02 -0500, Stephen Frost wrote: > > > Agreed, but I could see us having a regression test which complains if > > > it finds any which are marked as immutable but a

Re: pg_config wrongly marked as not parallel safe?

On 2018-11-26 19:14:24 -0500, Joe Conway wrote: > On 11/26/18 7:08 PM, Andres Freund wrote: > > On 2018-11-26 19:04:46 -0500, Joe Conway wrote: > >> Not intentional. Though, sitting here chatting with Stephen about it, I > >> am now wondering if pg_config() should actually be marked immutable: > >>

Re: pg_config wrongly marked as not parallel safe?

Hi, On 2018-11-26 19:16:00 -0500, Stephen Frost wrote: > Greetings, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2018-11-26 19:04:46 -0500, Joe Conway wrote: > > > So the correct answer is probably to mark pg_config() stable, but it > > > still seems to be parallel safe to me. > > > >

Re: IMMUTABLE and PARALLEL SAFE function markings

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-26 19:13:17 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On 2018-11-26 19:05:02 -0500, Stephen Frost wrote: > > > > Agreed, but I could see us having a regression test which complains if > > >

Re: IMMUTABLE and PARALLEL SAFE function markings

On 27/11/2018 01:14, Stephen Frost wrote: > Greetings, > > * Vik Fearing (vik.fear...@2ndquadrant.com) wrote: >> On 27/11/2018 01:10, Stephen Frost wrote: >>> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote: On 27/11/2018 01:05, Stephen Frost wrote: > That said, I do *not* think we shou

Re: IMMUTABLE and PARALLEL SAFE function markings

On 27/11/2018 01:13, Stephen Frost wrote: > Parallel safe functions should be marked as such. Immutable functions > should be marked as such. We should not assume that one implies the > other, nor should we operate as if they do. Yes we should! Unless you can produce a case where an immutable f

Re: IMMUTABLE and PARALLEL SAFE function markings

Hi, On 2018-11-27 01:27:41 +0100, Vik Fearing wrote: > On 27/11/2018 01:13, Stephen Frost wrote: > > Parallel safe functions should be marked as such. Immutable functions > > should be marked as such. We should not assume that one implies the > > other, nor should we operate as if they do. > >

Re: pg_config wrongly marked as not parallel safe?

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-26 19:16:00 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On 2018-11-26 19:04:46 -0500, Joe Conway wrote: > > > > So the correct answer is probably to mark pg_config() stable, but it > > > > sti

Re: IMMUTABLE and PARALLEL SAFE function markings

FWIW, I'm inclined to think that pg_config should be marked as stable not immutable. Aside from the minor-version-upgrade issue, what if you install new binaries that are the same version but built with different configure flags? The pg_config outputs are roughly as stable as initdb-inserted cata

Re: IMMUTABLE and PARALLEL SAFE function markings

Greetings, * Vik Fearing (vik.fear...@2ndquadrant.com) wrote: > On 27/11/2018 01:13, Stephen Frost wrote: > > Parallel safe functions should be marked as such. Immutable functions > > should be marked as such. We should not assume that one implies the > > other, nor should we operate as if they

  1   2   >