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 p

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 nu

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

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: > https://www.postgresql.org/message-id/9cfa34ee-f670

Re: [HACKERS] WAL logging problem in 9.4.3?

Hello, this is a fix for the defect 1 of 3. At Thu, 26 Dec 2019 12:46:39 +0900 (JST), Kyotaro Horiguchi wrote in > Thank you for the findings. > > At Wed, 25 Dec 2019 16:15:21 -0800, Noah Misch wrote in > > By improving AssertPendingSyncs_RelationCache() and by testing with > > -DRELCACHE_FO

Re: [HACKERS] Block level parallel vacuum

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 Jan 2020 at 15:51, Sergei Kornilov wrote: > > > > > > Hi > > > Thank you for update! I looked again > > > > > > (vacuum_indexes_leader) > > > +

Re: [HACKERS] Block level parallel vacuum

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 Jan 2020 at 15:51, Sergei Kornilov wrote: > > > > > > > > Hi > > > > Thank you for upda

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 modi

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: [HACKERS] Block level parallel vacuum

On Tue, Jan 14, 2020 at 4:17 PM Mahendra Singh Thalor wrote: > > Hi, > > +/* > + * Try to initialize the parallel vacuum if requested > + */ > +if (params->nworkers >= 0 && vacrelstats->useindex) > +{ > +/* > + * Since parallel workers cannot access data in temp

Re: ALTER TABLE support for dropping generation expression

On 2020-01-13 10:56, Sergei Kornilov wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Thank you! Looks go

Re: [Proposal] Global temporary tables

Thank you for review my patch. > 2020年1月12日 上午4:27，Pavel Stehule 写道： > > Hi > > so 11. 1. 2020 v 15:00 odesílatel 曾文旌(义从) > napsal: > Hi all > > This is the latest patch > > The updates are as follows: > 1. Support global temp Inherit table global temp pa

Re: [Proposal] Global temporary tables

ú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 odesílatel 曾文旌(义从) > napsal: > >> Hi all >> >> This is the latest patch >> >> The updates are as follows: >> 1. Support global temp Inhe

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 replicat

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

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 odes

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 no

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

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 an

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 sha2_

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

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

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 s

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

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

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 valida

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

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 t

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 c

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

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

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 rewr

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 itself

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

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 pg_write_server_f

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

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 ac

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 have

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 so

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": https://www.postgresql.org/docs/12/xfunc-o

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 the

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

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: > > https://www.postgresql.org/message-id/fl

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 posit

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

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 H

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

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

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

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

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 ultimate

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 prov

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 +++ b/src/backend/statistic

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

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 t

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) &&IsA(rightop, Const)) Yeah, it's been doing that for decades. I think the triggering factor

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

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 bi

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

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 f

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

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 to

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 t

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

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 t

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

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 wo

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 sy

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 ar

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 i

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 Man

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

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 wro

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 o

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 without

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

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 thi

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 agre

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

  1   2   >