Re: pause recovery if pitr target not reached

FWIW, I restate this (perhaps) more clearly. At Wed, 15 Jan 2020 11:02:24 +0900 (JST), Kyotaro Horiguchi wrote in > recvoery_target_* is not cleared after startup. If a server crashed > just after the last shutdown checkpoint, any recovery_target_* setting > prevents the server from starting

Re: backup manifests

Hi Tom, On 1/14/20 9:47 PM, Tom Lane wrote: David Steele writes: I'm happy to work up a prototype unless the consensus is that we absolutely don't want a second JSON parser in core. How much code are we talking about? If the answer is "a few hundred lines", it's a lot easier to swallow

Re: [HACKERS] Block level parallel vacuum

On Wed, 15 Jan 2020 at 12:34, Mahendra Singh Thalor wrote: > > On Tue, 14 Jan 2020 at 17:16, Mahendra Singh Thalor > wrote: > > > > On Tue, 14 Jan 2020 at 16:17, Mahendra Singh Thalor > > wrote: > > > > > > On Tue, 14 Jan 2020 at 10:06, Masahiko Sawada > > > wrote: > > > > > > > > On Tue, 14

Re: aggregate crash

Hi, On 2020-01-14 17:54:16 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2020-01-14 17:01:01 -0500, Tom Lane wrote: > >> But I agree that not checking null-ness > >> explicitly is kind of unsafe. We've never before had any expectation > >> that the Datum value of a null is anything in

Re: Remove libpq.rc, use win32ver.rc for libpq

At Tue, 14 Jan 2020 22:34:10 +0100, Peter Eisentraut wrote in > On 2020-01-09 10:56, Peter Eisentraut wrote: > > On 2020-01-06 09:02, Michael Paquier wrote: > >> - FILEFLAGSMASK 0x17L > >> + FILEFLAGSMASK VS_FFI_FILEFLAGSMASK > >> Are you sure with the mapping here? I would have thought that

Re: backup manifests

Hi Stephen, On 1/14/20 1:35 PM, Stephen Frost wrote: My thought, which I had expressed to David (though he obviously didn't entirely agree with me since he suggested the other options), was to adapt the pgBackRest JSON parser, which isn't really all that much code. It's not that I didn't

Re: Restore replication settings when modifying a field type

On 2020/1/3 17:14, Peter Eisentraut wrote: On 2019-11-01 04:39, Euler Taveira wrote: ATExecAlterColumnType records everything that depends on the column and for indexes it saves the definition (via pg_get_indexdef_string). Definition is not sufficient for reconstructing the replica identity

Re: Duplicate Workers entries in some EXPLAIN plans

Thanks for the review! I looked at and rebased the patch on current master, ac5bdf6. I introduced a new test file because this bug is specifically about EXPLAIN output (as opposed to query execution or planning functionality), and it didn't seem like a test would fit in any of the other files. I

Re: Setting min/max TLS protocol in clientside libpq

On Tue, Jan 14, 2020 at 11:01:00PM +0100, Daniel Gustafsson wrote: > Files renamed to match existing naming convention, the rest of the patch left > unchanged. + if ((pg_strcasecmp("tlsv1", protocol) == 0) || pg_strcasecmp("tlsv1.0", protocol) == 0) + return TLS1_VERSION; "TLSv1.0" is

Re: [HACKERS] Block level parallel vacuum

On Tue, 14 Jan 2020 at 21:43, Amit Kapila wrote: > > On Tue, Jan 14, 2020 at 10:04 AM Masahiko Sawada > wrote: > > > > On Mon, 13 Jan 2020 at 12:50, Amit Kapila wrote: > > > > > > On Sat, Jan 11, 2020 at 7:48 PM Masahiko Sawada > > > wrote: > > > > > > Okay, would it better if we get rid of

Re: backup manifests

David Steele writes: > I'm happy to work up a prototype unless the consensus is that we > absolutely don't want a second JSON parser in core. How much code are we talking about? If the answer is "a few hundred lines", it's a lot easier to swallow than if it's "a few thousand".

Re: Remove libpq.rc, use win32ver.rc for libpq

On Wed, Jan 15, 2020 at 02:22:45PM +0900, Kyotaro Horiguchi wrote: > At Tue, 14 Jan 2020 22:34:10 +0100, Peter Eisentraut > wrote in >> On 2020-01-09 10:56, Peter Eisentraut wrote: >>> Note that there is FILEFLAGSMASK and FILEFLAGS. The first is just a >>> mask that says which bits in the

Create/alter policy and exclusive table lock

Hi hackers, Right now changing policies (create/alter policy statements) requires exclusive lock of target table:     /* Get id of table.  Also handles permissions checks. */     table_id = RangeVarGetRelidExtended(stmt->table, AccessExclusiveLock,                                         0,   

Re: Setting min/max TLS protocol in clientside libpq

> On 11 Jan 2020, at 03:49, Michael Paquier wrote: > Heuh. It would be perfect to rely only on OpenSSL for that part > to bring some sanity, and compare the results fetched from the SSL > context so as we don't have to worry about special cases in with the > GUC reload if the parameter is

Re: Setting min/max TLS protocol in clientside libpq

Daniel Gustafsson writes: >> On 11 Jan 2020, at 03:49, Michael Paquier wrote: >>> One thing I noticed when looking at it is that we now have sha2_openssl.c >>> and >>> openssl_protocol.c in src/common. For easier visual grouping of OpenSSL >>> functionality, it makes sense to me to rename

Re: base backup client as auxiliary backend process

On 2020-01-14 07:32, Masahiko Sawada wrote: - Replication slot name used by this WAL receiver + + Replication slot name used by this WAL receiver. This is only set if a + permanent replication slot is set using . Otherwise, the WAL receiver may use + a temporary

Re: Making psql error out on output failures

David Z wrote: > $ psql -d postgres -At -c "select repeat('111', 100)" > > /mnt/ramdisk/file The -A option selects the unaligned output format and -t switches to the "tuples only" mode (no header, no footer). > Test-2: delete the "file", run the command within psql console, > $ rm

Re: our checks for read-only queries are not great

On Mon, Jan 13, 2020 at 3:00 PM Stephen Frost wrote: > I've never heard that and I don't agree with it being a justification > for blocking sensible progress. Speaking of sensible progress, I think we've drifted off on a tangent here about ALTER SYSTEM. As I understand it, nobody's opposed to

Re: Duplicate Workers entries in some EXPLAIN plans

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested This is a high level review only. However, seeing that there is a conflict

Re: [Proposal] Global temporary tables

> 2020年1月14日 下午9:20，Pavel Stehule 写道： > > > > út 14. 1. 2020 v 14:09 odesílatel 曾文旌(义从) > napsal: > Thank you for review my patch. > > >> 2020年1月12日 上午4:27，Pavel Stehule > > 写道： >> >> Hi >> >> so 11. 1. 2020 v 15:00

Re: [Proposal] Global temporary tables

> 2020年1月12日 上午9:14，Tomas Vondra 写道： > > On Fri, Jan 10, 2020 at 03:24:34PM +0300, Konstantin Knizhnik wrote: >> >> >> On 09.01.2020 19:30, Tomas Vondra wrote: >> >> >>> > >> 3 Still no one commented on GTT's transaction information processing, >> they include >>

Re: Create/alter policy and exclusive table lock

Konstantin Knizhnik writes: > Right now changing policies (create/alter policy statements) requires > exclusive lock of target table: Yup. > I wonder why do we really need exclusive lock here? Because it affects the behavior of a SELECT. > May be I missed something, but why we can not rely

Re: Add pg_file_sync() to adminpack

Hello, > On Sut, Jan 11, 2020 at 2:12 Fujii Masao : > I'm not sure if returning false with WARNING only in some error cases > is really good idea or not. At least for me, it's more intuitive to > return true on success and emit an ERROR otherwise. I'd like to hear > more opinions about this.

Re: Create/alter policy and exclusive table lock

On 14.01.2020 17:40, Tom Lane wrote: Konstantin Knizhnik writes: Right now changing policies (create/alter policy statements) requires exclusive lock of target table: Yup. I wonder why do we really need exclusive lock here? Because it affects the behavior of a SELECT. May be I missed

Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR

Dent John wrote: > It’s crashing when it’s checking that the returned tuple matches the > declared return type in rsinfo->setDesc. Seems rsinfo->setDesc gets > overwritten. So I think I have a memory management problem. What is the expected result anyway? A single column with a "record"

Re: Setting min/max TLS protocol in clientside libpq

> On 14 Jan 2020, at 15:49, Tom Lane wrote: > > Daniel Gustafsson writes: On 11 Jan 2020, at 03:49, Michael Paquier wrote: One thing I noticed when looking at it is that we now have sha2_openssl.c and openssl_protocol.c in src/common. For easier visual grouping of OpenSSL

Re: Unicode escapes with any backend encoding

I wrote: > Andrew Dunstan writes: >> On Tue, Jan 14, 2020 at 10:02 AM Tom Lane wrote: >>> Grepping for other direct uses of unicode_to_utf8(), I notice that >>> there are a couple of places in the JSON code where we have a similar >>> restriction that you can only write a Unicode escape in UTF8

Re: backup manifests

On Tue, Jan 14, 2020 at 12:53:04PM -0500, Tom Lane wrote: > Robert Haas writes: > > ... I would also expect that depending on an external package > > would provoke significant opposition. If we suck the code into core, > > then we have to keep it up to date with the upstream, which is a > >

Re: doc: vacuum full, fillfactor, and "extra space"

On Fri, Dec 27, 2019 at 11:58:18AM +0100, Fabien COELHO wrote: >> I started writing this patch to avoid the possibly-misleading phrase: "with >> no >> extra space" (since it's expected to typically take ~2x space, or 1x "extra" >> space). >> >> But the original phrase "with no extra space" seems

Re: backup manifests

Robert Haas writes: > ... I would also expect that depending on an external package > would provoke significant opposition. If we suck the code into core, > then we have to keep it up to date with the upstream, which is a > significant maintenance burden - look at all the time Tom has spent on >

Re: our checks for read-only queries are not great

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > Speaking of sensible progress, I think we've drifted off on a tangent > > here about ALTER SYSTEM. > > Agreed, that's not terribly relevant for the proposed patch. I agree that the proposed patch seems alright by

Re: backup manifests

On Thu, Jan 9, 2020 at 8:19 PM David Steele wrote: > For example, have you considered what will happen if you have a file in > the cluster with a tab in the name? This is perfectly valid in Posix > filesystems, at least. Yeah, there's code for that in the patch I posted. I don't think the

Re: Add pg_file_sync() to adminpack

On Tue, Jan 14, 2020 at 4:08 PM Atsushi Torikoshi wrote: > > > On Sut, Jan 11, 2020 at 2:12 Fujii Masao : > > > But pg_write_server_files users are not allowed to execute > > > other functions like pg_file_write() by default. So doing that > > > change only for pg_file_sync() looks strange to

Use compiler intrinsics for bit ops in hash

Folks, The recent patch for distinct windowing aggregates contained a partial fix of the FIXME that didn't seem entirely right, so I extracted that part, changed it to use compiler intrinsics, and submit it here. Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember

Re: our checks for read-only queries are not great

Robert Haas writes: > Speaking of sensible progress, I think we've drifted off on a tangent > here about ALTER SYSTEM. Agreed, that's not terribly relevant for the proposed patch. regards, tom lane

Re: Create/alter policy and exclusive table lock

Konstantin Knizhnik writes: > But let me ask you one more question: why do we obtaining snapshot twice > in exec_simple_query: > first for analyze (pg_analyze_and_rewrite) and one for execution > (PortalStart)? That would happen anyway if the plan is cached. If we were to throw away all plan

Re: Avoid full GIN index scan when possible

Alexander Korotkov writes: > Updated patch is attached. It contains more comments as well as commit > message. I reviewed this a little bit. I agree this seems way more straightforward than the patches we've been considering so far. I wasn't too happy with the state of the comments, so I

Re: Unicode escapes with any backend encoding

On 1/14/20 10:10 AM, Tom Lane wrote: > to me that this error is just useless pedantry. As long as the DB > encoding can represent the desired character, it should be transparent > to users. That's my position too. Regards, -Chap

Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?)

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > I wrote: > > Here's a draft patch that cleans up all the logic errors I could find. > > So last night I was assuming that this problem just requires more careful > attention to what to return in the error exit paths. In the light of > morning,

Re: backup manifests

Greetings, * David Fetter (da...@fetter.org) wrote: > On Tue, Jan 14, 2020 at 12:53:04PM -0500, Tom Lane wrote: > > Robert Haas writes: > > > ... I would also expect that depending on an external package > > > would provoke significant opposition. If we suck the code into core, > > > then we

Re: proposal: type info support functions for functions that use "any" type

Pavel Stehule writes: > [ parser-support-function-with-demo-20191128.patch ] TBH, I'm still not convinced that this is a good idea. Restricting the support function to only change the function's return type is safer than the original proposal, but it's still not terribly safe. If you change

Re: Unicode escapes with any backend encoding

On Wed, Jan 15, 2020 at 4:25 AM Chapman Flack wrote: > > On 1/14/20 10:10 AM, Tom Lane wrote: > > to me that this error is just useless pedantry. As long as the DB > > encoding can represent the desired character, it should be transparent > > to users. > > That's my position too. > and mine.

Re: Unicode escapes with any backend encoding

On 1/14/20 4:25 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On Wed, Jan 15, 2020 at 4:25 AM Chapman Flack wrote: >>> On 1/14/20 10:10 AM, Tom Lane wrote: to me that this error is just useless pedantry. As long as the DB encoding can represent the desired character, it should be

Re: aggregate crash

Alvaro Herrera writes: > On 2019-Dec-27, Teodor Sigaev wrote: >> Found crash on production instance, assert-enabled build crashes in pfree() >> call, with default config. v11, v12 and head are affected, but, seems, you >> need to be a bit lucky. > Is this bug being considered for the next set of

Re: SQL/JSON: JSON_TABLE

Hi I read this patch There are some typo in doc *name* *type* EXISTS [ PATH *json_path_specification* ] *Gerenates* a column and inserts a boolean item into each row of this column. Is good to allow repeat examples from documentation - so documentation should to contains a INSERT with JSON,

Re: planner support functions: handle GROUP BY estimates ?

Justin Pryzby writes: > On Sun, Dec 22, 2019 at 06:16:48PM -0600, Justin Pryzby wrote: >> On Tue, Nov 19, 2019 at 01:34:21PM -0600, Justin Pryzby wrote: >>> Tom implemented "Planner support functions": >>> https://www.postgresql.org/docs/12/xfunc-optimization.html >>> I wondered whether there was

Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?)

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> ... We must remember how much data we encrypted >> and then discount that much of the caller's supplied data next time. >> There are hints in the existing comments that somebody understood >> this at one point, but the code isn't

Re: Use compiler intrinsics for bit ops in hash

Hi David, On Tue, Jan 14, 2020 at 9:36 AM David Fetter wrote: > > Folks, > > The recent patch for distinct windowing aggregates contained a partial > fix of the FIXME that didn't seem entirely right, so I extracted that > part, changed it to use compiler intrinsics, and submit it here. The

Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?)

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> ... We must remember how much data we encrypted > >> and then discount that much of the caller's supplied data next time. > >> There are hints in the existing comments that

Re: planner support functions: handle GROUP BY estimates ?

On Tue, Jan 14, 2020 at 03:12:21PM -0500, Tom Lane wrote: Justin Pryzby writes: On Sun, Dec 22, 2019 at 06:16:48PM -0600, Justin Pryzby wrote: On Tue, Nov 19, 2019 at 01:34:21PM -0600, Justin Pryzby wrote: Tom implemented "Planner support functions":

Re: Unicode escapes with any backend encoding

Andrew Dunstan writes: > On Wed, Jan 15, 2020 at 4:25 AM Chapman Flack wrote: >> On 1/14/20 10:10 AM, Tom Lane wrote: >>> to me that this error is just useless pedantry. As long as the DB >>> encoding can represent the desired character, it should be transparent >>> to users. >> That's my

Re: Remove libpq.rc, use win32ver.rc for libpq

On 2020-01-09 10:56, Peter Eisentraut wrote: On 2020-01-06 09:02, Michael Paquier wrote: - FILEFLAGSMASK 0x17L + FILEFLAGSMASK VS_FFI_FILEFLAGSMASK Are you sure with the mapping here? I would have thought that VS_FF_DEBUG is not necessary when using release-quality builds, which is something

Re: Add pg_file_sync() to adminpack

Greetings, * Julien Rouhaud (rjuju...@gmail.com) wrote: > On Fri, Jan 10, 2020 at 10:50 AM Fujii Masao wrote: > > On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud wrote: > > > I think that pg_write_server_files should be allowed to call that > > > function by default. > > > > But

Re: planner support functions: handle GROUP BY estimates ?

On Tue, Jan 14, 2020 at 04:21:57PM -0500, Tom Lane wrote: Tomas Vondra writes: On Tue, Jan 14, 2020 at 03:12:21PM -0500, Tom Lane wrote: cc'ing Tomas in case he has any thoughts about it. Well, I certainly do thoughts about this - it's pretty much exactly what I proposed yesterday in this

Re: planner support functions: handle GROUP BY estimates ?

Tomas Vondra writes: > On Tue, Jan 14, 2020 at 04:21:57PM -0500, Tom Lane wrote: >> Yeah, it seems likely to me that the infrastructure for this would be >> somewhat different --- the user-facing syntax could be basically the >> same, but ultimately we want to generate entries in pg_statistic not

Re: aggregate crash

On 2019-Dec-27, Teodor Sigaev wrote: > Hi! > > Found crash on production instance, assert-enabled build crashes in pfree() > call, with default config. v11, v12 and head are affected, but, seems, you > need to be a bit lucky. Is this bug being considered for the next set of minors? -- Álvaro

Re: Setting min/max TLS protocol in clientside libpq

> On 14 Jan 2020, at 16:15, Daniel Gustafsson wrote: > >> On 14 Jan 2020, at 15:49, Tom Lane wrote: >> >> Daniel Gustafsson writes: > On 11 Jan 2020, at 03:49, Michael Paquier wrote: > One thing I noticed when looking at it is that we now have sha2_openssl.c > and >

Re: doc: vacuum full, fillfactor, and "extra space"

Patch applies and compiles. Given that the paragraph begins with "Plain VACUUM (without FULL)", it is better to have the VACUUM FULL explanations on a separate paragraph, and the The original patch does that (Fabien agreed when I asked off list) Indeed. I may have looked at it in reverse,

Re: pause recovery if pitr target not reached

On 2019-12-11 12:40, Leif Gunnar Erlandsen wrote: Adding patch written for 13dev from git "Michael Paquier" skrev 1. desember 2019 kl. 03:08: On Fri, Nov 22, 2019 at 11:26:59AM +, Leif Gunnar Erlandsen wrote: No it does not. It works well to demonstrate its purpose though. And it might

Re: planner support functions: handle GROUP BY estimates ?

Tomas Vondra writes: > On Tue, Jan 14, 2020 at 03:12:21PM -0500, Tom Lane wrote: >> cc'ing Tomas in case he has any thoughts about it. > Well, I certainly do thoughts about this - it's pretty much exactly what > I proposed yesterday in this thread: > >

Re: DROP OWNED CASCADE vs Temp tables

On 2020-Jan-13, Tom Lane wrote: > That seems fundamentally wrong. By the time we've queued an object for > deletion in dependency.c, we have a lock on it, and we've verified that > the object is still there (cf. systable_recheck_tuple calls). > If shdepDropOwned is doing it differently, I'd say

Re: Use compiler intrinsics for bit ops in hash

On Tue, Jan 14, 2020 at 12:21:41PM -0800, Jesse Zhang wrote: > Hi David, > > On Tue, Jan 14, 2020 at 9:36 AM David Fetter wrote: > > > > Folks, > > > > The recent patch for distinct windowing aggregates contained a partial > > fix of the FIXME that didn't seem entirely right, so I extracted that

Re: planner support functions: handle GROUP BY estimates ?

Tomas Vondra writes: > On Tue, Jan 14, 2020 at 04:52:44PM -0500, Tom Lane wrote: >> The main issue for sticking the results into pg_statistic is that >> the primary key there is (starelid, staattnum), and we haven't got >> a suitable attnum. I wouldn't much object to putting the data into >>

Re: Unicode escapes with any backend encoding

On Wed, Jan 15, 2020 at 7:55 AM Tom Lane wrote: > > Andrew Dunstan writes: > > On Wed, Jan 15, 2020 at 4:25 AM Chapman Flack wrote: > >> On 1/14/20 10:10 AM, Tom Lane wrote: > >>> to me that this error is just useless pedantry. As long as the DB > >>> encoding can represent the desired

Re: Unicode escapes with any backend encoding

Andrew Dunstan writes: > Perhaps I expressed myself badly. What I meant was that we should keep > the json and text escape rules in sync, as they are now. Since we're > changing the text rules to allow resolvable non-ascii unicode escapes > in non-utf8 locales, we should do the same for json.

Re: Avoid full GIN index scan when possible

Alexander Korotkov writes: > On Tue, Jan 14, 2020 at 9:43 PM Tom Lane wrote: >> One thing I'm still not happy about is the comment in >> collectMatchesForHeapRow. v12 failed to touch that at all, so I tried to >> fill it in, but I'm not sure if my explanation is good. > I've tried to rephrase

Re: Add FOREIGN to ALTER TABLE in pg_dump

On 2020-Jan-14, Tom Lane wrote: > I can't get terribly excited about persuading that test to cover this > trivial little bit of logic, but if you are, I won't stand in the way. Hmm, that's a good point actually: the patch changed several places to inject the FOREIGN keyword, so in order to cover

Re: planner support functions: handle GROUP BY estimates ?

On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote: Tomas Vondra writes: On Tue, Jan 14, 2020 at 04:52:44PM -0500, Tom Lane wrote: The main issue for sticking the results into pg_statistic is that the primary key there is (starelid, staattnum), and we haven't got a suitable attnum. I

Re: Add pg_file_sync() to adminpack

Le mar. 14 janv. 2020 à 22:57, Stephen Frost a écrit : > Greetings, > > * Julien Rouhaud (rjuju...@gmail.com) wrote: > > On Fri, Jan 10, 2020 at 10:50 AM Fujii Masao > wrote: > > > On Thu, Jan 9, 2020 at 10:39 PM Julien Rouhaud > wrote: > > > > I think that pg_write_server_files should be

Re: planner support functions: handle GROUP BY estimates ?

On Tue, Jan 14, 2020 at 04:52:44PM -0500, Tom Lane wrote: Tomas Vondra writes: On Tue, Jan 14, 2020 at 04:21:57PM -0500, Tom Lane wrote: Yeah, it seems likely to me that the infrastructure for this would be somewhat different --- the user-facing syntax could be basically the same, but

pgindent && weirdness

I just ran pgindent over some patch, and noticed that this hunk ended up in my working tree: diff --git a/src/backend/statistics/extended_stats.c b/src/backend/statistics/extended_stats.c index 861a9148ed..fff54062b0 100644 --- a/src/backend/statistics/extended_stats.c +++

Re: Rearranging ALTER TABLE to avoid multi-operations bugs

I wrote: > [ fix-alter-table-order-of-operations-3.patch ] Rebased again, fixing a minor conflict with f595117e2. > I'd kind of like to get this cleared out of my queue soon. > Does anyone intend to review it further? If I don't hear objections pretty darn quick, I'm going to go ahead and push

Re: aggregate crash

Hi, On 2020-01-14 17:01:01 -0500, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Dec-27, Teodor Sigaev wrote: > >> Found crash on production instance, assert-enabled build crashes in pfree() > >> call, with default config. v11, v12 and head are affected, but, seems, you > >> need to be a

Re: Avoid full GIN index scan when possible

Hi! On Tue, Jan 14, 2020 at 9:43 PM Tom Lane wrote: > Alexander Korotkov writes: > > Updated patch is attached. It contains more comments as well as commit > > message. > > I reviewed this a little bit. I agree this seems way more straightforward > than the patches we've been considering so

Re: Add FOREIGN to ALTER TABLE in pg_dump

Alvaro Herrera writes: >> On Mon, Jan 13, 2020 at 7:52 PM Tom Lane wrote: >>> Isn't the change in the TAP test output sufficient? > Yeah, I think there should be at least one regexp in t/002_pg_dump.pl to > verify ALTER FOREIGN TABLE is being produced. > I wonder if Tom is thinking about Luis'

Re: aggregate crash

Andres Freund writes: > On 2020-01-14 17:01:01 -0500, Tom Lane wrote: >> But I agree that not checking null-ness >> explicitly is kind of unsafe. We've never before had any expectation >> that the Datum value of a null is anything in particular. > I'm still not sure I actually fully understand

Re: backup manifests

On Tue, Jan 14, 2020 at 03:35:40PM -0500, Stephen Frost wrote: > Greetings, > > * David Fetter (da...@fetter.org) wrote: > > On Tue, Jan 14, 2020 at 12:53:04PM -0500, Tom Lane wrote: > > > Robert Haas writes: > > > > ... I would also expect that depending on an external package > > > > would

Re: Add FOREIGN to ALTER TABLE in pg_dump

On 2020-Jan-14, vignesh C wrote: > On Mon, Jan 13, 2020 at 7:52 PM Tom Lane wrote: > > > > vignesh C writes: > > > On Thu, Sep 26, 2019 at 7:17 PM Luis Carril > > > wrote: > > >>> Your patch is failing the pg_dump TAP tests. Please use > > >>> configure --enable-tap-tests, fix the problems,

Re: pgindent && weirdness

Alvaro Herrera writes: > I just ran pgindent over some patch, and noticed that this hunk ended up > in my working tree: > - if (IsA(leftop, Var) && IsA(rightop, Const)) > + if (IsA(leftop, Var) &(rightop, Const)) Yeah, it's been doing that for decades. I think the triggering factor is

Re: Why is pq_begintypsend so slow?

Hi, On 2020-01-13 15:18:04 -0800, Andres Freund wrote: > On 2020-01-11 22:32:45 -0500, Tom Lane wrote: > > I wrote: > > > I saw at this point that the remaining top spots were > > > enlargeStringInfo and appendBinaryStringInfo, so I experimented > > > with inlining them (again, see patch below).

Re: Disallow cancellation of waiting for synchronous replication

Hi, On 2020-01-12 16:18:38 +0500, Andrey Borodin wrote: > > 11 янв. 2020 г., в 7:34, Bruce Momjian написал(а): > > > > Actually, it might be worse than that. In my reading of > > RecordTransactionCommit(), we do this: > > > > write to WAL > > flush WAL (durable) > > make visible

Re: Avoid full GIN index scan when possible

On Wed, Jan 15, 2020 at 1:47 AM Alexander Korotkov wrote: > I also had concerns about how excludeOnly keys work with lossy pages. > I didn't find exact error. But I've added code, which skips > excludeOnly keys checks for lossy pages. They aren't going to exclude > any lossy page anyway. So,

Re: planner support functions: handle GROUP BY estimates ?

Tomas Vondra writes: > On Tue, Jan 14, 2020 at 05:37:53PM -0500, Tom Lane wrote: >> I wonder just how messy it would be to add a column to pg_statistic_ext >> whose type is the composite type "pg_statistic", and drop the required >> data into that. We've not yet used any composite types in the

Re: Add support for automatically updating Unicode derived files

Peter Eisentraut writes: > Committed, thanks. This patch is making src/tools/pginclude/headerscheck unhappy: ./src/include/common/unicode_combining_table.h:3: error: array type has incomplete element type I guess that header needs another #include, or else you need to move some declarations

Re: base backup client as auxiliary backend process

On Tue, 14 Jan 2020 at 22:58, Peter Eisentraut wrote: > > On 2020-01-14 07:32, Masahiko Sawada wrote: > > - Replication slot name used by this WAL receiver > > + > > + Replication slot name used by this WAL receiver. This is only set > > if a > > + permanent replication slot

Complete data erasure

Hello hackers, I want to add the feature to erase data so that it cannot be restored because it prevents attackers from stealing data from released data area. - Background International security policies require that above threat is taken measures. It is "Base Protection Profile for Database

Re: logical decoding : exceeded maxAllocatedDescs for .spill files

On Tue, Jan 14, 2020 at 9:58 AM Amit Kapila wrote: > > On Sun, Jan 12, 2020 at 8:18 AM Amit Kapila wrote: > > > > On Sat, Jan 11, 2020 at 11:16 AM Tom Lane wrote: > > > > > > > > * The seeming bug in v10 suggests that we aren't testing large enough > > > logical-decoding cases, or at least

Re: pause recovery if pitr target not reached

At Tue, 14 Jan 2020 21:13:51 +0100, Peter Eisentraut wrote in > On 2019-12-11 12:40, Leif Gunnar Erlandsen wrote: > > Adding patch written for 13dev from git > > "Michael Paquier" skrev 1. desember 2019 > > kl. 03:08: > > > >> On Fri, Nov 22, 2019 at 11:26:59AM +, Leif Gunnar Erlandsen

Re: Improve errors when setting incorrect bounds for SSL protocols

On Tue, Jan 14, 2020 at 11:21:53AM +0100, Daniel Gustafsson wrote: > On 14 Jan 2020, at 04:54, Michael Paquier wrote: >> Please note that OpenSSL 1.1.0 has added two routines to be able to >> get the min/max protocols set in a context, called >> SSL_CTX_get_min/max_proto_version. Thinking about

Re: [HACKERS] Block level parallel vacuum

On Tue, 14 Jan 2020 at 17:16, Mahendra Singh Thalor wrote: > > On Tue, 14 Jan 2020 at 16:17, Mahendra Singh Thalor > wrote: > > > > On Tue, 14 Jan 2020 at 10:06, Masahiko Sawada > > wrote: > > > > > > On Tue, 14 Jan 2020 at 03:20, Mahendra Singh Thalor > > > wrote: > > > > > > > > On Fri, 10

Re: Complete data erasure

Hello, Asaba-san. At Wed, 15 Jan 2020 01:31:44 +, "asaba.takan...@fujitsu.com" wrote in > Hello hackers, > > I want to add the feature to erase data so that it cannot be restored > because it prevents attackers from stealing data from released data area. > > - Background > International

Re: Complete data erasure

"asaba.takan...@fujitsu.com" writes: > I want to add the feature to erase data so that it cannot be restored > because it prevents attackers from stealing data from released data area. I think this is fairly pointless, unfortunately. Dropping or truncating tables is as much as we can do

Re: TRUNCATE on foreign tables

Hello, The attached patch is the revised version of TRUNCATE on foreign tables. Definition of the callback is revised as follows: typedef void (*ExecForeignTruncate_function) (List *frels_list, bool is_cascade,

Re: Re: Append with naive multiplexing of FDWs

Hello I have tested the patch with a partition table with several foreign partitions living on seperate data nodes. The initial testing was done with a partition table having 3 foreign partitions, test was done with variety of scale facters. The seonnd test was with fixed data per data node but

Re: Append with naive multiplexing of FDWs

Hi Hackers, Sharing the email below from Movead Li, I believe he wanted to share the benchmarking results as a response to this email thread but it started a new thread.. Here it is... " Hello I have tested the patch with a partition table with several foreign partitions living on seperate data

Re: Additional improvements to extended statistics

út 14. 1. 2020 v 0:00 odesílatel Tomas Vondra napsal: > Hi, > > Now that I've committed [1] which allows us to use multiple extended > statistics per table, I'd like to start a thread discussing a couple of > additional improvements for extended statistics. I've considered > starting a separate

Re: Option to dump foreign data in pg_dump

Can you have a look at dump with parallel option. Parallel option will take a lock on table while invoking lockTableForWorker. May be this is not required for foreign tables. Thoughts? I tried with -j and found no issue. I guess that the foreign table needs locking anyway to prevent anyone to

Re: [HACKERS] Block level parallel vacuum

On Tue, Jan 14, 2020 at 10:04 AM Masahiko Sawada wrote: > > On Mon, 13 Jan 2020 at 12:50, Amit Kapila wrote: > > > > On Sat, Jan 11, 2020 at 7:48 PM Masahiko Sawada > > wrote: > > > > Okay, would it better if we get rid of this variable and have code like > > below? > > > > /* Skip the indexes

Re: Errors when update a view with conditional-INSTEAD rules

On Tue, 7 Jan 2020 at 11:00, Dean Rasheed wrote: > > Here's a patch along those lines. Yes, it's a little more code > duplication, but I think it's worth it for the more detailed error. > There was no previous regression test coverage of this case so I added > some (all other test output is

Re: Improve errors when setting incorrect bounds for SSL protocols

> On 14 Jan 2020, at 04:54, Michael Paquier wrote: > > Hi all, > (Daniel G. in CC.) > > As discussed on the thread to be able to set the min/max SSL protocols > with libpq, when mixing incorrect bounds the user experience is not > that good: >

  1   2   >