Re: SQL statement PREPARE does not work in ECPG

Hi all and thank you Matsumura-san. > Excuse: > It doesn't include regression tests and pass them. > Because I must reset all expected C program of regression. > # I add an argument to ECPGdo(). Sure, let's do this at the very end. > 1. Specification > It accepts the following .pgc. >

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

Yun Li writes: > Do you think if we can add queryId into the pg_stat_get_activity function > and ultimatly expose it in the view? It would be easier to track "similar" > query's performance over time easier. No, we're not likely to do that, because it would mean (1) baking one single definition

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

On Fri, Mar 15, 2019 at 3:40 PM John Naylor wrote: > > On Fri, Mar 15, 2019 at 5:55 PM Amit Kapila wrote: > > I have committed the latest version of this patch. I think we can > > wait for a day or two see if there is any complain from buildfarm or > > in general and then we can close this CF

Make pg_checksums complain if compiled BLCKSZ and data folder's block size differ

Hi all, (related folks in CC) Sergei Kornilov has reported here an issue with pg_checksums: https://www.postgresql.org/message-id/5217311552474...@myt2-66bcb87429e6.qloud-c.yandex.net If the block size the tool is compiled with does not match the data folder block size, then users would get

Re: Lifespan of a BeginInternalSubTransaction subxact ?

Chapman Flack writes: > PL/Java implements JDBC Savepoints using BeginInternalSubTransaction/ > ReleaseCurrentSubTransaction/RollbackAndReleaseCurrentSubTransaction. > That seems to be the Accepted Way of Doing Things within backend PLs > that want control over error recovery, am I right? Sounds

Re: string_to_array, array_to_string function without separator

On Fri, Mar 15, 2019 at 12:31:21PM -0400, Chapman Flack wrote: > On 3/15/19 12:15 PM, Tom Lane wrote: > > Chapman Flack writes: > >> So the proposal seems roughly equivalent to making string_to_array's > >> second parameter optional default null, and array_to_string's second > >> parameter

Lifespan of a BeginInternalSubTransaction subxact ?

Hi, PL/Java implements JDBC Savepoints using BeginInternalSubTransaction/ ReleaseCurrentSubTransaction/RollbackAndReleaseCurrentSubTransaction. That seems to be the Accepted Way of Doing Things within backend PLs that want control over error recovery, am I right? PL/Java also strictly enforces

Re: seems like a bug in pgbench -R

On 3/15/19 5:16 PM, Fabien COELHO wrote: > >>> echo 'select 1' > select.sql >>> >>> while /bin/true; do >>>  pgbench -n -f select.sql -R 1000 -j 8 -c 8 -T 1 > /dev/null 2>&1; >>>  date; >>> done; >> >> Indeed. I'll look at it over the weekend. >> >>> So I guess this is a bug in

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

Hey pg developers, Do you think if we can add queryId into the pg_stat_get_activity function and ultimatly expose it in the view? It would be easier to track "similar" query's performance over time easier. Thanks a lot! Yun

Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3

On Fri, Mar 15, 2019 at 5:10 PM Tom Lane wrote: > ISTM that this is only a problem if you choose the wrong encryption > method. One not-wrong encryption method is to use a stream cipher > --- maybe that's not the exact right technical term, but anyway > I'm talking about a method which

Re: hyrax vs. RelationBuildPartitionDesc

On Fri, Mar 15, 2019 at 3:45 PM Tom Lane wrote: > More to the point, we turned *one* rebuild = false situation into > a bunch of rebuild = true situations. I haven't studied it closely, > but I think a CCA animal would probably see O(N^2) rebuild = true > invocations in a query with N

Re: REINDEX CONCURRENTLY 2.0

Hi, Am Mittwoch, den 13.03.2019, 23:10 +0100 schrieb Peter Eisentraut: > Here is an updated patch. I had a quick look at some of the comments and noticed some possible nitpicky-level problems: > +/* > + * index_concurrently_set_dead > + * > + * Perform the last invalidation stage of DROP INDEX

Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3

Robert Haas writes: > If the WAL *is* encrypted, the state at this point is that the block > is unreadable, because the first 4kB of the block is the first half of > the bits that resulted from encrypting 8kB of data that includes the > new record, and the second 4kB of the block is the second

Re: [HACKERS] is there a deep unyielding reason to limit U&'' literals to ASCII?

On 1/25/16 12:52 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Jan 23, 2016 at 11:27 PM, Chapman Flack >> wrote: >>> What I would have expected would be to allow s >>> for any Unicode codepoint that's representable in the server encoding, >>> whatever encoding that is. > >> I don't know

Re: hyrax vs. RelationBuildPartitionDesc

Robert Haas writes: > On Fri, Mar 15, 2019 at 2:18 PM Tom Lane wrote: >> BTW, after closer study of 898e5e329 I have a theory as to why it >> made things worse for CCA animals: it causes relcache entries to be >> held open (via incremented refcounts) throughout planning, which >> they were not

Re: GiST VACUUM

On Tue, Mar 5, 2019 at 8:21 AM Heikki Linnakangas wrote: > On 05/03/2019 02:26, Andrey Borodin wrote: > >> I also tried your amcheck tool with this. It did not report any > >> errors. > >> > >> Attached is also latest version of the patch itself. It is the > >> same as your latest patch v19,

Re: hyrax vs. RelationBuildPartitionDesc

On Fri, Mar 15, 2019 at 2:18 PM Tom Lane wrote: > BTW, after closer study of 898e5e329 I have a theory as to why it > made things worse for CCA animals: it causes relcache entries to be > held open (via incremented refcounts) throughout planning, which > they were not before. This means that,

Re: GiST VACUUM

Hi! > 11 марта 2019 г., в 20:03, Heikki Linnakangas написал(а): > > On 10/03/2019 18:40, Andrey Borodin wrote: >> Here's new version of the patch for actual page deletion. >> Changes: >> 1. Fixed possible concurrency issue: >> We were locking child page while holding lock on internal page.

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 18:30 odesílatel Chapman Flack napsal: > On 3/15/19 12:59 PM, Pavel Stehule wrote: > > for this proposal "char" != byte > > > > result[n] = substring(str FROM n FOR 1) > > I think that's what string_to_array(..., null) already does: > sure. My proposal is +/- just reduction

Re: hyrax vs. RelationBuildPartitionDesc

Robert Haas writes: > On Thu, Mar 14, 2019 at 12:36 PM Tom Lane wrote: >> Hmm, I wonder why not. I suppose the answer is that >> the leak is worse in HEAD than before, but how come? > I'd like to know that, too, but right now I don't. BTW, after closer study of 898e5e329 I have a theory as to

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

On Thu, Mar 14, 2019 at 7:50 AM Kyotaro HORIGUCHI wrote: > Thank you for the kind explanation. I'm not sure but I understand > this as '"lists" is an extension' turned into 'lists are an > extension'. That is, the "lists' expresses a concept rather than > the plurarilty. (But I haven't got a gut

Re: string_to_array, array_to_string function without separator

On 3/15/19 12:59 PM, Pavel Stehule wrote: > for this proposal "char" != byte > > result[n] = substring(str FROM n FOR 1) I think that's what string_to_array(..., null) already does: SHOW server_encoding; server_encoding UTF8 WITH t0(s) AS (SELECT text 'verlorn ist daz slüzzelîn'), t1(a) AS

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 17:54 odesílatel Chapman Flack napsal: > On 3/15/19 12:26 PM, Pavel Stehule wrote: > > you use string_to_array function without separator, then only one > possible > > semantic is there - separation by chars. > > Other languages can and do specify other semantics for the >

Re: string_to_array, array_to_string function without separator

On 3/15/19 12:26 PM, Pavel Stehule wrote: > you use string_to_array function without separator, then only one possible > semantic is there - separation by chars. Other languages can and do specify other semantics for the separator-omitted case: often (as in Python) it means to split around "runs

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Thu, Mar 14, 2019 at 8:30 AM Masahiko Sawada wrote: > So I think there is no such insider thread problem, right? No, I think that's a really bad assumption. If there's no insider threat, then what exactly ARE you guarding against? If somebody steals the disk, you don't need PostgreSQL to do

Re: Ordered Partitioned Table Scans

On Sat, 16 Mar 2019 at 04:22, David Rowley wrote: > I've attached an updated patch which fixes the conflict with 0a9d7e1f6d8 ... and here's the one that I should have sent. (renamed to v12 to prevent confusion) -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL

Re: GTIN14 support for contrib/isn

Am 15.03.19 um 17:27 schrieb Tom Lane: Michael Kefeder writes: For a project of ours we need GTIN14 data type support. Hm, what is that and where would a reviewer find the specification for it? specs are from GS1 here https://www.gs1.org/standards/id-keys/gtin side-note EAN13 is actually

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

On 2019-03-15 21:58:25 +0900, Etsuro Fujita wrote: > (2019/03/04 12:10), Etsuro Fujita wrote: > > (2019/03/02 3:57), Andres Freund wrote: > > > FWIW, I pushed the EPQ patch, doing this conversion blindly. It'd be > > > awesome if you'd check that it actually works... > > > > I'll start the work

Re: string_to_array, array_to_string function without separator

On 3/15/19 12:15 PM, Tom Lane wrote: > Chapman Flack writes: >> So the proposal seems roughly equivalent to making string_to_array's >> second parameter optional default null, and array_to_string's second >> parameter optional default ''. > > In that case why bother? It'll just create a

Re: GTIN14 support for contrib/isn

Michael Kefeder writes: > For a project of ours we need GTIN14 data type support. Hm, what is that and where would a reviewer find the specification for it? > Looking at the code I saw every format that isn-extension supports is > stored as an EAN13. Theoretically that can be changed to be

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 17:16 odesílatel Tom Lane napsal: > Chapman Flack writes: > > So the proposal seems roughly equivalent to making string_to_array's > > second parameter optional default null, and array_to_string's second > > parameter optional default ''. > > In that case why bother? It'll

Inquiries

Hello, I am inquiring into the program Parallel access. How do I eile it from my device/ data completetly.  I don't believe ir is reliable... a broken laptop might have had the harddrive taken by a "friend" and accessed my account through this avenue. I am also wondering what you know about

Re: seems like a bug in pgbench -R

echo 'select 1' > select.sql while /bin/true; do pgbench -n -f select.sql -R 1000 -j 8 -c 8 -T 1 > /dev/null 2>&1; date; done; Indeed. I'll look at it over the weekend. So I guess this is a bug in 12788ae49e1933f463bc59a6efe46c4a01701b76, or one of the other commits touching this part

Re: string_to_array, array_to_string function without separator

Chapman Flack writes: > So the proposal seems roughly equivalent to making string_to_array's > second parameter optional default null, and array_to_string's second > parameter optional default ''. In that case why bother? It'll just create a cross-version compatibility hazard for next-to-no

Re: Feature: triggers on materialized views

Hi! On Fri, Mar 15, 2019 at 2:46 AM David Steele wrote: > The reason is that you have not gotten any committer support for this > patch or attracted significant review, that I can see. On the contrary, > three committers have expressed doubts about all or some of the patch > and it doesn't seem

GTIN14 support for contrib/isn

Hello hackers, For a project of ours we need GTIN14 data type support. The isn extension already supports EAN13, and a '0' prefixed EAN13 is a valid GTIN14. The leftmost "new" 14th digit is a packaging level indicator which we need (= using EAN13 and faking a leading 0 in output doesn't cut

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 16:59 odesílatel Chapman Flack napsal: > On 3/15/19 11:46 AM, Pavel Stehule wrote: > > pá 15. 3. 2019 v 15:03 odesílatel David Fetter > napsal: > >> Whatever optimizations you have in mind for this, could they also work > >> for string_to_array() and array_to_string() when they

Re: Facing issue in using special characters

This is not an issue for "hackers" nor "performance" in fact even for "general" it isn't really an issue. "Special characters" is actually nonsense. When people complain about "special characters" they haven't thought things through. If you are unwilling to think things through and go step

Re: string_to_array, array_to_string function without separator

On 3/15/19 11:46 AM, Pavel Stehule wrote: > pá 15. 3. 2019 v 15:03 odesílatel David Fetter napsal: >> Whatever optimizations you have in mind for this, could they also work >> for string_to_array() and array_to_string() when they get an empty >> string handed to them? > > my idea is use

Re: Ordered Partitioned Table Scans

On Fri, Mar 8, 2019 at 3:15 PM Tom Lane wrote: > I took a quick look through this and I'm not very happy with it. > It seems to me that the premise ought to be "just use an Append > if we can prove the output would be ordered anyway", but that's not > what we actually have here: instead you're

Re: string_to_array, array_to_string function without separator

pá 15. 3. 2019 v 15:03 odesílatel David Fetter napsal: > On Fri, Mar 15, 2019 at 05:04:02AM +0100, Pavel Stehule wrote: > > Hi > > > > I propose mentioned functions without specified separator. In this case > the > > string is transformed to array of chars, in second case, the array of > chars >

Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3

On Thu, Mar 14, 2019 at 9:26 AM Antonin Houska wrote: > The point of #ifdef USE_ENCRYPTION is that we rely on OpenSSL, so the code > needs to compile even w/o OpenSSL (of course the encryption won't be enabled > in that case). I'll try to reduce the use of this construct only to the code > blocks

Re: Ordered Partitioned Table Scans

I've attached an updated patch which fixes the conflict with 0a9d7e1f6d8 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services v11-0001-Allow-Append-to-be-used-in-place-of-MergeAppend-.patch Description: Binary data

Re: libpq environment variables in the server

On Fri, Mar 15, 2019 at 10:06:29AM +, Dagfinn Ilmari Mannsåker wrote: > Peter Eisentraut writes: > > > On 2019-03-15 05:00, Noah Misch wrote: > >> I consider the following style more idiomatic: > >> > >> { > >> local %ENV; > >> delete $ENV{PGAPPNAME}; > >> ... > >> } > > >

Re: seems like a bug in pgbench -R

echo 'select 1' > select.sql while /bin/true; do pgbench -n -f select.sql -R 1000 -j 8 -c 8 -T 1 > /dev/null 2>&1; date; done; Indeed. I'll look at it over the weekend. So I guess this is a bug in 12788ae49e1933f463bc59a6efe46c4a01701b76, or one of the other commits touching this part

Re: Best way to keep track of a sliced TOAST

On Fri, Mar 15, 2019 at 7:37 AM Bruno Hass wrote: > This idea is what I was hoping to achieve. Would we be able to make > optimizations on deTOASTing just by storing the chunk lengths in chunk 0? I don't know. I guess we could also NOT store the chunk lengths and just say that if you don't

Re: string_to_array, array_to_string function without separator

On Fri, Mar 15, 2019 at 05:04:02AM +0100, Pavel Stehule wrote: > Hi > > I propose mentioned functions without specified separator. In this case the > string is transformed to array of chars, in second case, the array of chars > is transformed back to string. > > Comments, notes? Whatever

Re: hyrax vs. RelationBuildPartitionDesc

Robert Haas writes: > On Thu, Mar 14, 2019 at 6:08 PM Tom Lane wrote: >> And it's >> still calling get_rel_relkind() in the rd_pdcxt context, potentially >> leaking a *lot* of stuff into that normally-long-lived context, since >> that will result in fresh catcache (and thence potentially

Re: hyrax vs. RelationBuildPartitionDesc

Heikki Linnakangas writes: > On 15/03/2019 00:08, Tom Lane wrote: >> Possibly it'd make sense to conditionally compile this so that we only >> do it in a CLOBBER_CACHE_ALWAYS build. I'm not very sure about that, >> but arguably in a normal build the overhead of making and destroying >> a context

Re: hyrax vs. RelationBuildPartitionDesc

On Thu, Mar 14, 2019 at 6:08 PM Tom Lane wrote: > I found that even with 2455ab488, there still seemed to be an > unreasonable amount of MessageContext bloat during some of the queries, > on the order of 50MB in some of them. Investigating more closely, > I found that 2455ab488 has a couple of

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

(2019/03/04 12:10), Etsuro Fujita wrote: (2019/03/02 3:57), Andres Freund wrote: FWIW, I pushed the EPQ patch, doing this conversion blindly. It'd be awesome if you'd check that it actually works... I'll start the work later this week. I think I can post an (initial) report on that next week,

Re: Re: Re: [HACKERS] Custom compression methods

On Fri, Mar 15, 2019 at 6:07 PM David Steele wrote: > On 3/7/19 11:50 AM, Alexander Korotkov wrote: > > On Thu, Mar 7, 2019 at 10:43 AM David Steele > > wrote: > > > > On 2/28/19 5:44 PM, Ildus Kurbangaliev wrote: > > > > > there are another set of patches.

Re: Offline enabling/disabling of data checksums

Hi, Am Freitag, den 15.03.2019, 21:23 +0900 schrieb Michael Paquier: > On Fri, Mar 15, 2019 at 12:54:01PM +0100, Michael Banck wrote: > > 1. There's a typo in line 578 which makes it fail to compile: > > > > > src/bin/pg_checksums/pg_checksums.c:578:4: error: ‘y’ undeclared (first > > > use in

Re: hyrax vs. RelationBuildPartitionDesc

On Fri, Mar 15, 2019 at 3:32 AM Heikki Linnakangas wrote: > We maintain a free list of AllocSetContexts nowadays, so creating a > short-lived context should be pretty cheap. Or if it's still too > expensive, we could create one short-lived context as a child of > TopMemoryContext, and reuse that

Re: Offline enabling/disabling of data checksums

On Fri, Mar 15, 2019 at 12:54:01PM +0100, Michael Banck wrote: > 1. There's a typo in line 578 which makes it fail to compile: > > |src/bin/pg_checksums/pg_checksums.c:578:4: error: ‘y’ undeclared (first use > in this function) > | }y I am wondering where you got this one. My local branch

Re: Offline enabling/disabling of data checksums

Hi, Am Freitag, den 15.03.2019, 11:50 +0900 schrieb Michael Paquier: > I have been able to grab some time to incorporate the feedback gathered > on this thread, and please find attached a new version of the patch to > add --enable/--disable. Some more feedback: 1. There's a typo in line 578

RE: Best way to keep track of a sliced TOAST

> It seems to me that making this overly pluggable is likely to be a net > negative, because there probably aren't really that many different > ways of doing this that are useful, and because having to store more > identifying information will make the toasted datum larger. One idea > is to let

Re: Offline enabling/disabling of data checksums

Hi, Am Mittwoch, den 13.03.2019, 12:24 +0100 schrieb Magnus Hagander: > On Wed, Mar 13, 2019 at 11:54 AM Sergei Kornilov wrote: > > One new question from me: how about replication? > > Case: primary+replica, we shut down primary and enable checksum, and > > "started streaming WAL from primary"

Re: Show a human-readable n_distinct in pg_stats view

Maxence Ahlouche wrote: > It seems to me that since the pg_stats view is supposed to be > human-readable, it would make sense to show a human-readable version > of n_distinct. > Currently, when the stats collector estimates that the number of > distinct values is more than 10% of the total row

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

On Fri, Mar 15, 2019 at 5:55 PM Amit Kapila wrote: > I have committed the latest version of this patch. I think we can > wait for a day or two see if there is any complain from buildfarm or > in general and then we can close this CF entry. IIRC, this was the > last patch in the series, right?

Re: Re: Re: [HACKERS] Custom compression methods

On 3/7/19 11:50 AM, Alexander Korotkov wrote: On Thu, Mar 7, 2019 at 10:43 AM David Steele > wrote: On 2/28/19 5:44 PM, Ildus Kurbangaliev wrote: > there are another set of patches. > Only rebased to current master. > > Also I will change

Re: libpq environment variables in the server

Peter Eisentraut writes: > On 2019-03-15 05:00, Noah Misch wrote: >> I consider the following style more idiomatic: >> >> { >> local %ENV; >> delete $ENV{PGAPPNAME}; >> ... >> } > > That doesn't work because the first line clears the entire environment. The solution to that is

Re: Offline enabling/disabling of data checksums

On Fri, Mar 15, 2019 at 09:52:11AM +0100, Magnus Hagander wrote: > As I said, that's a big hammer. I'm all for having a better solution. But I > don't think it's acceptable not to have *any* defense against it, given how > bad corruption it can lead to. Hm... It looks that my arguments are not

Re: Re: RE: libpq debug log

On 3/5/19 5:28 PM, David Steele wrote: On 3/5/19 11:48 AM, Iwata, Aya wrote: So is it alright to add these information to the new/proposed PQtrace() default output? I agree with Andres [1] that it's not very clear where this patch is going and we should push the target to PG13. Hearing

Re: Show a human-readable n_distinct in pg_stats view

On Wed, 13 Mar 2019 at 15:14, Maxence Ahlouche wrote: > * Should I add this patch to the commitfest? I added it: https://commitfest.postgresql.org/23/2061/

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

On Thu, Mar 14, 2019 at 7:46 PM Amit Kapila wrote: > > On Thu, Mar 14, 2019 at 12:37 PM John Naylor > wrote: > > > > On Thu, Mar 14, 2019 at 2:17 PM Amit Kapila wrote: > > > > > > 1. Added an Assert in new_cluster_needs_fsm() that old cluster version > > > should be >= 804 as that is where fsm

Change ereport level for QueuePartitionConstraintValidation

Hello Per discussion started here: https://www.postgresql.org/message-id/CA%2BTgmoZWSLUjVcc9KBSVvbn%3DU5QRgW1O-MgUX0y5CnLZOA2qyQ%40mail.gmail.com We have INFO ereport messages in alter table attach partition like this: > partition constraint for table \"%s\" is implied by existing constraints

Re: Feature: temporary materialized views

On 3/15/19 3:19 AM, Mitar wrote: On Thu, Mar 14, 2019 at 7:56 AM Andreas Karlsson wrote: Yeah, your patch is sadly stuck behind the refactoring, and the refactoring proved to be harder to do than I initially thought. The different code paths for executing CREATE MATERIALIZED VIEW are so

Re: Feature: triggers on materialized views

On 3/14/19 12:05 PM, Mitar wrote: Hi! On Thu, Mar 7, 2019 at 12:13 AM David Steele wrote: There doesn't seem to be consensus on whether or not we want this patch. Peter has issues with the way it works and Andres [1] thinks it should be pushed to PG13 or possibly rejected. I'll push this to

Re: [HACKERS] generated columns

On 2019-01-15 08:13, Michael Paquier wrote: > +/* > + * Thin wrapper around libpq to obtain server version. > + */ > +static int > +libpqrcv_server_version(WalReceiverConn *conn) > This should be introduced in separate patch in my opinion (needed > afterwards for logirep). I have committed this

RE: Timeout parameters

> Oops, unfortunately, PQcancel() does not follow any timeout parameters... It uses a blocking socket. > Also, I still don't think it's a good idea to request cancellation. socket_timeout should be sufficiently longer than the usually expected query execution duration. And long-running

Re: Offline enabling/disabling of data checksums

On Thu, Mar 14, 2019 at 4:26 PM Michael Banck wrote: > Hi, > > Am Donnerstag, den 14.03.2019, 15:26 +0100 schrieb Magnus Hagander: > > Given that the failure is data corruption, I don't think big fat > > warning is enough. We should really make it impossible to start up the > > postmaster by

Re: Offline enabling/disabling of data checksums

On Thu, Mar 14, 2019 at 4:54 PM Michael Banck wrote: > Hi, > > Am Donnerstag, den 14.03.2019, 15:32 +0100 schrieb Magnus Hagander: > > On Thu, Mar 14, 2019 at 3:28 PM Christoph Berg wrote: > > > Re: Magnus Hagander 2019-03-14 zmb8qck7ndmchey5...@mail.gmail.com> > > > > Are you suggesting we

Re: Offline enabling/disabling of data checksums

On Fri, Mar 15, 2019 at 1:49 AM Michael Paquier wrote: > On Thu, Mar 14, 2019 at 03:23:59PM +0100, Magnus Hagander wrote: > > Are you suggesting we should support running with a master with checksums > > on and a standby with checksums off in the same cluster? That seems.. > Very > > fragile. >

Willing to fix a TODO case 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: --- Prevent PQfnumber() from lowercasing unquoted column names PQfnumber() should never have been doing

Re: Offline enabling/disabling of data checksums

On Fri, Mar 15, 2019 at 09:04:51AM +0100, Michael Banck wrote: > ISTM this would not run fsync_parent_path() unless the first fsync fails > which is not the intended use. I guess we need two ifs here? Yes, let's do that. Let's see if others have input to offer about the patch. This thread is

Re: Problem with default partition pruning

Hello. At Fri, 15 Mar 2019 15:05:41 +0900, "Yuzuko Hosoya" wrote in <001901d4daf5$1ef4f640$5cdee2c0$@lab.ntt.co.jp> > v2 patch attached. > Could you please check it again? I have some comments on the patch itself. The patch relies on the fact(?) that the lowest index is always -1 in range

RE: Is PREPARE of ecpglib thread safe?

Dear Matsumura-san, Horiguchi-san, We should check the specfication of Pro*c before coding because this follows its feature. I'll test some cases and send you a simple report. Best Regards, Hayato Kuroda Fujitsu LIMITED

RE: Fix typo in test code comments

> Committed. Thanks! Regards, sho kato > -Original Message- > From: Michael Paquier [mailto:mich...@paquier.xyz] > Sent: Friday, March 15, 2019 4:24 PM > To: Kato, Sho/加藤 翔 > Cc: 'Kyotaro HORIGUCHI' ; > pgsql-hack...@postgresql.org > Subject: Re: Fix typo in test code comments > > On

Re: libpq environment variables in the server

On 2019-03-15 05:00, Noah Misch wrote: > I consider the following style more idiomatic: > > { > local %ENV; > delete $ENV{PGAPPNAME}; > ... > } That doesn't work because the first line clears the entire environment. What does work is { delete local $ENV{PGAPPNAME}; ...

Re: Offline enabling/disabling of data checksums

Hi, Am Freitag, den 15.03.2019, 11:50 +0900 schrieb Michael Paquier: > On Thu, Mar 14, 2019 at 04:26:20PM +0100, Michael Banck wrote: > > Am Donnerstag, den 14.03.2019, 15:26 +0100 schrieb Magnus Hagander: > > > One big-hammer method could be similar to what pg_upgrade does -- > > > temporarily

RE: Timeout parameters

From: mikalaike...@ibagroup.eu [mailto:mikalaike...@ibagroup.eu] > In case of failure PQcancel() terminates in 'socket_timeout'. So, control > to the end-user in such a failure situation will be returned in 2 * > 'socket_timeout' interval. It is much better than hanging forever in some > specific

Re: current_logfiles not following group access and instead follows log_file_mode permissions

On Tue, Mar 12, 2019 at 5:03 PM Michael Paquier wrote: > On Tue, Feb 26, 2019 at 12:22:53PM +1100, Haribabu Kommi wrote: > > I checked the code why the current_logfiles is not implemented as > > shared memory and found that the current syslogger doesn't attach to > > the shared memory of the

RE: Is PREPARE of ecpglib thread safe?

Horiguchi-san, Kuroda-san > Horiguchi-san wrote: > > A namespace of declared statement is not connection independent. > > Therefore, we must manage the namespce in global and consider about race > > condition. > > Right, and but thread independent. I was wrong. I understand that DECLARE

Re: hyrax vs. RelationBuildPartitionDesc

On 15/03/2019 00:08, Tom Lane wrote: What I'm thinking, therefore, is that 2455ab488 had the right idea but didn't take it far enough. We should remove the temp-context logic it added to RelationBuildPartitionDesc and instead put that one level up, in RelationBuildDesc, where the same temp

RE: Timeout parameters

Hello Takayuki-san, > Yes, so I think it would be necessary to describe how to set socket_timeout with relation to other timeout parameters -- socket_timeout > statement_timeout, emphasizing that socket_timeout is not for canceling long-running queries but for returning control to the client.

Re: Fix typo in test code comments

On Fri, Mar 15, 2019 at 05:49:47AM +, Kato, Sho wrote: > Oops, thank you for your advice. > I fixed it. Committed. -- Michael signature.asc Description: PGP signature

Re: pg_basebackup ignores the existing data directory permissions

On Fri, Mar 15, 2019 at 10:33 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-09 02:19, Haribabu Kommi wrote: > > Yes, I agree that it may be a problem if the existing data directory > > permissions > > are 0700 to changing it to 0750. But it may not be a problem for

Re: Is PREPARE of ecpglib thread safe?

Oops. At Fri, 15 Mar 2019 15:33:50 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190315.153350.226491548.horiguchi.kyot...@lab.ntt.co.jp> > > // If ecpglib didn't reject the above, ecpglib cannot judge > > // which connection the followings should be executed on. > > exec

Re: Is PREPARE of ecpglib thread safe?

At Fri, 15 Mar 2019 05:27:01 +, "Matsumura, Ryo" wrote in <03040DFF97E6E54E88D3BFEE5F5480F737AC3F24@G01JPEXMBYT04> > Hi Horiguchi-san, Kuroda-san > > Horiguchi-san, thank you for your comment. > > I have a question. > A bug of StatementCache is occurred in previous versions. > Should a

Re: Sparse bit set data structure

On Thu, Mar 14, 2019 at 4:37 PM Julien Rouhaud wrote: > > + if (newitem <= sbs->last_item) > + elog(ERROR, "cannot insert to sparse bitset out of order"); > > Is there any reason to disallow inserting duplicates? AFAICT nothing > prevents that in the current code. If that's

RE: proposal: pg_restore --convert-to-text

Hi Jose, Sorry for my late reply. On Wed, Mar 6, 2019 at 10:58 AM, José Arthur Benetasso Villanova wrote: > On Thu, 28 Feb 2019, Imai, Yoshikazu wrote: > > > Is there no need to rewrite the Description in the Doc to state we should > specify either -d or -f option? > > (and also it might be

RE: Problem with default partition pruning

Hi Thibaut, Thanks a lot for your test and comments. > > Le 28/02/2019 à 09:26, Imai, Yoshikazu a écrit : > > Hosoya-san > > > > On Wed, Feb 27, 2019 at 6:51 AM, Yuzuko Hosoya wrote: > >>> From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > >>> Sent: Wednesday, February 27, 2019 11:22