Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

On Thu, Feb 11, 2021 at 8:22 PM Tom Lane wrote: > > Ashutosh Bapat writes: > > Can this information be part of PathTarget structure and hence part of > > RelOptInfo::reltarget, so that it can be extended to join, group and > > other kinds of RelOptInfo in future? > > Why would that be better than

RE: [POC] Fast COPY FROM command for the table with foreign partitions

From: Andrey V. Lepikhov > On 2/9/21 12:47 PM, tsunakawa.ta...@fujitsu.com wrote: > > As Tang-san and you showed, the basic part already demonstrated > impressive improvement. If there's no objection, I'd like to make this ready > for > committer in a few days. > Good. I've marked this as read

RE: Parallel INSERT (INTO ... SELECT ...)

From: Hou, Zhijie/侯 志杰 > If we diable bitmapscan, the performance degradation seems will not happen. Yes, but that's because the hundreds of times slower sequential scan hides the insert time. Furthermore, as an aside, Worker 3 does much of the work in the parallel sequential scan + parallel i

RE: [HACKERS] logical decoding of two-phase transactions

Hi On Thursday, February 11, 2021 5:10 PM Peter Smith wrote: > Please find attached the new 2PC patch set v39* I started to review the patchset so, let me give some comments I have at this moment. (1) File : v39-0007-Support-2PC-txn-tests-for-concurrent-aborts.patch Modification : @@ -620,6

Re: Possible dereference null return (src/backend/replication/logical/reorderbuffer.c)

At Wed, 10 Feb 2021 20:12:38 -0300, Ranier Vilela wrote in > Hi, > > Per Coverity. > > If xid is a subtransaction, the setup of base snapshot on the top-level > transaction, > can be not optional, otherwise a Dereference null return value > (NULL_RETURNS) can be raised. > > Patch suggestion t

RE: Parallel INSERT (INTO ... SELECT ...)

From: Hou, Zhijie/侯 志杰 > > What would the result look like if you turn off > > parallel_leader_participation? If the leader is freed from > > reading/writing the table and index, the index page splits and > > internal lock contention may decrease enough to recover part of the loss. > > > > https:

Re: Possible dereference after null check (src/backend/executor/ExecUtils.c)

At Wed, 10 Feb 2021 19:54:46 -0300, Ranier Vilela wrote in > Hi, > > Per Coverity. > > The functions ExecGetInsertedCols and ExecGetUpdatedCols at ExecUtils.c > only are safe to call if the variable "ri_RangeTableIndex" is != 0. > > Otherwise a possible Dereference after null check (FORWARD_

Re: Is Recovery actually paused?

At Fri, 12 Feb 2021 13:33:32 +0900, Yugo NAGATA wrote in > I don't think that we need to include the waiting approach in > pg_get_wal_replay_pause_state > patch. However, Horiguchi-san's patch may be useful for some users who want > pg_wal_replay_pause to wait until recovery gets paused instead

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

At Thu, 11 Feb 2021 19:55:45 -0300, Ranier Vilela wrote in > Em qui., 11 de fev. de 2021 às 09:47, Michael Paquier > escreveu: > > > On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote: > > > It is necessary to correct the interfaces. To caller, inform the size of > > > the buffer it

Re: Single transaction in the tablesync worker?

On Fri, Feb 12, 2021 at 10:08 AM Ajin Cherian wrote: > > On Fri, Feb 12, 2021 at 2:46 PM Amit Kapila wrote: > > > > > Thanks, I have pushed the patch but getting one failure: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thorntail&dt=2021-02-12%2002%3A28%3A12 > > > > The reason seem

Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Feb 12, 2021 at 3:21 PM Zhihong Yu wrote: > > Greg: > bq. we should just return parsetree->hasModifyingCTE at this point, > > Maybe you can clarify a bit. > The if (parsetree->hasModifyingCTE) check is followed by if > (!hasModifyingCTE). > When parsetree->hasModifyingCTE is false, !hasMo

RE: libpq debug log

(48) void PQtrace(PGconn *conn, FILE *stream); + + Calls PQtraceSetFlags to output with or without a timestamp. + + Why is this necessary? Even if you decide to remove this change, can you share your idea on why you added this just in case? (49) + Dete

Re: WIP: WAL prefetch (another approach)

Hi, On 2021-02-12 00:42:04 +0100, Tomas Vondra wrote: > Yeah, that's a good point. I think it'd make sense to keep track of recent > FPIs and skip prefetching such blocks. But how exactly should we implement > that, how many blocks do we need to track? If you get an FPI, how long > should we skip

Re: Single transaction in the tablesync worker?

On Fri, Feb 12, 2021 at 2:46 PM Amit Kapila wrote: > > Thanks, I have pushed the patch but getting one failure: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thorntail&dt=2021-02-12%2002%3A28%3A12 > > The reason seems to be that we are trying to connect and > max_wal_senders is set to

Re: Is Recovery actually paused?

On Thu, 11 Feb 2021 16:36:55 +0530 Dilip Kumar wrote: > On Thu, Feb 11, 2021 at 3:20 PM Bharath Rupireddy > wrote: > > > > On Wed, Feb 10, 2021 at 8:39 PM Dilip Kumar wrote: > > > > > > On Wed, Feb 10, 2021 at 10:02 AM Dilip Kumar > > > wrote: > > > > > > > > I don't find any problem with thi

Re: Parallel INSERT (INTO ... SELECT ...)

Greg: bq. we should just return parsetree->hasModifyingCTE at this point, Maybe you can clarify a bit. The if (parsetree->hasModifyingCTE) check is followed by if (!hasModifyingCTE). When parsetree->hasModifyingCTE is false, !hasModifyingCTE would be true, resulting in the execution of the if (!ha

Re: Parallel INSERT (INTO ... SELECT ...)

On Fri, Feb 12, 2021 at 2:33 PM Zhihong Yu wrote: > > For v17-0001-Enable-parallel-SELECT-for-INSERT-INTO-.-SELECT.patch : > > + /* Assume original queries have hasModifyingCTE set correctly */ > + if (parsetree->hasModifyingCTE) > + hasModifyingCTE = true; > > Since hasModif

Re: parse mistake in ecpg connect string

At Thu, 11 Feb 2021 15:23:31 -0500, Tom Lane wrote in > "kuroda.hay...@fujitsu.com" writes: > > Dear Wang, Horiguchi-san, > >>> How about the attached? > > >> I think, this patch is good. > > > I agree. The backward compatibility is violated in the doc, but maybe no > > one take care. > > Pu

Re: Single transaction in the tablesync worker?

On Fri, Feb 12, 2021 at 7:18 AM Ajin Cherian wrote: > > On Thu, Feb 11, 2021 at 10:38 PM Amit Kapila wrote: > > > Okay, attached an updated patch with only that change. > > I ran Erik's test suite [1] on this patch overnight and found no > errors. No more comments from me. The patch looks good. >

Re: Libpq support to connect to standby server as priority

On Fri, Feb 12, 2021 at 7:07 AM Greg Nancarrow wrote: > > On Wed, Feb 10, 2021 at 5:09 PM vignesh C wrote: > > > > Modified. > > These comments are handled in v22 patch posted in my earlier mail. > > > > Thanks, just one minor thing I missed in doc/src/sgml/libpq.sgml. > > +The support of

Re: Parallel INSERT (INTO ... SELECT ...)

Hi, For v17-0001-Enable-parallel-SELECT-for-INSERT-INTO-.-SELECT.patch : + /* Assume original queries have hasModifyingCTE set correctly */ + if (parsetree->hasModifyingCTE) + hasModifyingCTE = true; Since hasModifyingCTE is false by the time the above is run, it can be simp

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

On Thu, Feb 11, 2021 at 9:09 PM Ashutosh Bapat wrote: > Can this information be part of PathTarget structure and hence part of > RelOptInfo::reltarget, so that it can be extended to join, group and > other kinds of RelOptInfo in future? I think you want to expand this field in a more generic wa

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Thank you all, friends! On Fri, Feb 12, 2021 at 9:02 AM David Rowley wrote: > On Wed, 10 Feb 2021 at 16:18, Andy Fan wrote: > > v1-0001-Introduce-notnullattrs-field-in-RelOptInfo-to-ind.patch > > > > Introduce notnullattrs field in RelOptInfo to indicate which attr are > not null > > in current

Re: Single transaction in the tablesync worker?

On Thu, Feb 11, 2021 at 10:38 PM Amit Kapila wrote: > Okay, attached an updated patch with only that change. I ran Erik's test suite [1] on this patch overnight and found no errors. No more comments from me. The patch looks good. regards, Ajin Cherian Fujitsu Australia [1]- https://www.postgr

pg13.2: invalid memory alloc request size NNNN

ts=# \errverbose ERROR: XX000: invalid memory alloc request size 18446744073709551613 #0 pg_re_throw () at elog.c:1716 #1 0x00a33b12 in errfinish (filename=0xbff20e "mcxt.c", lineno=959, funcname=0xbff2db <__func__.6684> "palloc") at elog.c:502 #2 0x00a6760d in palloc (size=1

Re: Libpq support to connect to standby server as priority

On Wed, Feb 10, 2021 at 5:09 PM vignesh C wrote: > > Modified. > These comments are handled in v22 patch posted in my earlier mail. > Thanks, just one minor thing I missed in doc/src/sgml/libpq.sgml. +The support of read-write transactions is determined by the value of the +defau

Re: Detecting pointer misalignment (was Re: pgsql: Implementation of subscripting for jsonb)

On Thu, Feb 11, 2021 at 9:46 PM Tom Lane wrote: > Alexander Korotkov writes: > > On Mon, Feb 8, 2021 at 7:49 PM Tom Lane wrote: > >> Ugh, no it isn't: even pretty recent clang releases only define > >> __GNUC__ as 4. It looks like we need a separate test on clang's > >> version. I looked at th

[DOC] add missing "[ NO ]" to various "DEPENDS ON" synopses

Greetings We have following syntax: ALTER THING name [ NO ] DEPENDS ON EXTENSION name for the following THINGs: - ALTER TRIGGER - ALTER FUNCTION - ALTER PROCEDURE - ALTER ROUTINE - ALTER MATERIALIZED VIEW - ALTER INDEX In the documentation, the "[ NO ]" option is listed in the synopsis for

RE: libpq debug log

Hi all, Thank you for your review. I update patch to v17. > From: Tsunakawa, Takayuki/綱川 貴之 > Sent: Tuesday, February 9, 2021 11:26 AM > (45) ... > The description of PQtrace() should be written independent of PQtraceEx(). > It is an unnecessary implementation detail to the user that PQtrace()

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

On Wed, 10 Feb 2021 at 16:18, Andy Fan wrote: > v1-0001-Introduce-notnullattrs-field-in-RelOptInfo-to-ind.patch > > Introduce notnullattrs field in RelOptInfo to indicate which attr are not null > in current query. The not null is judged by checking pg_attribute and query's > restrictinfo. The inf

Re: WIP: WAL prefetch (another approach)

On 2/10/21 10:50 PM, Stephen Frost wrote: > ... > +/* + * Scan the current record for block references, and consider prefetching. + * + * Return true if we processed the current record to completion and still have + * queue space to process a new record, and false if we saturated the I/O + * qu

Re: parse_slash_copy doesn't support psql variables substitution

On Wed, Feb 10, 2021 at 8:33 AM Pavel Stehule wrote: > Hi > > Is there some reason why \copy statement (parse_slash_copy parser) doesn't > support psql variables? > > Regards > > Pavel > I remember wondering about that when I was working on the \if stuff. I dug into it a bit, but the problem was

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Em qui., 11 de fev. de 2021 às 09:47, Michael Paquier escreveu: > On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote: > > It is necessary to correct the interfaces. To caller, inform the size of > > the buffer it created. > > Now, the patch you sent has no need to be that complicated,

Re: Parallel Full Hash Join

On Tue, Dec 29, 2020 at 03:28:12PM +1300, Thomas Munro wrote: > I had some feedback I meant to > post in November but didn't get around to: > > * PHJ_BATCH_PROBING-- all probe > - * PHJ_BATCH_DONE -- end > + > + * PHJ_BATCH_DONE -- queries not requiring inner fill

Re: Is Recovery actually paused?

On Thu, Feb 11, 2021 at 6:07 AM Dilip Kumar wrote: > > Thanks for the patch. I tested the new function and it works as > > expected. I have no further comments on the v13 patch. > > Thanks for the review and testing. I don't see a whole lot wrong with this patch, but I think there are some things

Re: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)

Em qui., 11 de fev. de 2021 às 14:51, Tom Lane escreveu: > Ranier Vilela writes: > > Em qui., 11 de fev. de 2021 às 01:46, Tom Lane > escreveu: > >> At the same time, I think this code could be improved; but the way > >> to do that is to use strtoint(), rather than kluging the choice of > >> da

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

>On Thu, Feb 11, 2021, at 16:50, Mark Rofail wrote: >> Here comes a first review of the anyarray_anyelement_operators-v1.patch. >Great, thanks! I’ll start applying your comments today and release a new patch. Here comes some more feedback: I was surprised to see <<@ and @>> don't complain when tr

Re: Detecting pointer misalignment (was Re: pgsql: Implementation of subscripting for jsonb)

On Tue, Feb 9, 2021 at 1:34 PM Alexander Korotkov wrote: > Could we have both cfbot + buildfarm animals? Hi Alexander, For cfbot, yeah it does seem like a good idea to throw whatever code sanitiser stuff we can into the automated tests, especially stuff that isn't prone to false alarms. Can you

Re: Proposal: Save user's original authenticated identity for logging

On Mon, 2021-02-08 at 23:35 +, Jacob Champion wrote: > Note that I haven't compiled or tested on > Windows and BSD yet, so the SSPI and BSD auth changes are eyeballed for > now. I've now tested on both. > - For the SSPI auth method, I pick the format of the identity string > based on the comp

Re: parse mistake in ecpg connect string

"kuroda.hay...@fujitsu.com" writes: > Dear Wang, Horiguchi-san, >>> How about the attached? >> I think, this patch is good. > I agree. The backward compatibility is violated in the doc, but maybe no one > take care. Pushed with a little more work on the documentation.

Re: Tightening up allowed custom GUC names

On 2/11/21 1:32 PM, Tom Lane wrote: > Noah Misch writes: >> On Tue, Feb 09, 2021 at 05:34:37PM -0500, Tom Lane wrote: >>> * A case could be made for tightening things up a lot more, and not >>> allowing anything that doesn't look like an identifier. I'm not >>> pushing for that, as it seems mor

Re: Tightening up allowed custom GUC names

On Tue, Feb 9, 2021 at 6:02 PM Noah Misch wrote: > > * A case could be made for tightening things up a lot more, and not > > allowing anything that doesn't look like an identifier. I'm not > > pushing for that, as it seems more likely to break existing > > applications than the narrow restriction

Re: repeated decoding of prepared transactions

On Thu, Feb 11, 2021 at 5:37 AM Amit Kapila wrote: > to explain the exact case to you which is not very apparent. The basic > idea is that we ship/replay all transactions where commit happens > after the snapshot has a consistent state (SNAPBUILD_CONSISTENT), see > atop snapbuild.c for details. No

Re: Tightening up allowed custom GUC names

чц, 11 лют 2021, 21:33 карыстальнік Tom Lane напісаў: > Noah Misch writes: > > On Tue, Feb 09, 2021 at 05:34:37PM -0500, Tom Lane wrote: > >> * A case could be made for tightening things up a lot more, and not > >> allowing anything that doesn't look like an identifier. I'm not > >> pushing for

Re: Allowing create database within transaction block

Hari Sankar writes: > I wanted to see why we do not allow the following statements to be allowed > within a transaction block: > 1. Create database > 2. Drop Database > Is there a detailed reasoning behind disallowing the above statements as > part of the design. Will appreciate it if someone can

Re: Detecting pointer misalignment (was Re: pgsql: Implementation of subscripting for jsonb)

Alexander Korotkov writes: > On Mon, Feb 8, 2021 at 7:49 PM Tom Lane wrote: >> Ugh, no it isn't: even pretty recent clang releases only define >> __GNUC__ as 4. It looks like we need a separate test on clang's >> version. I looked at their version history and sanitizers seem >> to have come in

Re: Tightening up allowed custom GUC names

Noah Misch writes: > On Tue, Feb 09, 2021 at 05:34:37PM -0500, Tom Lane wrote: >> * A case could be made for tightening things up a lot more, and not >> allowing anything that doesn't look like an identifier. I'm not >> pushing for that, as it seems more likely to break existing >> applications t

Re: Extensibility of the PostgreSQL wire protocol

On Wed, Feb 10, 2021 at 11:04 AM Tom Lane wrote: > "Jonah H. Harris" writes: > > On Wed, Feb 10, 2021 at 1:10 PM Tom Lane wrote: > >> ... If we start having > >> modes for MySQL identifier quoting, Oracle outer join syntax, yadda > >> yadda, it's going to be way more of a maintenance nightmare

Re: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)

Ranier Vilela writes: > Em qui., 11 de fev. de 2021 às 01:46, Tom Lane escreveu: >> At the same time, I think this code could be improved; but the way >> to do that is to use strtoint(), rather than kluging the choice of >> datatype even further. > No matter the function used strtol or strtoint,

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Hey Joel, > Here comes a first review of the anyarray_anyelement_operators-v1.patch. Great, thanks! I’ll start applying your comments today and release a new patch. /Mark

Re: Extensibility of the PostgreSQL wire protocol

On Thu, Feb 11, 2021 at 10:29 AM Andrew Dunstan wrote: > > On 2/11/21 10:06 AM, Tom Lane wrote: > > Robert Haas writes: > >> On Thu, Feb 11, 2021 at 9:42 AM Jonah H. Harris > wrote: > >>> As Jan said in his last email, they're not proposing all the different > >>> aspects needed. In fact, nothi

Re: Extensibility of the PostgreSQL wire protocol

On 2/11/21 10:06 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 11, 2021 at 9:42 AM Jonah H. Harris >> wrote: >>> As Jan said in his last email, they're not proposing all the different >>> aspects needed. In fact, nothing has actually been proposed yet. This >>> is an entirely philos

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Hi Mark, On Mon, Feb 8, 2021, at 09:40, Mark Rofail wrote: > anyarray_anyelement_operators-v1.patch Here comes a first review of the anyarray_anyelement_operators-v1.patch. doc/src/sgml/func.sgml +Does the array contain specified element ? * Maybe remove the extra blank space before que

Re: Extensibility of the PostgreSQL wire protocol

Robert Haas writes: > On Thu, Feb 11, 2021 at 9:42 AM Jonah H. Harris > wrote: >> As Jan said in his last email, they're not proposing all the different >> aspects needed. In fact, nothing has actually been proposed yet. This >> is an entirely philosophical debate. I don't even know what's being

Re: Extensibility of the PostgreSQL wire protocol

On Thu, Feb 11, 2021 at 9:42 AM Jonah H. Harris wrote: > I'm quite sure I said I'd open source my MySQL implementation, which allows > Postgres to appear to MySQL clients as a MySQL/MariaDB server. This is > neither proprietary nor Amazon-related and makes Postgres substantially more > useful f

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Ashutosh Bapat writes: > Can this information be part of PathTarget structure and hence part of > RelOptInfo::reltarget, so that it can be extended to join, group and > other kinds of RelOptInfo in future? Why would that be better than keeping it in RelOptInfo? regards, t

Re: [HACKERS] Custom compression methods

On Thu, Feb 11, 2021 at 7:36 AM Dilip Kumar wrote: > W.R.T the attached patch, In HeapTupleHeaderGetDatum, we don't even > attempt to detoast if there is no external field in the tuple, in POC > I have got rid of that check, but I think we might need to do better. > Maybe we can add a flag in info

Re: Improvements and additions to COPY progress reporting

On Thu, Feb 11, 2021, 8:08 PM Josef Šimánek wrote: > čt 11. 2. 2021 v 15:27 odesílatel Matthias van de Meent > napsal: > > > > On Wed, 10 Feb 2021 at 07:43, Bharath Rupireddy > > wrote: > > > > > > On Tue, Feb 9, 2021 at 6:02 PM Matthias van de Meent > > > wrote: > > > > > Also, you can add th

Re: Extensibility of the PostgreSQL wire protocol

On Thu, Feb 11, 2021 at 9:28 AM Robert Haas wrote: > That being said, I'm not in favor of transferring maintenance work to > the community for this set of hooks any more than I am for something > on the parsing side. In general, I'm in favor of as much extensibility > as we can reasonably create,

Re: Improvements and additions to COPY progress reporting

čt 11. 2. 2021 v 15:27 odesílatel Matthias van de Meent napsal: > > On Wed, 10 Feb 2021 at 07:43, Bharath Rupireddy > wrote: > > > > On Tue, Feb 9, 2021 at 6:02 PM Matthias van de Meent > > wrote: > > > > Also, you can add this to the current commitfest. > > > > > > See https://commitfest.postgr

Re: ERROR: invalid spinlock number: 0

On 2021/02/11 21:55, Michael Paquier wrote: Hi Fujii-san, On Tue, Feb 09, 2021 at 11:17:04PM +0900, Fujii Masao wrote: ISTM that the commit 2c8dd05d6c caused this issue. The commit changed pg_stat_get_wal_receiver() so that it reads "writtenUpto" by using pg_atomic_read_u64(). But since "writ

Re: Extensibility of the PostgreSQL wire protocol

On Wed, Feb 10, 2021 at 2:04 PM Tom Lane wrote: > That is a spot-on definition of where I do NOT want to end up. Hooks > everywhere and enormous extensions that break anytime we change anything > in the core. It's not really clear that anybody is going to find that > more maintainable than a str

Re: Improvements and additions to COPY progress reporting

On Wed, 10 Feb 2021 at 07:43, Bharath Rupireddy wrote: > > On Tue, Feb 9, 2021 at 6:02 PM Matthias van de Meent > wrote: > > > Also, you can add this to the current commitfest. > > > > See https://commitfest.postgresql.org/32/2977/ > > > > On Tue, 9 Feb 2021 at 12:53, Josef Šimánek wrote: > > >

Re: Transactions involving multiple postgres foreign servers, take 2

On Fri, Feb 5, 2021 at 2:45 PM Masahiko Sawada wrote: > > On Tue, Feb 2, 2021 at 5:18 PM Fujii Masao > wrote: > > > > > > > > On 2021/01/27 14:08, Masahiko Sawada wrote: > > > On Wed, Jan 27, 2021 at 10:29 AM Fujii Masao > > > wrote: > > >> > > >> > > >> You fixed some issues. But maybe you for

Re: TRUNCATE on foreign table

On Wed, Feb 10, 2021 at 10:58 PM Kazutaka Onishi wrote: > > That's because using the foreign server is difficult for the user. > > For example, the user doesn't always have the permission to login to the > forein server. > In some cases, the foreign table has been created by the administrator tha

Add tests for bytea LIKE operator

A few more easy tests for things not covered at all: bytea LIKE bytea (bytealike) bytea NOT LIKE bytea (byteanlike) ESCAPE clause for the above (like_escape_bytea) also name NOT ILIKE text (nameicnlike) See also

Re: libpq compression

On 11.02.2021 16:09, Daniil Zakhlystov wrote: Hi! On 09.02.2021 09:06, Konstantin Knizhnik wrote: Sorry, but my interpretation of your results is completely different: permanent compression is faster than chunked compression (2m15 vs. 2m27) and consumes less CPU (44 vs 48 sec). Size of RX d

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Em qui., 11 de fev. de 2021 às 09:47, Michael Paquier escreveu: > On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote: > > It is necessary to correct the interfaces. To caller, inform the size of > > the buffer it created. > > Well, Coverity likes nannyism, so each one of its reports is

Re: Online checksums patch - once again

On Wed, Feb 10, 2021 at 01:26:18PM -0500, Bruce Momjian wrote: > On Wed, Feb 10, 2021 at 03:25:58PM +0100, Magnus Hagander wrote: > > A fairly large amount of this complexity comes out of the fact that it > > now supports restarting and tracks checksums on a per-table basis. We > > skipped this in

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Can this information be part of PathTarget structure and hence part of RelOptInfo::reltarget, so that it can be extended to join, group and other kinds of RelOptInfo in future? In fact, it might be easy to do that in this patch itself. On Wed, Feb 10, 2021 at 8:57 AM Andy Fan wrote: > > > On Wed,

Re: libpq compression

Hi! > On 09.02.2021 09:06, Konstantin Knizhnik wrote: > > Sorry, but my interpretation of your results is completely different: > permanent compression is faster than chunked compression (2m15 vs. 2m27) > and consumes less CPU (44 vs 48 sec). > Size of RX data is slightly larger - 0.5Mb but TX s

Re: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)

Em qui., 11 de fev. de 2021 às 01:46, Tom Lane escreveu: > Ranier Vilela writes: > > *long* 4 *long int*, *signed long int* -2.147.483.648 a 2.147.483.647 > > Therefore long never be > INT_MAX at Windows 64 bits. > > Thus lindex is always false in this expression: > > if (errno != 0 || badp == c

Re: ERROR: invalid spinlock number: 0

Hi Fujii-san, On Tue, Feb 09, 2021 at 11:17:04PM +0900, Fujii Masao wrote: > ISTM that the commit 2c8dd05d6c caused this issue. The commit changed > pg_stat_get_wal_receiver() so that it reads "writtenUpto" by using > pg_atomic_read_u64(). But since "writtenUpto" is initialized only when > walrece

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote: > It is necessary to correct the interfaces. To caller, inform the size of > the buffer it created. Well, Coverity likes nannyism, so each one of its reports is to take with a pinch of salt, so there is no point to change something tha

Re: [HACKERS] Custom compression methods

On Thu, Feb 11, 2021 at 3:26 AM Robert Haas wrote: > > On Wed, Feb 10, 2021 at 3:06 PM Robert Haas wrote: > > I think you have a fairly big problem with row types. Consider this example: > > > > create table t1 (a int, b text compression pglz); > > create table t2 (a int, b text compression lz4);

Re: repeated decoding of prepared transactions

Hello Amit, thanks a lot for your extensive explanation and examples, I appreciate this very much. I'll need to think this through and see how we can make this work for us. Best Regards Markus

Re: Dump public schema ownership & seclabels

On Sun, Jan 17, 2021 at 12:00:06PM +0100, Vik Fearing wrote: > On 1/17/21 10:41 AM, Noah Misch wrote: > > On Sat, Jan 16, 2021 at 02:05:43PM +0100, Vik Fearing wrote: > >> On 12/30/20 12:59 PM, Noah Misch wrote: > >>> On Tue, Dec 29, 2020 at 05:49:24AM -0800, Noah Misch wrote: > https://postgr

Re: Single transaction in the tablesync worker?

On Thu, Feb 11, 2021 at 3:32 PM Petr Jelinek wrote: > > On 11 Feb 2021, at 10:56, Amit Kapila wrote: > > > >> Well, I was thinking it could be NOTICE or LOG to be honest, WARNING seems > >> unnecessarily scary for those usecases to me. > >> > > > > I am fine with LOG and will make that change. D

Re: Is Recovery actually paused?

On Thu, Feb 11, 2021 at 3:20 PM Bharath Rupireddy wrote: > > On Wed, Feb 10, 2021 at 8:39 PM Dilip Kumar wrote: > > > > On Wed, Feb 10, 2021 at 10:02 AM Dilip Kumar wrote: > > > > > > I don't find any problem with this approach as well, but I personally > > > feel that the other approach where w

Re: repeated decoding of prepared transactions

On Mon, Feb 8, 2021 at 2:01 PM Markus Wanner wrote: > > I did not expect this, as any receiver that wants to have decoded 2PC is > likely supporting some kind of two-phase commits itself. And would > therefore prepare the transaction upon its first reception. Potentially > receiving it a second

Re: Single transaction in the tablesync worker?

On 11 Feb 2021, at 10:56, Amit Kapila wrote: > > On Thu, Feb 11, 2021 at 3:20 PM Petr Jelinek > wrote: >> >> On 11 Feb 2021, at 10:42, Amit Kapila wrote: >>> >>> On Thu, Feb 11, 2021 at 1:51 PM Petr Jelinek >>> wrote: On 10 Feb 2021, at 06:32, Amit Kapila wrote: > > On W

Re: Single transaction in the tablesync worker?

On Thu, Feb 11, 2021 at 3:20 PM Petr Jelinek wrote: > > On 11 Feb 2021, at 10:42, Amit Kapila wrote: > > > > On Thu, Feb 11, 2021 at 1:51 PM Petr Jelinek > > wrote: > >> > >> On 10 Feb 2021, at 06:32, Amit Kapila wrote: > >>> > >>> On Wed, Feb 10, 2021 at 7:41 AM Peter Smith wrote: > > >>

Re: Single transaction in the tablesync worker?

On 11 Feb 2021, at 10:42, Amit Kapila wrote: > > On Thu, Feb 11, 2021 at 1:51 PM Petr Jelinek > wrote: >> >> On 10 Feb 2021, at 06:32, Amit Kapila wrote: >>> >>> On Wed, Feb 10, 2021 at 7:41 AM Peter Smith wrote: On Tue, Feb 9, 2021 at 10:38 AM Peter Smith wrote: > >>>

Re: Is Recovery actually paused?

On Wed, Feb 10, 2021 at 8:39 PM Dilip Kumar wrote: > > On Wed, Feb 10, 2021 at 10:02 AM Dilip Kumar wrote: > > > > I don't find any problem with this approach as well, but I personally > > feel that the other approach where we don't wait in any API and just > > return the recovery pause state is

Re: Single transaction in the tablesync worker?

On Thu, Feb 11, 2021 at 1:51 PM Petr Jelinek wrote: > > On 10 Feb 2021, at 06:32, Amit Kapila wrote: > > > > On Wed, Feb 10, 2021 at 7:41 AM Peter Smith wrote: > >> > >> On Tue, Feb 9, 2021 at 10:38 AM Peter Smith wrote: > >>> > >> > >> PSA v2 of this WalRcvExceResult patch (it is same as v1 bu

Re: Single transaction in the tablesync worker?

On 10 Feb 2021, at 06:32, Amit Kapila wrote: > > On Wed, Feb 10, 2021 at 7:41 AM Peter Smith wrote: >> >> On Tue, Feb 9, 2021 at 10:38 AM Peter Smith wrote: >>> >> >> PSA v2 of this WalRcvExceResult patch (it is same as v1 but includes >> some PG doc updates). >> This applies OK on top of v3

Re: SQL-standard function body

On 2020-11-20 08:25, Peter Eisentraut wrote: On 2020-11-10 16:21, Georgios Kokolatos wrote: Hi, I noticed that this patch fails on the cfbot. For this, I changed the status to: 'Waiting on Author'. Cheers, //Georgios The new status of this patch is: Waiting on Author Here is an updated pat