Re: Proposal to suppress errors thrown by to_reg*()

Hello. At Thu, 14 Mar 2019 13:37:00 +0900, Takuma Hoshiai wrote in <20190314133700.c271429ddc00ddab3aac2...@sraoss.co.jp> > Hi, hackers, > > According to the document, "to_reg* functions return null rather than > throwing an error if the name is not found", but this is not the case > if the arg

RE: Problem with default partition pruning

Hi Amit-san, From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] Sent: Monday, March 18, 2019 6:44 PM > Hosoya-san, > > On 2019/03/15 15:05, Yuzuko Hosoya wrote: > > Indeed, it's problematic. I also did test and I found that this > > problem was occurred when any partition didn't match W

Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method

On Mon, Mar 18, 2019 at 10:41:13PM +0300, Nikolay Shaplov wrote: > So I created src/test/modules/dummy_index, it does no real indexing, but it > has all types of reloptions that can be set (reloption_int, reloption_real, > reloption_bool, reloption_string and reloption_string2). It also has set o

Re: pg_basebackup ignores the existing data directory permissions

On Tue, Mar 19, 2019 at 5:29 PM Michael Paquier wrote: > On Mon, Mar 18, 2019 at 11:45:05AM -0400, Robert Haas wrote: > > So you want to default to no group access regardless of the directory > > permissions, with an option to enable group access that must be > > explicitly specified? That seems

Re: Proposal to suppress errors thrown by to_reg*()

>> According to the document, "to_reg* functions return null rather than >> throwing an error if the name is not found", but this is not the case >> if the arguments to those functions are schema qualified and the >> caller does not have access permission of the schema even if the table >> (or othe

RE: Transaction commits VS Transaction commits (with parallel) VS query mean time

Hi Hari-san, On Sunday, February 10, 2019 2:25 PM (GMT+9), Haribabu Kommi wrote: > I try to fix it by adding a check for parallel worker or not and based on it > count them into stats. Patch attached. > > With this patch, currently it doesn't count parallel worker transactions, and > rest of the s

Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

On Tue, Mar 19, 2019 at 2:32 PM Rahila Syed wrote: > Hi Haribabu, > > The latest patch fails while applying header files part. Kindly rebase. > Thanks for the review. > The patch looks good to me. However, I wonder what are the other scenarios > where xact_commit is incremented because even if

Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

On Tue, Mar 19, 2019 at 6:47 PM Jamison, Kirk wrote: > Hi Hari-san, > > > > On Sunday, February 10, 2019 2:25 PM (GMT+9), Haribabu Kommi wrote: > > > I try to fix it by adding a check for parallel worker or not and based > on it > > > count them into stats. Patch attached. > > > > > > With this p

RE: Speed up transaction completion faster after many relations are accessed in a transaction

Hi Peter, Imai-san, From: Peter Eisentraut [mailto:peter.eisentr...@2ndquadrant.com] > Your changes in LOCALLOCK still refer to PGPROC, from your first version > of the patch. > > I think the reordering of struct members could be done as a separate > preliminary patch. > > Some more documentatio

Re: [HACKERS] Block level parallel vacuum

At Tue, 19 Mar 2019 13:31:04 +0900, Masahiko Sawada wrote in > > For indexes=4,8,16, the cases with parallel_degree=4,8,16 behave > > almost the same. I suspect that the indexes are too-small and all > > the index pages were on memory and CPU is saturated. Maybe you > > had four cores and parall

Re: DNS SRV support for LDAP authentication

On Sat, Feb 16, 2019 at 10:57 PM Thomas Munro wrote: > Yeah. This coding is ugly and StringInfo would be much nicer. > Thinking about that made me realise that the proposed SRV case should > also handle multiple SRV records by building a multi-URL string too > (instead of just taking the first on

Willing to fix a PQexec() in libpq module

Hi,all On website: https://wiki.postgresql.org/wiki/Todo#libpq I found that in libpq module,there is a TODO case: --- Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks ---

Re: Proposal to suppress errors thrown by to_reg*()

At Tue, 19 Mar 2019 16:35:32 +0900 (JST), Tatsuo Ishii wrote in <20190319.163532.529526338176696856.t-is...@sraoss.co.jp> > >> According to the document, "to_reg* functions return null rather than > >> throwing an error if the name is not found", but this is not the case > >> if the arguments to

Re: Proposal to suppress errors thrown by to_reg*()

>> You misunderstand the functionality of to_regclass(). Even if a user >> does not have an access privilege of certain table, to_regclass() does >> not raise an error. >> >> test=> select * from t1; >> ERROR: permission denied for table t1 >> >> test=> select to_regclass('t1')::oid; >> to_regcl

Re: [HACKERS] Block level parallel vacuum

On Tue, Mar 19, 2019 at 10:39 AM Haribabu Kommi wrote: > > > On Mon, Mar 18, 2019 at 1:58 PM Masahiko Sawada wrote: >> >> On Tue, Feb 26, 2019 at 7:20 PM Masahiko Sawada >> wrote: >> > >> > On Tue, Feb 26, 2019 at 1:35 PM Haribabu Kommi >> > wrote: >> > > >> > > On Thu, Feb 14, 2019 at 9:17 P

RE: Speed up transaction completion faster after many relations are accessed in a transaction

Hi Tsunakawa-san, Peter On Tue, Mar 19, 2019 at 7:53 AM, Tsunakawa, Takayuki wrote: > From: Peter Eisentraut [mailto:peter.eisentr...@2ndquadrant.com] > > You posted a link to some performance numbers, but I didn't see the > > test setup explained there. I'd like to get some more information on >

RE: Speed up transaction completion faster after many relations are accessed in a transaction

From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com] > Fixed. Rebased on HEAD. Regards Takayuki Tsunakawa 0001-reorder-LOCALLOCK-structure-members-to-compact-the-s.patch Description: 0001-reorder-LOCALLOCK-structure-members-to-compact-the-s.patch 0002-speed-up-LOCALLOCK-scan.pa

Re: jsonpath

On Sun, Feb 24, 2019 at 5:03 PM Alexander Korotkov wrote: > On Wed, Jan 30, 2019 at 5:28 AM Andres Freund wrote: > > Why -CF, and why is -p repeated? > > BTW, for our SQL grammar we have > > > scan.c: FLEXFLAGS = -CF -p -p > > Is it kind of default? I just saw this in the committed patch. This i

Re: partitioned tables referenced by FKs

Hi, Thanks for updating the patch. I'll reply to other parts separately. On 2019/03/19 7:02, Alvaro Herrera wrote: > A pretty silly bug remains here. Watch: > > create table pk (a int primary key) partition by list (a); > create table pk1 partition of pk for values in (1); > create table fk (a

Re: [HACKERS] Custom compression methods

On Mon, Mar 18, 2019 at 11:09 PM Tomas Vondra wrote: > > > On 3/15/19 12:52 PM, Ildus Kurbangaliev wrote: > > On Fri, 15 Mar 2019 14:07:14 +0400 > > David Steele wrote: > > > >> On 3/7/19 11:50 AM, Alexander Korotkov wrote: > >>> On Thu, Mar 7, 2019 at 10:43 AM David Steele >>>

Re: [HACKERS] CLUSTER command progress monitor

At Tue, 19 Mar 2019 11:02:57 +0900, Tatsuro Yamada wrote in > On 2019/03/19 10:43, Tatsuro Yamada wrote: > > Hi Rafia! > > On 2019/03/18 20:42, Rafia Sabih wrote: > >> On Fri, 8 Mar 2019 at 09:14, Tatsuro Yamada > >> wrote: > >>> Attached file is rebased patch on current HEAD. > >>> I changed

Re: [HACKERS] Block level parallel vacuum

On Tue, Mar 19, 2019 at 4:59 PM Kyotaro HORIGUCHI wrote: > > At Tue, 19 Mar 2019 13:31:04 +0900, Masahiko Sawada > wrote in > > > For indexes=4,8,16, the cases with parallel_degree=4,8,16 behave > > > almost the same. I suspect that the indexes are too-small and all > > > the index pages were o

Re: Proposal to suppress errors thrown by to_reg*()

At Tue, 19 Mar 2019 17:54:01 +0900 (JST), Tatsuo Ishii wrote in <20190319.175401.646838939186238443.t-is...@sraoss.co.jp> > > It seems to be a different thing. The oid 1647239 would be a > > table in public schema or any schema that the user has access > > to. If search_path contained only unpriv

Re: [HACKERS] Block level parallel vacuum

At Tue, 19 Mar 2019 19:01:06 +0900, Masahiko Sawada wrote in > On Tue, Mar 19, 2019 at 4:59 PM Kyotaro HORIGUCHI > wrote: > > > > At Tue, 19 Mar 2019 13:31:04 +0900, Masahiko Sawada > > wrote in > > > > > > For indexes=4,8,16, the cases with parallel_degree=4,8,16 behave > > > > almost the

Re: [HACKERS] Block level parallel vacuum

At Tue, 19 Mar 2019 17:51:32 +0900, Masahiko Sawada wrote in > On Tue, Mar 19, 2019 at 10:39 AM Haribabu Kommi > wrote: > > The performance results are good. Do we want to add the recommended > > size in the document for the parallel option? the parallel option for > > smaller > > tables can l

Re: ALTER TABLE on system catalogs

On 2019-02-08 04:04, Kyotaro HORIGUCHI wrote: > Hi, I got redirected here by a kind suggestion by Tom. I have committed my patch, which also addresses the issue you had in your other thread. I rest of these discussions have merit but are not really dependent on my patch. -- Peter Eisentraut

Re: jsonpath

On Mon, Mar 18, 2019 at 11:23 PM Tom Lane wrote: > Alexander Korotkov writes: > > On Mon, Mar 18, 2019 at 10:08 PM Tom Lane wrote: > >> Just another minor bitch about this patch: jsonpath_scan.l has introduced > >> a typedef called "keyword". This is causing pgindent to produce seriously > >> u

Re: jsonpath

On Tue, Mar 19, 2019 at 12:23 PM John Naylor wrote: > On Sun, Feb 24, 2019 at 5:03 PM Alexander Korotkov > wrote: > > On Wed, Jan 30, 2019 at 5:28 AM Andres Freund wrote: > > > Why -CF, and why is -p repeated? > > > > BTW, for our SQL grammar we have > > > > > scan.c: FLEXFLAGS = -CF -p -p > > >

Re: Willing to fix a PQexec() in libpq module

Hello. At Tue, 19 Mar 2019 08:18:23 +, "Wu, Fei" wrote in <52E6E0843B9D774C8C73D6CF64402F05621F0FFC@G08CNEXMBPEKD02.g08.fujitsu.local> > Hi,all > > On website: https://wiki.postgresql.org/wiki/Todo#libpq > I found that in libpq module,there is a TODO case: >

Re: extensions are hitting the ceiling

Hi all! We are also facing some issues when using extensions. We are using them quite intensively as a tool for maintaining our custom "DB applications" with versioning, all tables, data, regression tests... We find extensions great! We do not need other tool like flyway. My colleague already post

Re: Offline enabling/disabling of data checksums

Bonjour Michaël, Please find attached an updated patch set, I have rebased that stuff on top of my recent commits to refactor the control file updates. Patch applies cleanly, compiles, make check-world seems ok, doc build ok. It would help if the patch includes a version number. I assume tha

Contribution to Perldoc for TestLib module in Postgres

Hi Hackers, I was going through the regression testing framework used in postgres. I was trying to understand the custom functions written in perl for postgres. I could not find the perldoc for TestLib module in src/test/perl and found some difficultly in understanding what each function does whi

Re: unconstify equivalent for volatile

On 2019-02-18 16:42, Andres Freund wrote: > On February 18, 2019 7:39:25 AM PST, Peter Eisentraut > wrote: >> I propose to add an equivalent to unconstify() for volatile. When >> working on this, I picked the name unvolatize() mostly as a joke, but >> it >> appears it's a real word. Other ideas

Re: ALTER TABLE on system catalogs

Sorry overlooked this. At Thu, 14 Feb 2019 16:35:45 +0100, Peter Eisentraut wrote in <84c6bcc4-026f-a44f-5726-e8035f4d1...@2ndquadrant.com> > On 08/02/2019 04:04, Kyotaro HORIGUCHI wrote: > > By the way, I'm confused to see that attributes that don't want > > to go external are marked as 'x' in

RE: speeding up planning with partitions

Amit-san, On Tue, Mar 19, 2019 at 6:53 AM, Amit Langote wrote: > On 2019/03/15 9:33, Imai, Yoshikazu wrote: > > On Thu, Mar 14, 2019 at 9:04 AM, Amit Langote wrote: > >>> * In inheritance_planner(), we do ChangeVarNodes() only for > >>> orig_rtable, > >> so the codes concatenating lists of append_

Re: [HACKERS] Custom compression methods

On 3/19/19 10:59 AM, Chris Travers wrote: > > > On Mon, Mar 18, 2019 at 11:09 PM Tomas Vondra > mailto:tomas.von...@2ndquadrant.com>> wrote: > > > > On 3/15/19 12:52 PM, Ildus Kurbangaliev wrote: > > On Fri, 15 Mar 2019 14:07:14 +0400 > > David Steele mailto:da...@pgmasters.net>>

Re: [HACKERS] Block level parallel vacuum

On Tue, Mar 19, 2019 at 7:15 PM Kyotaro HORIGUCHI wrote: > > At Tue, 19 Mar 2019 19:01:06 +0900, Masahiko Sawada > wrote in > > On Tue, Mar 19, 2019 at 4:59 PM Kyotaro HORIGUCHI > > wrote: > > > > > > At Tue, 19 Mar 2019 13:31:04 +0900, Masahiko Sawada > > > wrote in > > > > > > > > For in

Re: Compressed TOAST Slicing

Greetings, * Paul Ramsey (pram...@cleverelephant.ca) wrote: > > On Mar 18, 2019, at 7:34 AM, Robert Haas wrote: > > +1. I think Paul had it right originally. > > In that spirit, here is a “one pglz_decompress function, new parameter” > version for commit. Alright, I've been working through th

Re: partitioned tables referenced by FKs

On 2019-Mar-19, Amit Langote wrote: > Will it suffice or be OK if we skipped invoking the pre-drop callback for > objects that are being "indirectly" dropped? I came up with the attached > patch to resolve this problem, if that idea has any merit. We also get > slightly better error message as s

Re: Contribution to Perldoc for TestLib module in Postgres

On 2019-Mar-19, Prajwal A V wrote: > I could not find the perldoc for TestLib module in src/test/perl and found > some difficultly in understanding what each function does while other > modules in the src/test folder had perldoc and it was easy to understand > the functions. > > I would like to c

Re: partitioned tables referenced by FKs

On Tue, Mar 19, 2019 at 8:49 PM Alvaro Herrera wrote: > On 2019-Mar-19, Amit Langote wrote: > > > Will it suffice or be OK if we skipped invoking the pre-drop callback for > > objects that are being "indirectly" dropped? I came up with the attached > > patch to resolve this problem, if that idea

Re: partitioned tables referenced by FKs

On 2019-Mar-19, Amit Langote wrote: > On Tue, Mar 19, 2019 at 8:49 PM Alvaro Herrera > wrote: > > On 2019-Mar-19, Amit Langote wrote: > > > > > Will it suffice or be OK if we skipped invoking the pre-drop callback for > > > objects that are being "indirectly" dropped? I came up with the attache

Re: Offline enabling/disabling of data checksums

On Tue, Mar 19, 2019 at 11:48:25AM +0100, Fabien COELHO wrote: > Moving the controlfile looks like an effective way to prevent any concurrent > start, as the fs operation is probably atomic and especially if external > tools uses the same trick. However this is not the case yet, eg > "pg_resetwal"

Re: Contribution to Perldoc for TestLib module in Postgres

On Tue, Mar 19, 2019 at 09:05:29AM -0300, Alvaro Herrera wrote: > Yes, it is, please do. +1. -- Michael signature.asc Description: PGP signature

Re: Fwd: Add tablespace tap test to pg_rewind

On Tue, Mar 12, 2019 at 10:27 AM Michael Paquier wrote: > On Mon, Mar 11, 2019 at 07:49:11PM +0800, Shaoqi Bai wrote: > > Thanks, will work on it as you suggested > > Add pg_basebackup --T olddir=newdir to support check the consistency of a > > tablespace created before promotion > > Add run_test

Re: Offline enabling/disabling of data checksums

Hi, Am Dienstag, den 19.03.2019, 11:48 +0100 schrieb Fabien COELHO: > Moving the controlfile looks like an effective way to prevent any > concurrent start, as the fs operation is probably atomic and especially if > external tools uses the same trick. However this is not the case yet, eg > "pg_r

Re: Offline enabling/disabling of data checksums

Ok, this might not work, because of the following, less likely, race condition: postmaster opens control file RW pg_checksums moves control file, postmater open file handle follows ... So ISTM that we really need some locking to have something clean. We are talking about complicating a m

Re: pg_upgrade version checking questions

On Tuesday, March 19, 2019 7:55 AM, Bruce Momjian wrote: > On Tue, Mar 19, 2019 at 02:43:49AM -0400, Bruce Momjian wrote: > > > > 3. Actually, I'm kind of wondering why pg_upgrade has a --new-bindir > > > option at all, rather than just insisting on finding the new-version > > > executab

Re: Index Skip Scan

> On Sat, Mar 16, 2019 at 5:14 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Fri, Mar 15, 2019 at 4:55 AM Kyotaro HORIGUCHI > > wrote: > > I have some comments on the latest v11 patch. > > Thank you! In the meantime here is a new version, rebased after tableam changes. v13-0001-Inde

Re: partitioned tables referenced by FKs

On 2019-Mar-14, Robert Haas wrote: > On Thu, Mar 14, 2019 at 3:36 PM Alvaro Herrera > wrote: > > In any case, since the RI > > queries are run via SPI, any unnecessary partitions should get pruned by > > partition pruning based on each partition's constraint. So I'm not so > > certain that thi

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On 3/16/19 5:32 PM, Robert Haas wrote: There's only one query ID field available, and you can't use two extensions that care about query ID unless they compute it the same way, and replicating all the code that computes the query ID into each new extension that wants one sucks. I think we shoul

Re: Willing to fix a PQexec() in libpq module

Kyotaro HORIGUCHI writes: > At Tue, 19 Mar 2019 08:18:23 +, "Wu, Fei" > wrote in > <52E6E0843B9D774C8C73D6CF64402F05621F0FFC@G08CNEXMBPEKD02.g08.fujitsu.local> >> I will try to fix it~ > I don't oppose that, but as the discussion linked from there [1], > psql already has a feature that sen

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Tue, Mar 19, 2019 at 2:45 PM Maksim Milyutin wrote: > > But I think that enough to integrate into core the query normalization > routine and store generalized query strings (from which the queryId is > produced) in shared memory (for example, hashtable that maps queryId to > the text representa

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Mon, Mar 18, 2019 at 7:33 PM Julien Rouhaud wrote: > > On Mon, Mar 18, 2019 at 6:23 PM Yun Li wrote: > > > > Let's take one step back. Since queryId is stored in core as Julien pointed > > out, can we just add that global to the pg_stat_get_activity and ultimately > > exposed in pg_stat_acti

Re: [HACKERS] Cached plans and statement generalization

Thank you very much for the review! On 19.03.2019 5:56, Yamaji, Ryo wrote: On Tue, Jan 29, 2019 at 10:46 AM, Konstantin Knizhnik wrote: Rebased version of the patch is attached. I'm sorry for the late review. I confirmed behavior of autoprepare-12.patch. It is summarized below. ・parameter Exp

Re: Problem with default partition pruning

Le 19/03/2019 à 08:01, Yuzuko Hosoya a écrit : > Hi Amit-san, > > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Sent: Monday, March 18, 2019 6:44 PM > >> Hosoya-san, >> >> On 2019/03/15 15:05, Yuzuko Hosoya wrote: >>> Indeed, it's problematic. I also did test and I found that thi

Re: pg_upgrade version checking questions

On 2019-03-19 00:35, Tom Lane wrote: > 2. check_cluster_versions() insists that the target version be the > same major version as pg_upgrade itself, but is that really good enough? > As things stand, it looks like pg_upgrade 11.3 would happily use pg_dump > 11.1, or vice versa. I'd hesitate to tie

Re: Online verification of checksums

On Mon, Mar 18, 2019 at 2:38 AM Stephen Frost wrote: > Sure the backend has those facilities since it needs to, but these > frontend tools *don't* need that to *never* have any false positives, so > why are we complicating things by saying that this frontend tool and the > backend have to coordina

Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested I read a discussion and I think so currently implemented behave (by l

Re: Offline enabling/disabling of data checksums

Hi, On 2019-03-18 17:13:01 +0900, Michael Paquier wrote: > +/* > + * Locations of persistent and temporary control files. The control > + * file gets renamed into a temporary location when enabling checksums > + * to prevent a parallel startup of Postgres. > + */ > +#define CONTROL_FILE_PATH

Re: Speed up transaction completion faster after many relations are accessed in a transaction

On 2019-03-19 10:21, Tsunakawa, Takayuki wrote: > From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com] >> Fixed. > > Rebased on HEAD. I have committed the first patch that reorganizes the struct. I'll have to spend some time evaluating the performance impact of the second patch, but

Re: [HACKERS] Custom compression methods

On Tue, Mar 19, 2019 at 12:19 PM Tomas Vondra wrote: > > On 3/19/19 10:59 AM, Chris Travers wrote: > > > > > > Not discussing whether any particular committer should pick this up but > > I want to discuss an important use case we have at Adjust for this sort > > of patch. > > > > The PostgreSQL c

Re: Concurrency bug with vacuum full (cluster) and toast

On Mon, Mar 18, 2019 at 12:53 PM Alexander Korotkov wrote: > I've discovered bug, when vacuum full fails with error, because it > couldn't find toast chunks deleted by itself. That happens because > cluster_rel() sets OldestXmin, but toast accesses gets snapshot later > and independently. That c

Re: pg_upgrade version checking questions

Peter Eisentraut writes: > On 2019-03-19 00:35, Tom Lane wrote: >> 2. check_cluster_versions() insists that the target version be the >> same major version as pg_upgrade itself, but is that really good enough? >> As things stand, it looks like pg_upgrade 11.3 would happily use pg_dump >> 11.1, or

Re: Online verification of checksums

Hi, Am Dienstag, den 19.03.2019, 11:22 -0400 schrieb Robert Haas: > It's torn pages that I am concerned about - the server is writing and > we are reading, and we get a mix of old and new content. We have been > quite diligent about protecting ourselves from such risks elsewhere, > and checksum v

Re: Offline enabling/disabling of data checksums

Hi, Am Dienstag, den 19.03.2019, 08:36 -0700 schrieb Andres Freund: > On 2019-03-18 17:13:01 +0900, Michael Paquier wrote: > > +/* > > + * Locations of persistent and temporary control files. The control > > + * file gets renamed into a temporary location when enabling checksums > > + * to preven

Re: Online verification of checksums

Hi, On 2019-03-19 16:52:08 +0100, Michael Banck wrote: > Am Dienstag, den 19.03.2019, 11:22 -0400 schrieb Robert Haas: > > It's torn pages that I am concerned about - the server is writing and > > we are reading, and we get a mix of old and new content. We have been > > quite diligent about prote

Re: Offline enabling/disabling of data checksums

On 2019-03-19 16:55:12 +0100, Michael Banck wrote: > Hi, > > Am Dienstag, den 19.03.2019, 08:36 -0700 schrieb Andres Freund: > > On 2019-03-18 17:13:01 +0900, Michael Paquier wrote: > > > +/* > > > + * Locations of persistent and temporary control files. The control > > > + * file gets renamed in

Re: Offline enabling/disabling of data checksums

Hi, Am Dienstag, den 19.03.2019, 09:00 -0700 schrieb Andres Freund: > On 2019-03-19 16:55:12 +0100, Michael Banck wrote: > > Am Dienstag, den 19.03.2019, 08:36 -0700 schrieb Andres Freund: > > > On 2019-03-18 17:13:01 +0900, Michael Paquier wrote: > > > > +/* > > > > + * Locations of persistent an

Re: Offline enabling/disabling of data checksums

Hi, On 2019-03-19 17:08:17 +0100, Michael Banck wrote: > Am Dienstag, den 19.03.2019, 09:00 -0700 schrieb Andres Freund: > > On 2019-03-19 16:55:12 +0100, Michael Banck wrote: > > > Am Dienstag, den 19.03.2019, 08:36 -0700 schrieb Andres Freund: > > > > On 2019-03-18 17:13:01 +0900, Michael Paquie

Re: Offline enabling/disabling of data checksums

Hi, Am Dienstag, den 19.03.2019, 09:13 -0700 schrieb Andres Freund: > On 2019-03-19 17:08:17 +0100, Michael Banck wrote: > > Am Dienstag, den 19.03.2019, 09:00 -0700 schrieb Andres Freund: > > > On 2019-03-19 16:55:12 +0100, Michael Banck wrote: > > > > Am Dienstag, den 19.03.2019, 08:36 -0700 sch

Re: Willing to fix a PQexec() in libpq module

On Tue, Mar 19, 2019 at 10:30:45AM -0400, Tom Lane wrote: > Kyotaro HORIGUCHI writes: > > At Tue, 19 Mar 2019 08:18:23 +, "Wu, Fei" > > wrote in > > <52E6E0843B9D774C8C73D6CF64402F05621F0FFC@G08CNEXMBPEKD02.g08.fujitsu.local> > >> I will try to fix it~ > > > I don't oppose that, but as the

Re: Libpq support to connect to standby server as priority

On Mon, Mar 18, 2019 at 9:33 PM Haribabu Kommi wrote: > While working on implementation of target_server_type new connection option > for the libpq > to specify master, slave and etc, there is no problem when the newly added > target_server_type > option is used separate, but when it is combined

Re: Offline enabling/disabling of data checksums

Hi, On 2019-03-19 17:30:16 +0100, Michael Banck wrote: > Am Dienstag, den 19.03.2019, 09:13 -0700 schrieb Andres Freund: > > On 2019-03-19 17:08:17 +0100, Michael Banck wrote: > > > Am Dienstag, den 19.03.2019, 09:00 -0700 schrieb Andres Freund: > > > > On 2019-03-19 16:55:12 +0100, Michael Banck

Re: Willing to fix a PQexec() in libpq module

David Fetter writes: > I think the answer is "no," and we should deprecate this misfeature. > It's bad enough that we'll be supporting it for five years after > deprecating it, but it's worse to leave it hanging around our necks > forever. https://en.wikipedia.org/wiki/Albatross_(metaphor) The pr

Re: Willing to fix a PQexec() in libpq module

Hi, On 2019-03-19 12:51:39 -0400, Tom Lane wrote: > David Fetter writes: > > I think the answer is "no," and we should deprecate this misfeature. > > It's bad enough that we'll be supporting it for five years after > > deprecating it, but it's worse to leave it hanging around our necks > > foreve

Re: Willing to fix a PQexec() in libpq module

On 2019-Mar-19, Andres Freund wrote: > Hi, > > On 2019-03-19 12:51:39 -0400, Tom Lane wrote: > > David Fetter writes: > > > I think the answer is "no," and we should deprecate this misfeature. > > > It's bad enough that we'll be supporting it for five years after > > > deprecating it, but it's w

Re: Willing to fix a PQexec() in libpq module

On Tue, Mar 19, 2019 at 01:59:34PM -0300, Alvaro Herrera wrote: > On 2019-Mar-19, Andres Freund wrote: > > > Hi, > > > > On 2019-03-19 12:51:39 -0400, Tom Lane wrote: > > > David Fetter writes: > > > > I think the answer is "no," and we should deprecate this misfeature. > > > > It's bad enough t

Re: Willing to fix a PQexec() in libpq module

Hi, On 2019-03-19 13:59:34 -0300, Alvaro Herrera wrote: > On 2019-Mar-19, Andres Freund wrote: > > On 2019-03-19 12:51:39 -0400, Tom Lane wrote: > > > David Fetter writes: > > > > I think the answer is "no," and we should deprecate this misfeature. > > > > It's bad enough that we'll be supporting

Re: Willing to fix a PQexec() in libpq module

On 2019-03-19 10:02:33 -0700, Andres Freund wrote: > Hi, > > On 2019-03-19 13:59:34 -0300, Alvaro Herrera wrote: > > On 2019-Mar-19, Andres Freund wrote: > > > On 2019-03-19 12:51:39 -0400, Tom Lane wrote: > > > > David Fetter writes: > > > > > I think the answer is "no," and we should deprecate

Re: jsonpath

On Sun, Mar 17, 2019 at 6:03 PM Tom Lane wrote: > Andrew Dunstan writes: > > Why are we installing the jsonpath_gram.h file? It's not going to be > > used by anything else, is it? TBH, I'm not sure I see why we're > > installing the scanner.h file either. > > As near as I can see, jsonpath_gram.h

Automated way to find actual COMMIT LSN of subxact LSN

I want to build automation to recover a database to a specific LSN *inclusive*, even if that LSN is from a subtransaction. The problem I am facing is that I know what specific LSN wrote a row on a remote system, but if I create a recovery.conf file with: recovery_target_lsn = '95F/BBA36DF8' and

Re: Willing to fix a PQexec() in libpq module

Andres Freund writes: > On 2019-03-19 13:59:34 -0300, Alvaro Herrera wrote: >> I suppose it can be argued that for the cases where they want that, it >> is not entirely ridiculous to have it be done with a different API call, >> say PQexecMultiple. > Sure, but what'd the gain be? Using PQexecPara

Re: Willing to fix a PQexec() in libpq module

Hi, On 2019-03-19 13:18:25 -0400, Tom Lane wrote: > Having said that ... a better argument for a new API is that it > could be explicitly designed to handle multiple queries, and in > particular make some provision for returning multiple PGresults. Oh, I completely agree, that'd be hugely useful.

Re: Willing to fix a PQexec() in libpq module

On Tue, Mar 19, 2019 at 01:18:25PM -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-03-19 13:59:34 -0300, Alvaro Herrera wrote: > >> I suppose it can be argued that for the cases where they want that, it > >> is not entirely ridiculous to have it be done with a different API call, > >> s

Re: extensions are hitting the ceiling

On Mon, Mar 18, 2019 at 11:56 PM Chapman Flack wrote: > On 03/18/19 22:38, Eric Hanson wrote: > > rows are really second class citizens: They aren't tracked with > > pg_catalog.pg_depend, they aren't deleted when the extension is dropped, > > etc. > > This. You have other interests as well, but

Re: Concurrency bug with vacuum full (cluster) and toast

On Tue, Mar 19, 2019 at 6:48 PM Robert Haas wrote: > On Mon, Mar 18, 2019 at 12:53 PM Alexander Korotkov > wrote: > > I've discovered bug, when vacuum full fails with error, because it > > couldn't find toast chunks deleted by itself. That happens because > > cluster_rel() sets OldestXmin, but t

Re: Willing to fix a PQexec() in libpq module

Andres Freund writes: > On 2019-03-19 13:18:25 -0400, Tom Lane wrote: >> Having said that ... a better argument for a new API is that it >> could be explicitly designed to handle multiple queries, and in >> particular make some provision for returning multiple PGresults. > Oh, I completely agree,

Re: [HACKERS] CLUSTER command progress monitor

On Mon, Mar 18, 2019 at 10:03 PM Tatsuro Yamada wrote: > Attached patch is a rebased document patch. :) Attached is an updated patch. I went through this patch carefully today, in the hopes of committing it, and I think the attached version is pretty closet to being committable, but there's at l

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Tue, Mar 19, 2019 at 1:24 PM Jim Finnerty wrote: > The queryId depends on oids, so it is not stable enough for some purposes. > For example, to create a SQL identifier that survives across a server > upgrade, or that can be shipped to another database, the queryId isn't > usable. > > The apg_pl

Re: Willing to fix a PQexec() in libpq module

Tom Lane wrote: > Unfortunately, if the default behavior doesn't change, then there's little > argument for doing this at all. The security reasoning behind doing > anything in this area would be to provide an extra measure of protection > against SQL-injection attacks on carelessly-writt

Re: Online verification of checksums

Greetings, On Tue, Mar 19, 2019 at 23:59 Andres Freund wrote: > Hi, > > On 2019-03-19 16:52:08 +0100, Michael Banck wrote: > > Am Dienstag, den 19.03.2019, 11:22 -0400 schrieb Robert Haas: > > > It's torn pages that I am concerned about - the server is writing and > > > we are reading, and we ge

Re: Rare SSL failures on eelpout

Thomas Munro writes: > On Tue, Mar 19, 2019 at 9:11 AM Tom Lane wrote: >>> One thing that isn't real clear to me is how much timing sensitivity >>> there is in "when no more input data is available". Can we assume that >>> if we've gotten ECONNRESET or an allied error from a write, then any >>>

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

Great, thank you Julien ! Would it make sense to add it in auto explain ? I don't know for explain itself, but maybe ... Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

Re: Rare SSL failures on eelpout

On Wed, Mar 20, 2019 at 8:31 AM Tom Lane wrote: > So I'm inclined to (1) commit the patch as-proposed in HEAD, and > (2) hack the ssl test cases in v11 as you suggested. If we see field > complaints about this, we can consider reverting (2) in favor of > a back-patch once v12 beta is over. This

Re: Online verification of checksums

Hi, On 2019-03-20 03:27:55 +0800, Stephen Frost wrote: > On Tue, Mar 19, 2019 at 23:59 Andres Freund wrote: > > On 2019-03-19 16:52:08 +0100, Michael Banck wrote: > > > Am Dienstag, den 19.03.2019, 11:22 -0400 schrieb Robert Haas: > > > > It's torn pages that I am concerned about - the server is

Re: Online verification of checksums

On 2019-03-19 13:00:50 -0700, Andres Freund wrote: > As it stands, the logic seems to give more false confidence than > anything else. To demonstrate that I ran a loop that verified that a) a normal backend query using the tale detects the corruption b) pg_basebackup doesn't. i=0; while true; do

[survey] New "Stable" QueryId based on normalized query text

Hello, There are many projects that use alternate QueryId distinct from the famous pg_stat_statements jumbling algorithm. https://github.com/postgrespro/aqo query_hash https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.ViewPlans.html sql_hash https://github.

Re: Online verification of checksums

On Tue, Mar 19, 2019 at 4:49 PM Andres Freund wrote: > To demonstrate that I ran a loop that verified that a) a normal backend > query using the tale detects the corruption b) pg_basebackup doesn't. > > i=0; > while true; do > i=$(($i+1)); > echo attempt $i; > dd if=/dev/urandom of=/sr

Re: Online verification of checksums

Hi, Am Dienstag, den 19.03.2019, 13:00 -0700 schrieb Andres Freund: > On 2019-03-20 03:27:55 +0800, Stephen Frost wrote: > > On Tue, Mar 19, 2019 at 23:59 Andres Freund wrote: > > > On 2019-03-19 16:52:08 +0100, Michael Banck wrote: > > > > Am Dienstag, den 19.03.2019, 11:22 -0400 schrieb Robert

  1   2   >