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

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

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)

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

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

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

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

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

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: 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: 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: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: 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, * 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

Re: reg* checks in pg_upgrade are out of date

On 2018-11-22 08:49:23 -0500, Andrew Dunstan wrote: > > On 11/21/18 7:12 PM, Andres Freund wrote: > > Hi, > > > > It seems the list of reg* types and the check for them in pg_upgrade > > have gone out of sync. We have the following reg* types: > > > > SELECT typname FROM pg_type WHERE typname

Re: pg11.1 jit segv

On 2018-11-17 17:37:15 -0600, Justin Pryzby wrote: > On Fri, Nov 16, 2018 at 10:24:46AM -0600, Justin Pryzby wrote: > > On Fri, Nov 16, 2018 at 08:38:26AM -0600, Justin Pryzby wrote: > > > The table is not too special, but was probably ALTERed to add columns a > > > good > > > number of times by

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

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

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

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

Re: IMMUTABLE and PARALLEL SAFE function markings

Vik Fearing writes: > 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

Re: pg_config wrongly marked as not parallel safe?

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-26 19:34:03 -0500, Stephen Frost wrote: > > These two things seem entirely independent in my view, so I'm really not > > sure that I'm following what you're getting at. > > All I said is that I don't think it's a reasonable

Re: IMMUTABLE and PARALLEL SAFE function markings

I'm a bit more concerned by the fact that inlining the function isn't affecting the parallel safety of the query - the fact that parallel safety is being checked prior to inlining means that if inlining *introduces* a parallel hazard, it will go unnoticed? -- Andrew (irc:RhodiumToad)

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

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

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

Re: Pluggable Storage - Andres's take

Hi, FWIW, now that oids are removed, and the tuple table slot abstraction got in, I'm working on rebasing the pluggable storage patchset ontop of that. On 2018-11-27 12:48:36 +1100, Haribabu Kommi wrote: > On Thu, Nov 22, 2018 at 1:12 PM Asim R P wrote: > > > Ashwin (copied) and I got a

Re: A WalSnd issue related to state WALSNDSTATE_STOPPING

On Tue, Nov 27, 2018 at 10:07:04AM +0800, Paul Guo wrote: > Agree. Your code change is safer. Thanks Paul for double-checking. I'll come back to this patch in two days, look at it again and commit it if there are no objections from others. -- Michael signature.asc Description: PGP signature

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

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

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

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

Re: pg_config wrongly marked as not parallel safe?

On 2018-11-26 19:34:03 -0500, Stephen Frost wrote: > These two things seem entirely independent in my view, so I'm really not > sure that I'm following what you're getting at. All I said is that I don't think it's a reasonable policy to mark all functions that potentially could change across

Re: IMMUTABLE and PARALLEL SAFE function markings

On 27/11/2018 01:40, Tom Lane wrote: > Vik Fearing writes: >> 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

Re: Pluggable Storage - Andres's take

On Thu, Nov 22, 2018 at 1:12 PM Asim R P wrote: > Ashwin (copied) and I got a chance to go through the latest code from > Andres' github repository. We would like to share some > comments/quesitons: > Thanks for the review. > The TupleTableSlot argument is well suited for row-oriented

Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS)

On Fri, Nov 23, 2018 at 6:39 PM Thomas Munro wrote: > On Mon, Nov 19, 2018 at 5:24 PM Kyotaro HORIGUCHI > wrote: > > At Sat, 17 Nov 2018 11:15:54 -0300, Alvaro Herrera < > alvhe...@2ndquadrant.com> wrote in > <20181117141554.4dkx2u4j6md3bqdh@alvherre.pgsql> > > > Is this patch committable now?

Re: [HACKERS] Block level parallel vacuum

On Mon, Nov 26, 2018 at 2:08 PM Masahiko Sawada wrote: > > 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

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

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: 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: 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: Handling of REGRESS_OPTS in MSVC for regression tests

On Mon, Nov 26, 2018 at 12:41:21PM -0500, Andrew Dunstan wrote: > It's not the buildfarm that is broken. Both contribcheck() and > modulescheck() in vcregress.pl run in installcheck mode, i.e. with an > already running database. That makes the tests run faster, because setting > up and breaking

Re: dsa_allocate() faliure

On Tue, Nov 27, 2018 at 7:45 AM Alvaro Herrera wrote: > On 2018-Nov-26, Jakub Glapa wrote: > > Justin thanks for the information! > > I'm running Ubuntu 16.04. > > I'll try to prepare for the next crash. > > Couldn't find anything this time. > > As I recall, the appport stuff in Ubuntu is

Remove Deprecated Exclusive Backup Mode

Hackers, I propose we remove the deprecated exclusive backup mode of pg_start_backup()/pg_stop_backup() for Postgres 12. The exclusive backup mode has a serious known issue. If Postgres terminates ungracefully during a backup (due to hardware, kernel, Postgres issues, etc.) then Postgres

Re: Remove Deprecated Exclusive Backup Mode

On Mon, Nov 26, 2018 at 10:13:34PM -0500, David Steele wrote: > Non-exclusive backups have been available since 9.6 and several third-party > solutions support this mode, in addition to pg_basebackup. I think that two releases is not actually that much time to just nuke the exclusive backup

Re: Remove Deprecated Exclusive Backup Mode

Hi, On 2018-11-27 12:20:13 +0900, Michael Paquier wrote: > On Mon, Nov 26, 2018 at 10:13:34PM -0500, David Steele wrote: > > Non-exclusive backups have been available since 9.6 and several third-party > > solutions support this mode, in addition to pg_basebackup. > > I think that two releases is

Re: IMMUTABLE and PARALLEL SAFE function markings

On Mon, Nov 26, 2018 at 7:47 PM Vik Fearing wrote: > > I'm way less inclined to buy into the idea that it MUST be wrong, though. > > Immutability is a promise about result stability and lack of side effects, > > but it is not a promise about implementation details. There could be an > >

Re: IMMUTABLE and PARALLEL SAFE function markings

On Mon, Nov 26, 2018 at 8:49 PM Andrew Gierth wrote: > I'm a bit more concerned by the fact that inlining the function isn't > affecting the parallel safety of the query - the fact that parallel > safety is being checked prior to inlining means that if inlining > *introduces* a parallel hazard,

Re: Remove Deprecated Exclusive Backup Mode

On Mon, Nov 26, 2018 at 10:13 PM David Steele wrote: > I propose we remove the deprecated exclusive backup mode of > pg_start_backup()/pg_stop_backup() for Postgres 12. -1. I don't have a problem with deprecating exclusive backup mode eventually, but I don't see any good reason to do it this

Re: IMMUTABLE and PARALLEL SAFE function markings

> "Robert" == Robert Haas writes: >> I'm a bit more concerned by the fact that inlining the function >> isn't affecting the parallel safety of the query - the fact that >> parallel safety is being checked prior to inlining means that if >> inlining *introduces* a parallel hazard, it will

Re: IMMUTABLE and PARALLEL SAFE function markings

On Mon, Nov 26, 2018 at 11:20 PM Andrew Gierth wrote: > But the combination of inlining and polymorphism, in particular, makes > it impossible for the function author to know this. Take the OP's > example; it is parallel safe if and only if the selected type's equal > function is parallel safe -

Re: Inadequate executor locking of indexes

On 2018/11/27 6:19, David Rowley wrote: > 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

vacuum and autovacuum - is it good to configure the threshold at TABLE LEVEL?

Hi, Please suggest me on the following, 1. Is it better to configure autovacuum threshold at table level? 2. Is there any discussions in this forum which I can refer for understanding vacuum/autovacuum? Thanks in advance. Rajan. - -- Thanks, Rajan. -- Sent from:

Re: IMMUTABLE and PARALLEL SAFE function markings

Robert Haas writes: > On Mon, Nov 26, 2018 at 11:21 PM Tom Lane wrote: >> Alternatively, could we postpone the parallelism checks till after >> function inlining? Do we even make any before that? > ... I believe the parallel-safety checks are done very early, and if > you decide that it's not

Re: IMMUTABLE and PARALLEL SAFE function markings

On Mon, Nov 26, 2018 at 11:21 PM Tom Lane wrote: > Hm. We intentionally allow SQL functions to be marked as less mutable > than their internals, because sometimes that's useful for tricking > the planner. However, IIRC we don't inline when we see that's the > case. Maybe there needs to be a

Re: IMMUTABLE and PARALLEL SAFE function markings

> "Tom" == Tom Lane writes: Tom> Hm. We intentionally allow SQL functions to be marked as less Tom> mutable than their internals, because sometimes that's useful for Tom> tricking the planner. However, IIRC we don't inline when we see Tom> that's the case. Maybe there needs to be a

Re: pg11.1 jit segv

On Mon, Nov 26, 2018 at 07:00:35PM -0800, Andres Freund wrote: > Could you check that the attached patch this also fixes your original > issue? Going through the code to see if there's other occurances of > this. Confirmed that fixes my crash. Thanks, Justin

Re: IMMUTABLE and PARALLEL SAFE function markings

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> Hm. We intentionally allow SQL functions to be marked as less > Tom> mutable than their internals, because sometimes that's useful for > Tom> tricking the planner. However, IIRC we don't inline when we see > Tom> that's the case. Maybe

Re: pg_config wrongly marked as not parallel safe?

On Mon, 2018-11-26 at 19:51 -0500, Stephen Frost wrote: > If a function's results can change across minor or major versions, we > shouldn't be marking it as immutable because, by definition, it's not > immutable. > > We, today, have a baked in assumption that any function marked as > immutable

Re: Pluggable Storage - Andres's take

Hi, On 2018/11/02 9:17, Haribabu Kommi wrote: > Here I attached the cumulative fixes of the patches, new API additions for > zheap and > basic outline of the documentation. I've read the documentation patch while also looking at the code and here are some comments. + Each table is stored as

RE: libpq debug log

Hi, I created a new version patch. Please find attached my patch. Changes: Since v2 patch I forgot to write the detail of v2 patch changes. So I write these. - Fixed the " Start receiving message from backend:" message location. Because I found that message located at outside of "retry4". -

Re: IMMUTABLE and PARALLEL SAFE function markings

Robert Haas writes: > On Mon, Nov 26, 2018 at 8:49 PM Andrew Gierth > wrote: >> I'm a bit more concerned by the fact that inlining the function isn't >> affecting the parallel safety of the query - the fact that parallel >> safety is being checked prior to inlining means that if inlining >>

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

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

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

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

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

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

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

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=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: 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

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

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

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

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

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.

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 >

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

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,

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

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

[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

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

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

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

[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

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

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

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

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

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

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

  1   2   >