Re: Berserk Autovacuum (let's save next Mandrill)

On Fri, Mar 13, 2020 at 02:38:51PM -0700, Andres Freund wrote: > On 2020-03-13 13:44:42 -0500, Justin Pryzby wrote: > > Having now played with the patch, I'll suggest that 1000 is too high a > > threshold. If autovacuum runs without FREEZE, I don't see why it couldn't > > be > > much lower

Re: plan cache overhead on plpgsql expression

čt 19. 3. 2020 v 10:47 odesílatel Amit Langote napsal: > Hi Pavel, > > Sorry it took me a while to look at this. > > On Tue, Feb 25, 2020 at 4:28 AM Pavel Stehule > wrote: > > po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule > napsal: > >> But I found one issue - I don't know if this issue is

Re: WAL usage calculation patch

On 2020/03/19 2:19, Julien Rouhaud wrote: On Wed, Mar 18, 2020 at 09:02:58AM +0300, Kirill Bychik wrote: There is a higher-level Instrumentation API that can be used with INSTRUMENT_WAL flag to collect the wal usage information. I believe the instrumentation is widely used in the executor

Re: [Proposal] Global temporary tables

postgres=# CREATE LOCAL TEMPORARY TABLE gtt1(c1 serial PRIMARY KEY, c2 VARCHAR (50) UNIQUE NOT NULL) ON COMMIT DELETE ROWS; CREATE TABLE postgres=# CREATE LOCAL TEMPORARY TABLE gtt2(c1 integer NOT NULL, c2 integer NOT NULL, postgres(# PRIMARY KEY (c1, c2), postgres(# FOREIGN KEY (c1) REFERENCES

Re: [PATCH] Add schema and table names to partition error

Thank you Chris, Amit. On Thu, Mar 19, 2020 at 1:46 PM Amit Kapila wrote: > On Thu, Mar 19, 2020 at 3:55 AM Chris Bandy wrote: > > > > > > Sorry for these troubles. Attached are patches created using `git > > format-patch -n -v6` on master at 487e9861d0. > > > > No problem. I have extracted

Re: PG v12.2 - Setting jit_above_cost is causing the server to crash

Hi, On Thu, Feb 27, 2020 at 6:23 PM Dave Page wrote: > Hi > > On Thu, Feb 27, 2020 at 12:41 PM Tom Lane wrote: > >> Aditya Toshniwal writes: >> > On Mon, Feb 24, 2020 at 12:46 PM Andres Freund >> wrote: >> >> This isn't reproducible here. Are you sure that you're running on a >> >> clean

Re: Print physical file path when checksum check fails

I have updated the patch based on the previous comments. Sorry for the late patch. I removed `SetZeroDamagedPageInChecksum` and add `zeroDamagePage` flag in smgrread to determine whether we should zero damage page when an error happens. It depends on the caller. `GetRelationFilePath` is removed

Re: Auxiliary Processes and MyAuxProc

On 2020-03-18 17:07, Mike Palmiotto wrote: On Wed, Mar 18, 2020 at 11:26 AM Mike Palmiotto wrote: On Wed, Mar 18, 2020 at 10:17 AM Justin Pryzby wrote: Also, I saw this was failing tests both before and after my rebase. http://cfbot.cputube.org/

Re: WIP/PoC for parallel backup

Hi Asif, In another scenarios, bkp data is corrupted for tablespace. again this is not reproducible everytime, but If I am running the same set of commands I am getting the same error. [edb@localhost bin]$ ./pg_ctl -D data -l logfile start waiting for server to start done server started

Re: Wait event that should be reported while waiting for WAL archiving to finish

On Wed, Feb 26, 2020 at 9:19 PM Fujii Masao wrote: > I have no idea about this. But I wonder how much that change > is helpful to reduce the power consumption because waiting > for WAL archive during the backup basically not so frequently > happens. > +1. And as far as I reviewed the patch, I

Re: [PATCH] Skip llvm bytecode generation if LLVM is missing

On 2020-03-15 02:28, Craig Ringer wrote: On Fri, 13 Mar 2020 at 15:04, Andres Freund > wrote: On 2020-03-13 14:08:12 +0800, Craig Ringer wrote: > The alternative would be to detect a missing clang and emit a much more > informative error than the

Re: Berserk Autovacuum (let's save next Mandrill)

On Thu, 19 Mar 2020 at 18:45, Laurenz Albe wrote: > > On Tue, 2020-03-17 at 18:02 -0700, Andres Freund wrote: > > I don't think a default scale factor of 0 is going to be ok. For > > large-ish tables this will basically cause permanent vacuums. And it'll > > sometimes trigger for tables that

Re: Berserk Autovacuum (let's save next Mandrill)

On Thu, 19 Mar 2020 at 19:07, Justin Pryzby wrote: > > On Fri, Mar 13, 2020 at 02:38:51PM -0700, Andres Freund wrote: > > On 2020-03-13 13:44:42 -0500, Justin Pryzby wrote: > > > Having now played with the patch, I'll suggest that 1000 is too high a > > > threshold. If autovacuum runs

Re: Internal key management system

On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada wrote: > > Sending to pgsql-hackers again. > > On Tue, 17 Mar 2020 at 03:18, Bruce Momjian > wrote: > > > > On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote: > > > On Thu, 12 Mar 2020 at 08:13, Bruce Momjian > > > wrote: > > > > > > >

Re: RecoveryWalAll and RecoveryWalStream wait events

On 2020/03/18 22:37, Atsushi Torikoshi wrote: On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote: I meant the following part in the doc. - At startup, the standby begins by restoring all WAL available in the archive

Re: PATCH: Add uri percent-encoding for binary data

> On 4 Mar 2020, at 12:25, Daniel Gustafsson wrote: > >> On 20 Feb 2020, at 23:27, Alvaro Herrera wrote: >> >> On 2019-Oct-07, Anders Åstrand wrote: >> >>> Attached is a patch for adding uri as an encoding option for >>> encode/decode. It uses what's called "percent-encoding" in rfc3986 >>>

Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

On 2020/03/19 1:13, Fujii Masao wrote: On 2020/03/19 0:37, Magnus Hagander wrote: On Wed, Mar 11, 2020 at 5:53 AM Fujii Masao wrote: On 2020/03/11 3:39, Magnus Hagander wrote: On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao wrote: On 2020/03/10 22:43, Amit Langote wrote: On Tue,

Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

On 2020/03/19 12:02, Amit Langote wrote: On Thu, Mar 19, 2020 at 11:45 AM Fujii Masao wrote: On 2020/03/19 11:32, Amit Langote wrote: On Thu, Mar 19, 2020 at 11:24 AM Alvaro Herrera wrote: On 2020-Mar-19, Amit Langote wrote: Magnus' idea of checking the values in

Re: truncating timestamps on arbitrary intervals

Hello, On 3/13/2020 4:13 PM, John Naylor wrote: I've put off adding documentation on the origin piece pending comments about the approach. I haven't thought seriously about timezone yet, but hopefully it's just work and nothing to think too hard about. Thank you for the patch. I looked it

Re: plan cache overhead on plpgsql expression

Hi Pavel, Sorry it took me a while to look at this. On Tue, Feb 25, 2020 at 4:28 AM Pavel Stehule wrote: > po 24. 2. 2020 v 18:56 odesílatel Pavel Stehule > napsal: >> But I found one issue - I don't know if this issue is related to your patch >> or plpgsql_check. >> >> plpgsql_check try to

Re: Memory-Bounded Hash Aggregation

On Sun, Mar 15, 2020 at 04:05:37PM -0700, Jeff Davis wrote: > > + if (from_tape) > > + partition_mem += HASHAGG_READ_BUFFER_SIZE; > > + partition_mem = npartitions * HASHAGG_WRITE_BUFFER_SIZE; > > > > => That looks wrong ; should say += ? > > Good catch! Fixed. > +++

Re: Internal key management system

Sending to pgsql-hackers again. On Tue, 17 Mar 2020 at 03:18, Bruce Momjian wrote: > > On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote: > > On Thu, 12 Mar 2020 at 08:13, Bruce Momjian > > wrote: > > > > > > On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote: > > > >

Re: adding partitioned tables to publications

On 2020-03-18 15:19, Amit Langote wrote: On Wed, Mar 18, 2020 at 8:16 PM Peter Eisentraut wrote: On 2020-03-18 04:06, Amit Langote wrote: + if (isnull || !remote_is_publishable) + ereport(ERROR, + (errmsg("table \"%s.%s\" on the publisher is not publishable", +

RE: ssl passphrase callback

Hello Andrew, From: Andreas Karlsson > # Nitpicking > > The certificate expires in 2030 while all other certificates used in > tests expires in 2046. Should we be consistent? > > There is text in server.crt and server.key, while other certificates and > keys used in the tests do not have this.

Re: Cache lookup errors with functions manipulation object addresses

> On 17 Oct 2019, at 03:37, Michael Paquier wrote: > Attached is an updated > patch set with the heap_close() calls removed as per the recent report > from Dmitry. Taking a look at this to see if we can achieve closure on this long-running patchset. The goal of the patch is IMO a clear win for

Re: Optimizer Doesn't Push Down Where Expressions on Rollups

Hi, (cc'ing -hackers) We used to push down clauses from HAVING to WHERE when grouping sets are used in 61444bfb and then reverted it in a6897efa because of wrong results issue. As now there are people suffering from performance issue as described in [1], I'm wondering if we should give it

Re: error context for vacuum to include block number

On Thu, Mar 19, 2020 at 9:38 AM Justin Pryzby wrote: > > On Thu, Mar 19, 2020 at 08:20:51AM +0530, Amit Kapila wrote: > > > > Few other comments: > > > 1. The error in lazy_vacuum_heap can either have phase > > > VACUUM_ERRCB_PHASE_INDEX_* or VACUUM_ERRCB_PHASE_VACUUM_HEAP depending > > > on when

Re: Internal key management system

On Thu, 19 Mar 2020 at 18:32, Masahiko Sawada wrote: > > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada > wrote: > > > > Sending to pgsql-hackers again. > > > > On Tue, 17 Mar 2020 at 03:18, Bruce Momjian > > wrote: > > > > > > On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote: > >

Re: [Proposal] Global temporary tables

On Thu, Mar 19, 2020 at 3:51 PM wenjing.zwj wrote: > postgres=# CREATE LOCAL TEMPORARY TABLE gtt1(c1 serial PRIMARY KEY, c2 > VARCHAR (50) UNIQUE NOT NULL) ON COMMIT DELETE ROWS; > CREATE TABLE > postgres=# CREATE LOCAL TEMPORARY TABLE gtt2(c1 integer NOT NULL, c2 > integer NOT NULL, >

Re: Internal key management system

On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote: > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada > > I understand that your idea is to include fixed length string to the > > 256 bit key in order to separate key space. But if we do that, I think > > that the key strength would

Re: Don't try fetching future segment of a TLI.

Hi, I've tested patch provided by Kyotaro and do confirm it fixes the issue. Any chance it will be merged to one of the next minor releases? Thank you very much! сб, 1 февр. 2020 г. в 08:31, David Steele : > On 1/28/20 8:02 PM, Kyotaro Horiguchi wrote: > > At Tue, 28 Jan 2020 19:13:32 +0300,

Re: adding partitioned tables to publications

On 2020-03-18 08:33, Amit Langote wrote: By the way, I have rebased the patches, although maybe you've got your own copies; attached. Looking through 0002 and 0003 now. The structure looks generally good. In 0002, the naming of apply_handle_insert() vs. apply_handle_do_insert() etc. seems a

Re: Berserk Autovacuum (let's save next Mandrill)

On Thu, Mar 19, 2020 at 09:52:11PM +1300, David Rowley wrote: > On Thu, 19 Mar 2020 at 19:07, Justin Pryzby wrote: > > > > On Fri, Mar 13, 2020 at 02:38:51PM -0700, Andres Freund wrote: > > > On 2020-03-13 13:44:42 -0500, Justin Pryzby wrote: > > > > Having now played with the patch, I'll suggest

Re: GSoC applicant proposal, Uday PB

Hi, On 3/18/20 1:11 AM, p.b uday wrote: > summer. Below is my draft proposal for your review. Any feedback would be > greatly appreciated. > ... > The goal of the project is to improve the PL/JAVA online documentation > website in terms of appearance, usability, information showcase and >

Re: Cache lookup errors with functions manipulation object addresses

On Thu, Mar 19, 2020 at 08:48:58AM +0100, Daniel Gustafsson wrote: > Taking a look at this to see if we can achieve closure on this long-running > patchset. The goal of the patch is IMO a clear win for usability. > > The patchset applies with a bit of fuzzing and offsetting, it has tests (which >

Re: Auxiliary Processes and MyAuxProc

On Thu, Mar 19, 2020 at 6:35 AM Peter Eisentraut wrote: > > While working on (My)BackendType, I was attempting to get rid of > (My)AuxProcType altogether. This would mostly work except that it's > sort of wired into the pgstats subsystem (see NumBackendStatSlots). > This can probably be

Re: Add FOREIGN to ALTER TABLE in pg_dump

> On 15 Jan 2020, at 00:04, Alvaro Herrera wrote: > > 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

Re: Internal key management system

On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote: > > On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote: > > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada > > > I understand that your idea is to include fixed length string to the > > > 256 bit key in order to separate key space.

Re: [PATCH] Add schema and table names to partition error

On 3/18/20 11:46 PM, Amit Kapila wrote: > On Thu, Mar 19, 2020 at 3:55 AM Chris Bandy wrote: >> >> >> Sorry for these troubles. Attached are patches created using `git >> format-patch -n -v6` on master at 487e9861d0. >> > > No problem. I have extracted your code changes as a separate patch >

Re: potential stuck lock in SaveSlotToPath()

On Wed, Mar 18, 2020 at 4:25 PM Andres Freund wrote: > I don't see a valid reason for that though - if anything it's dangerous, > because we're not persistently saving the slot. It should fail the > checkpoint imo. Robert, do you have an idea? Well, the comment atop SaveSlotToPath says: * This

Re: Unicode normalization SQL functions

What is that status of this patch set? I think we have nailed down the behavior, but there were some concerns about certain performance characteristics. Do people feel that those are required to be addressed in this cycle? -- Peter Eisentraut http://www.2ndQuadrant.com/

Re: JDBC prepared insert and X00 and SQL_ASCII

On Wed, 18 Mar 2020 at 08:56, gmail Vladimir Koković < vladimir.koko...@gmail.com> wrote: > Hi, > > > After a thorough Java-Swig-libpq test, I can confirm that INSERT/SELECT is > working properly: > 1. server_encoding: SQL_ASCII > 2. client_encoding: SQL_ASCII > 3. INSERT / SELECT java string

Re: Make MemoryContextMemAllocated() more precise

On Mon, Mar 16, 2020 at 2:45 PM Jeff Davis wrote: > Attached is a patch that makes mem_allocated a method (rather than a > field) of MemoryContext, and allows each memory context type to track > the memory its own way. They all do the same thing as before > (increment/decrement a field), but

Re: proposal: new polymorphic types - commontype and commontypearray

I wrote: > Here's a pretty-nearly-final version of the patch. > In 0001 below, I've left it throwing an error for the case of all > ANYCOMPATIBLE inputs being unknown, but the documentation fails to > acknowledge that. 0002 below is a delta patch that switches to the > other approach of resolving

Re: proposal: new polymorphic types - commontype and commontypearray

čt 19. 3. 2020 v 16:44 odesílatel Tom Lane napsal: > I wrote: > > Here's a pretty-nearly-final version of the patch. > > In 0001 below, I've left it throwing an error for the case of all > > ANYCOMPATIBLE inputs being unknown, but the documentation fails to > > acknowledge that. 0002 below is a

Re: WAL usage calculation patch

On Thu, Mar 19, 2020 at 09:03:02PM +0900, Fujii Masao wrote: > > On 2020/03/19 2:19, Julien Rouhaud wrote: > > > > I'm attaching a v5 with fp records only for temp tables, so there's no risk > > of > > instability. As I previously said I'm fine with your two patches, so unless > > you have

Re: Internal key management system

On Thu, Mar 19, 2020 at 11:42:36PM +0900, Masahiko Sawada wrote: > On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote: > > > > On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote: > > > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada > > > > I understand that your idea is to include

Re: Internal key management system

On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote: > On Thu, Mar 19, 2020 at 11:42:36PM +0900, Masahiko Sawada wrote: > > On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote: > > > > > > On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote: > > > > On Thu, 19 Mar 2020 at 15:59, Masahiko

Re: Internal key management system

On Fri, Mar 20, 2020 at 12:50:27AM +0900, Masahiko Sawada wrote: > On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote: > Well, the issue is if the user can control the user key, there is might be > a way to make the user key do nothing. > > Well I meant ‘USER_KEY:’ is a fixed length string

nbtree: assertion failure in _bt_killitems() for posting tuple

During tests, we catched an assertion failure in _bt_killitems() for posting tuple in unique index: /* kitem must have matching offnum when heap TIDs match */ Assert(kitem->indexOffset == offnum); https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtutils.c#L1809 I

Re: backend type in log_line_prefix?

On Sun, Mar 15, 2020 at 7:32 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > > I have committed that last one also, after some corrections. > IMHO we should also update file_fdw documentation. See attached! Regards, -- Fabrízio de Royes Mello Timbira -

Re: Parallel grouping sets

Thanks you to review this patch. On Thu, Mar 19, 2020 at 10:09 AM Tomas Vondra wrote: > Hi, > > unfortunately this got a bit broken by the disk-based hash aggregation, > committed today, and so it needs a rebase. I've started looking at the > patch before that, and I have it rebased on

Re: Unicode normalization SQL functions

On 3/19/20 3:41 PM, Peter Eisentraut wrote: What is that status of this patch set?  I think we have nailed down the behavior, but there were some concerns about certain performance characteristics.  Do people feel that those are required to be addressed in this cycle? Personally I would

Re: Missing errcode() in ereport

Hi, On 2020-03-17 10:09:18 -0400, Tom Lane wrote: > We might want to spend some effort thinking how to find or prevent > additional bugs of the same ilk ... Yea, that'd be good. Trying to help people new to postgres write their first patches I found that ereport is very confusing to them -

Re: GSoC applicant proposal, Uday PB

Hi! On Wed, Mar 18, 2020 at 8:13 AM p.b uday wrote: > Hi PostgreSQL team, > I am looking forward to participating in the GSoC with PostgreSQL this > summer. Below is my draft proposal for your review. Any feedback would be > greatly appreciated. > > PL/Java online documentation improvements

Re: Missing errcode() in ereport

Andres Freund writes: > On 2020-03-17 10:09:18 -0400, Tom Lane wrote: >> We might want to spend some effort thinking how to find or prevent >> additional bugs of the same ilk ... > Yea, that'd be good. Trying to help people new to postgres write their > first patches I found that ereport is

Re: Adding missing object access hook invocations

> On Mar 19, 2020, at 11:17 AM, Alvaro Herrera wrote: > > On 2020-Mar-18, Mark Dilger wrote: > >> Here is the latest patch. > > So you insist in keeping the Drop hook calls? My apologies, not at all. I appear to have attached the wrong patch. Will post v3 shortly. — Mark Dilger

Re: error context for vacuum to include block number

On Thu, Mar 19, 2020 at 03:18:32PM +0530, Amit Kapila wrote: > > You're right. PHASE_SCAN_HEAP was set, but only inside a conditional. > > I think if we do it inside for loop, then we don't need to set it > conditionally at multiple places. I have changed like that in the > attached patch, see

invalid byte sequence for encoding "UTF8": 0x95-while using PGP Encryption -PostgreSQL

Hi, I was working on Asymmetric encryption in postgres using pgcrypto . I have generated the keys and stored in data folder and had inserted the data using pgcrypto encrypt function . here the problem comes, I was trying to decrypt the data but it was throwing me the below error ERROR:

Re: Berserk Autovacuum (let's save next Mandrill)

> > According to my reckoning, that is the remaining objection to the patch > > as it is (with ordinary freezing behavior). > > > > How about a scale_factor od 0.005? That will be high enough for large > > tables, which seem to be the main concern here. > > Seems low on a first blush. On a

Fwd: invalid byte sequence for encoding "UTF8": 0x95-while using PGP Encryption -PostgreSQL

Hi, I was working on Asymmetric encryption in postgres using pgcrypto . I have generated the keys and stored in data folder and had inserted the data using pgcrypto encrypt function . here the problem comes, I was trying to decrypt the data but it was throwing me the below error ERROR:

Re: Additional improvements to extended statistics

On Wed, 18 Mar 2020 at 19:31, Tomas Vondra wrote: > > Attached is a rebased patch series, addressing both those issues. > > I've been wondering why none of the regression tests failed because of > the 0.0 vs. 1.0 issue, but I think the explanation is pretty simple - to > make the tests stable,

Re: GSoC applicant proposal, Uday PB

Greetings, * Chapman Flack (c...@anastigmatix.net) wrote: > On 3/19/20 2:03 PM, Alexander Korotkov wrote: > > Does your project imply any coding? AFAIR, GSoC doesn't allow pure > > documentation projects. > > That's a good question. The idea as I proposed it is more of an > infrastructure

Re: Berserk Autovacuum (let's save next Mandrill)

On Thu, 2020-03-19 at 21:39 +1300, David Rowley wrote: > > According to my reckoning, that is the remaining objection to the patch > > as it is (with ordinary freezing behavior). > > > > How about a scale_factor od 0.005? That will be high enough for large > > tables, which seem to be the main

Re: Make MemoryContextMemAllocated() more precise

On Thu, Mar 19, 2020 at 3:44 PM Jeff Davis wrote: > On Thu, 2020-03-19 at 15:26 -0400, Robert Haas wrote: > > Well, the issue is, if I understand correctly, that this means that > > MemoryContextStats() might now report a smaller amount of memory than > > what we actually allocated from the

Re: Make MemoryContextMemAllocated() more precise

On Thu, 2020-03-19 at 16:04 -0400, Robert Haas wrote: > Other people may have different concerns, but that was the only thing > that was bothering me. OK, thank you for raising it. Perhaps we can re-fix the issue for HashAgg if necessary, or I can tweak some accounting things within HashAgg

Re: Adding missing object access hook invocations

> On Mar 19, 2020, at 11:30 AM, Mark Dilger > wrote: > > Will post v3 shortly. v3-0001-Adding-missing-Object-Access-hook-invocations.patch Description: Binary data — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [PATCH] pg_upgrade: report the reason for failing to open the cluster version file

On Wed, Feb 26, 2020 at 06:32:00PM +, Dagfinn Ilmari Mannsåker wrote: > Tom Lane writes: > > > Michael Paquier writes: > >> On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote: > >>> +1, seems like that would be a regression in value. > > > >> Having more generic messages is

Re: Make MemoryContextMemAllocated() more precise

On Thu, Mar 19, 2020 at 3:27 PM Jeff Davis wrote: > I think omitting the tail of the current block is an unqualified > improvement for the purpose of obeying work_mem, regardless of the OS. > The block sizes keep doubling up to 8MB, and it doesn't make a lot of > sense to count that last large

Re: shared-memory based stats collector

Hi, On 2020-03-19 20:30:04 +0900, Kyotaro Horiguchi wrote: > > I think we also can get rid of the dshash_delete changes, by instead > > adding a dshash_delete_current(dshash_seq_stat *status, void *entry) API > > or such. > > [009] (Fixed) > I'm not sure about the point of having two interfaces

Re: PATCH: add support for IN and @> in functional-dependency statistics use

On Wed, 18 Mar 2020 at 00:29, Tomas Vondra wrote: > > OK, I took a look. I think from the correctness POV the patch is OK, but > I think the dependencies_clauselist_selectivity() function now got a bit > too complex. I've been able to parse it now, but I'm sure I'll have > trouble in the future

Re: Collation versioning

On Thu, Mar 19, 2020 at 12:31:54PM +0900, Michael Paquier wrote: > On Wed, Mar 18, 2020 at 04:35:43PM +0100, Julien Rouhaud wrote: > > On Wed, Mar 18, 2020 at 09:56:40AM +0100, Julien Rouhaud wrote: > > AFAICT it was only missing a call to index_update_collation_versions() in > >

Re: Make MemoryContextMemAllocated() more precise

On Thu, Mar 19, 2020 at 2:11 PM Tomas Vondra wrote: > My understanding is that this is really just an accounting issue, where > allocating a block would get us over the limit, which I suppose might be > an issue with low work_mem values. Well, the issue is, if I understand correctly, that this

Re: Make MemoryContextMemAllocated() more precise

On Thu, 2020-03-19 at 11:44 -0400, Robert Haas wrote: > Procedurally, I think that it is highly inappropriate to submit a > patch two weeks after the start of the final CommitFest and then > commit it just over 48 hours later without a single endorsement of > the > change from anyone. Reverted.

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

Noah Misch writes: > On Sun, Jan 05, 2020 at 01:33:55AM +0100, Tomas Vondra wrote: >> It's a bit unfortunate that a patch for a data corruption / loss issue >> (even if a low-probability one) fell through multiple commitfests. > Thanks for investing in steps to fix that. Yeah, this patch has

Re: Berserk Autovacuum (let's save next Mandrill)

Hi, On 2020-03-19 20:47:40 +0100, Laurenz Albe wrote: > On Thu, 2020-03-19 at 21:39 +1300, David Rowley wrote: > > I've attached a small fix which I'd like to apply to your v8 patch. > > With that, and pending one final look, I'd like to push this during my > > Monday (New Zealand time). So if

Re: Some improvements to numeric sqrt() and ln()

Dean Rasheed writes: > On Wed, 4 Mar 2020 at 14:41, David Steele wrote: >> Are these improvements targeted at PG13 or PG14? This seems a pretty >> big change for the last CF of PG13. > Well of course that's not entirely up to me, but I was hoping to > commit it for PG13. > It's very well

Re: Make MemoryContextMemAllocated() more precise

On Thu, Mar 19, 2020 at 12:25:16PM -0700, Jeff Davis wrote: On Thu, 2020-03-19 at 19:11 +0100, Tomas Vondra wrote: AFAICS the 2x allocation is the worst case, because it only happens right after allocating a new block (of twice the size), when the "utilization" drops from 100% to 50%. But in

Re: Auxiliary Processes and MyAuxProc

Hi, On 2020-03-19 11:35:41 +0100, Peter Eisentraut wrote: > On 2020-03-18 17:07, Mike Palmiotto wrote: > > On Wed, Mar 18, 2020 at 11:26 AM Mike Palmiotto > > wrote: > > > > > > On Wed, Mar 18, 2020 at 10:17 AM Justin Pryzby > > > wrote: > > > > Also, I saw this was failing tests both before

Re: Make MemoryContextMemAllocated() more precise

On Thu, 2020-03-19 at 15:26 -0400, Robert Haas wrote: > Well, the issue is, if I understand correctly, that this means that > MemoryContextStats() might now report a smaller amount of memory than > what we actually allocated from the operating system. That seems like > it might lead someone trying

Re: Make MemoryContextMemAllocated() more precise

On Thu, 2020-03-19 at 15:33 -0400, Robert Haas wrote: > On Thu, Mar 19, 2020 at 3:27 PM Jeff Davis wrote: > > I think omitting the tail of the current block is an unqualified > > improvement for the purpose of obeying work_mem, regardless of the > > OS. > > The block sizes keep doubling up to

Fwd: invalid byte sequence for encoding "UTF8": 0x95-while using PGP Encryption -PostgreSQL

Hi, I was working on Asymmetric encryption in postgres using pgcrypto . I have generated the keys and stored in data folder and had inserted the data using pgcrypto encrypt function . here the problem comes, I was trying to decrypt the data but it was throwing me the below error ERROR:

Re: range_agg

On Thu, Mar 19, 2020 at 1:42 PM Alvaro Herrera wrote: > > On 2020-Mar-16, Paul A Jungwirth wrote: > > > On Sat, Mar 14, 2020 at 11:13 AM Paul A Jungwirth > > wrote: > > > I think that should fix the cfbot failure. > > > > I saw this patch was failing to apply again. There was some > >

Re: Berserk Autovacuum (let's save next Mandrill)

Hi, On 2020-03-19 06:45:48 +0100, Laurenz Albe wrote: > On Tue, 2020-03-17 at 18:02 -0700, Andres Freund wrote: > > I don't think a default scale factor of 0 is going to be ok. For > > large-ish tables this will basically cause permanent vacuums. And it'll > > sometimes trigger for tables that

Re: Make MemoryContextMemAllocated() more precise

On Thu, Mar 19, 2020 at 11:44:05AM -0400, Robert Haas wrote: On Mon, Mar 16, 2020 at 2:45 PM Jeff Davis wrote: Attached is a patch that makes mem_allocated a method (rather than a field) of MemoryContext, and allows each memory context type to track the memory its own way. They all do the same

Re: Adding missing object access hook invocations

On 2020-Mar-18, Mark Dilger wrote: > Here is the latest patch. So you insist in keeping the Drop hook calls? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Make MemoryContextMemAllocated() more precise

On Thu, 2020-03-19 at 19:11 +0100, Tomas Vondra wrote: > AFAICS the 2x allocation is the worst case, because it only happens > right after allocating a new block (of twice the size), when the > "utilization" drops from 100% to 50%. But in practice the utilization > will be somewhere in between,

Re: [PATCH] pg_upgrade: report the reason for failing to open the cluster version file

Bruce Momjian writes: > On Wed, Feb 26, 2020 at 06:32:00PM +, Dagfinn Ilmari Mannsåker wrote: >> Tom Lane writes: >> >> > Michael Paquier writes: >> >> On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote: >> >>> +1, seems like that would be a regression in value. >> > >> >>

Re: range_agg

On 2020-Mar-16, Paul A Jungwirth wrote: > On Sat, Mar 14, 2020 at 11:13 AM Paul A Jungwirth > wrote: > > I think that should fix the cfbot failure. > > I saw this patch was failing to apply again. There was some > refactoring to how polymorphic types are determined. I added my > changes for

Re: Improve errors when setting incorrect bounds for SSL protocols

> On 7 Feb 2020, at 01:33, Michael Paquier wrote: > > On Thu, Feb 06, 2020 at 11:30:40PM +0100, Daniel Gustafsson wrote: >> Or change to the v1 patch in this thread, which avoids the problem by doing >> it >> in the OpenSSL code. It's a shame to have generic TLS functionality be >> OpenSSL >>

Re: Berserk Autovacuum (let's save next Mandrill)

Hi, On 2020-03-20 01:11:23 +0300, Darafei "Komяpa" Praliaskouski wrote: > > > According to my reckoning, that is the remaining objection to the patch > > > as it is (with ordinary freezing behavior). > > > > > > How about a scale_factor od 0.005? That will be high enough for large > > > tables,

Re: GSoC applicant proposal, Uday PB

On 3/19/20 2:03 PM, Alexander Korotkov wrote: > Does your project imply any coding? AFAIR, GSoC doesn't allow pure > documentation projects. That's a good question. The idea as I proposed it is more of an infrastructure project, adjusting the toolchain that currently autogenerates the docs

Re: shared-memory based stats collector

Hi, On 2020-03-19 16:51:59 +1300, Thomas Munro wrote: > On Fri, Mar 13, 2020 at 4:13 PM Andres Freund wrote: > > Thomas, could you look at the first two patches here, and my review > > questions? > > Ack. Thanks! > > > dsa_pointer item_pointer = hash_table->buckets[i]; > > > @@

Re: Add PostgreSQL home page to --help output

> On 19 Mar 2020, at 22:32, Bruce Momjian wrote: > > bOn Mon, Mar 16, 2020 at 09:10:25PM -0300, Alvaro Herrera wrote: >> On 2020-Mar-16, Bruce Momjian wrote: >> >>> On Mon, Mar 16, 2020 at 05:55:26PM -0400, Bruce Momjian wrote: Report bugs mailto:pgsql-b...@lists.postgresql.org

Re: improve transparency of bitmap-only heap scans

On Mon, Mar 16, 2020 at 9:08 AM James Coleman wrote: > ... > One question though: if I change the query to: > explain (analyze, buffers) select count(*) from exp where a between 50 > and 100 and d between 5 and 10; > then I get a parallel bitmap heap scan, and I only see exact heap > blocks (see

Re: improve transparency of bitmap-only heap scans

On Thu, Mar 19, 2020 at 9:26 PM Justin Pryzby wrote: > > On Mon, Mar 16, 2020 at 09:08:36AM -0400, James Coleman wrote: > > Does the original optimization cover parallel bitmap heap scans like this? > > It works for parallel bitmap only scans. > > template1=# explain analyze select count(*) from

Re: Berserk Autovacuum (let's save next Mandrill)

On Fri, 20 Mar 2020 at 11:17, Andres Freund wrote: > I think there's too much "reinventing" autovacuum scheduling in a > "local" insert-only manner happening in this thread. And as far as I can > tell additionally only looking at a somewhat narrow slice of insert only > workloads. I understand

Re: nbtree: assertion failure in _bt_killitems() for posting tuple

On Thu, Mar 19, 2020 at 9:34 AM Anastasia Lubennikova wrote: > Unfortunately I cannot attach test and core dump, since they rely on the > enterprise multimaster extension code. > Here are some details from the core dump, that I find essential: > > Stack is > _bt_killitems >

Re: Add A Glossary

I gave this a look. I first reformatted it so I could read it; that's 0001. Second I changed all the long items into s, which are shorter and don't have to repeat the title of the refered to page. (Of course, this changes the link to be in the same style as every other link in our

Re: error context for vacuum to include block number

On Thu, Mar 19, 2020 at 03:29:31PM -0500, Justin Pryzby wrote: > I was going to suggest that we could do that by passing in a pointer to a > local > variable "LVRelStats olderrcbarg", like: > |update_vacuum_error_cbarg(vacrelstats, VACUUM_ERRCB_PHASE_SCAN_HEAP, > |

  1   2   >