Re: Don't choke on files that are removed while pg_rewind runs.

On Mon, 13 Jul 2020 at 15:34, Daniel Gustafsson wrote: > > > On 13 Jul 2020, at 08:10, Justin Pryzby wrote: > > > Every other access to "res" in this loop is to res(i), which I believe is > > what > > was intended here, too. Currently, it will dumbly loop but skip *every* > > row if > > the 2n

Re: max_slot_wal_keep_size and wal_keep_segments

At Mon, 13 Jul 2020 14:14:30 +0900, Fujii Masao wrote in > > > On 2020/07/09 13:47, Kyotaro Horiguchi wrote: > > At Thu, 9 Jul 2020 00:37:57 +0900, Fujii Masao > > wrote in > >> > >> > >> On 2020/07/02 2:18, David Steele wrote: > >>> On 7/1/20 10:54 AM, Alvaro Herrera wrote: > On 2020-Ju

Re: [PATCH] Performance Improvement For Copy From Binary Files

On Mon, Jul 13, 2020 at 12:17 PM Bharath Rupireddy wrote: > > CopyReadFromRawBuf as a name for the new function might be misleading > > as long as we are only using it for binary data. Maybe > > CopyReadBinaryData is more appropriate? See attached v4 with these > > and a few other cosmetic chang

Re: OpenSSL 3.0.0 compatibility

On 2020-07-07 22:52, Daniel Gustafsson wrote: where would be a good place to define OPENSSL_API_COMPAT? The only place that's shared between frontend and backend code is c.h. The attached patch does it that way. pg_config_manual.h, perhaps? I don't have a strong preference. When starting hac

Re: Don't choke on files that are removed while pg_rewind runs.

On Mon, Jul 13, 2020 at 03:59:56PM +0900, Masahiko Sawada wrote: > On Mon, 13 Jul 2020 at 15:34, Daniel Gustafsson wrote: >> Yeah, I agree with that, seems like the call should've been PQgetisnull(res, >> i, 1); >> to match the loop. > > +1 Good catch, Justin. There is a second thing here. Th

Re: Don't choke on files that are removed while pg_rewind runs.

> On 13 Jul 2020, at 09:56, Michael Paquier wrote: > > On Mon, Jul 13, 2020 at 03:59:56PM +0900, Masahiko Sawada wrote: >> On Mon, 13 Jul 2020 at 15:34, Daniel Gustafsson wrote: >>> Yeah, I agree with that, seems like the call should've been >>> PQgetisnull(res, i, 1); >>> to match the loop. >>

Re: proposal: possibility to read dumped table's name from file

ne 12. 7. 2020 v 3:43 odesílatel vignesh C napsal: > On Mon, Jul 6, 2020 at 10:05 AM Pavel Stehule > wrote: > > > > here is support for comment's line - first char should be # > > > > Few comments: > + str = fgets(*lineptr + total_chars, > + *n

Re: Auto-vectorization speeds up multiplication of large-precision numerics

On Fri, 10 Jul 2020 at 19:02, Tom Lane wrote: > > Peter Eisentraut writes: > > We normally don't compile with -O3, so very few users would get the > > benefit of this. > > Yeah. I don't think changing that baseline globally would be a wise move. > > > We have CFLAGS_VECTOR for the checksum code.

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Jul 13, 2020 at 11:10 AM Amit Kapila wrote: > > On Mon, Jul 13, 2020 at 10:40 AM Dilip Kumar wrote: > > > > On Mon, Jul 13, 2020 at 10:14 AM Amit Kapila > > wrote: > > > > > > On Fri, Jul 10, 2020 at 3:37 PM Dilip Kumar wrote: > > > > > > > > On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila

Re: Default setting for enable_hashagg_disk

On Sat, Jul 11, 2020 at 3:30 AM Tom Lane wrote: > > Stephen Frost writes: > > I don't see hash_mem as being any kind of proper fix- it's just punting > > to the user saying "we can't figure this out, how about you do it" and, > > worse, it's in conflict with how we already ask the user that quest

Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

Hi čt 18. 6. 2020 v 0:47 odesílatel David G. Johnston < david.g.johns...@gmail.com> napsal: > This is a follow-up to Bug # 16492 which also links to a thread sent to > -hackers back in 2018. > > I'm firmly of the belief that the existing behavior of DROP relation IF > EXISTS is flawed - it should

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Jul 13, 2020 at 2:32 PM Dilip Kumar wrote: > > On Mon, Jul 13, 2020 at 11:10 AM Amit Kapila wrote: > > > > > > I think you can refer to commit message as well for that "We however > > must explicitly disable streaming replication during replication slot > > creation, even if the plugin su

Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

po 13. 7. 2020 v 11:11 odesílatel Pavel Stehule napsal: > Hi > > čt 18. 6. 2020 v 0:47 odesílatel David G. Johnston < > david.g.johns...@gmail.com> napsal: > >> This is a follow-up to Bug # 16492 which also links to a thread sent to >> -hackers back in 2018. >> >> I'm firmly of the belief that th

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Jul 13, 2020 at 2:56 PM Amit Kapila wrote: > > On Mon, Jul 13, 2020 at 2:32 PM Dilip Kumar wrote: > > > > On Mon, Jul 13, 2020 at 11:10 AM Amit Kapila > > wrote: > > > > > > > > > I think you can refer to commit message as well for that "We however > > > must explicitly disable streamin

Re: Stale external URL in doc?

> On 11 Jul 2020, at 05:25, Thomas Munro wrote: > Is it OK that I see the following warning many times when running > "make" under src/backend/utils/mb/Unicode? It looks like this code is > from commit 1de9cc0d. Horiguchi-san, do you think something changed > (input data format, etc) since you

Re: proposal: possibility to read dumped table's name from file

> On 13 Jul 2020, at 10:20, Pavel Stehule wrote: > attached updated patch Sorry for jumping in late, but thinking about this extension to pg_dump: doesn't it make more sense to use an existing file format like JSON for this, given that virtually all devops/cd/etc tooling know about JSON already?

Re: [HACKERS] [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

> On 8 Apr 2020, at 14:58, David Steele wrote: > > On 3/28/20 5:27 AM, Fabien COELHO wrote: >> Hello Tom, >> Thanks for your feedback, I'd be rather unclear about what the actual feedback is, though. I'd interpret it as "pg does not care much about code coverage". Most clients are

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Jul 13, 2020 at 3:04 PM Dilip Kumar wrote: > > On Mon, Jul 13, 2020 at 2:56 PM Amit Kapila wrote: > > > > On Mon, Jul 13, 2020 at 2:32 PM Dilip Kumar wrote: > > > > > > On Mon, Jul 13, 2020 at 11:10 AM Amit Kapila > > > wrote: > > > > > > > > > > > > I think you can refer to commit mes

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, Jul 13, 2020 at 4:00 PM Amit Kapila wrote: > > On Mon, Jul 13, 2020 at 3:04 PM Dilip Kumar wrote: > > > > On Mon, Jul 13, 2020 at 2:56 PM Amit Kapila wrote: > > > > > > On Mon, Jul 13, 2020 at 2:32 PM Dilip Kumar wrote: > > > > > > > > On Mon, Jul 13, 2020 at 11:10 AM Amit Kapila > >

Re: INSERT INTO SELECT, Why Parallelism is not selected?

On Sat, Jul 11, 2020 at 6:07 PM Dilip Kumar wrote: > > I have just notice that the parallelism is off even for the select > part of the query mentioned in the $subject. I see the only reason it > is not getting parallel because we block the parallelism if the query > type is not SELECT. I don't

Re: proposal: possibility to read dumped table's name from file

po 13. 7. 2020 v 12:04 odesílatel Daniel Gustafsson napsal: > > On 13 Jul 2020, at 10:20, Pavel Stehule wrote: > > > attached updated patch > > Sorry for jumping in late, but thinking about this extension to pg_dump: > doesn't it make more sense to use an existing file format like JSON for > thi

Re: Global snapshots

On Fri, Jul 10, 2020 at 8:46 AM Masahiko Sawada wrote: > > On Wed, 8 Jul 2020 at 21:35, Amit Kapila wrote: > > > > > > Cool. While studying, if you can try to think whether this approach is > > different from the global coordinator based approach then it would be > > great. Here is my initial th

Re: POC and rebased patch for CSN based snapshots

On 2020/06/19 14:54, Fujii Masao wrote: On 2020/06/19 13:36, movead...@highgo.ca wrote:  >You mean that the last generated CSN needs to be WAL-logged because any smaller CSN than the last one should not be reused after crash recovery. Right? Yes that's it. If right, that WAL-logging s

Re: [HACKERS] make async slave to wait for lsn to be replayed

This patch require some rewording of documentation/comments and variable names after the language change introduced by 229f8c219f8f..a9a4a7ad565b, the thread below can be used as reference for how to change: https://www.postgresql.org/message-id/flat/20200615182235.x7lch5n6kcjq4aue%40alap3.anaraze

Re: Resetting spilled txn statistics in pg_stat_replication

On Fri, Jul 10, 2020 at 2:39 PM Amit Kapila wrote: > > On Fri, Jul 10, 2020 at 7:19 AM Masahiko Sawada > wrote: > > > > On Thu, 9 Jul 2020 at 16:09, Amit Kapila wrote: > > > > > > > > > Fair enough. The attached patch reverts the commits related to these > > > stats. Sawada-San, can you please

Re: [PATCH] Performance Improvement For Copy From Binary Files

> > > > CopyReadFromRawBuf as a name for the new function might be misleading > > > as long as we are only using it for binary data. Maybe > > > CopyReadBinaryData is more appropriate? See attached v4 with these > > > and a few other cosmetic changes. > > > > > > > CopyReadBinaryData() looks mean

Re: Default setting for enable_hashagg_disk

On 2020-04-07 20:20, Jeff Davis wrote: Now that we have Disk-based Hash Aggregation, there are a lot more situations where the planner can choose HashAgg. The enable_hashagg_disk GUC, if set to true, chooses HashAgg based on costing. If false, it only generates a HashAgg path if it thinks it will

Re: [Proposal] Global temporary tables

> 2020年7月10日 下午5:03，wenjing zeng 写道： > > HI all > > I started using my personal email to respond to community issue. > > > >> 2020年7月7日 下午6:05，Pavel Stehule > > 写道： >> >> Hi >> >> GTT Merge the latest PGMaster and resolves conflicts. >> >> >> >> I teste

Re: Default setting for enable_hashagg_disk

On Mon, 13 Jul 2020 at 23:51, Peter Eisentraut wrote: > I have an anecdote that might be related to this discussion. > > I was running an unrelated benchmark suite. With PostgreSQL 12, one > query ran out of memory. With PostgreSQL 13, the same query instead ran > out of disk space. I bisected

Re: Don't choke on files that are removed while pg_rewind runs.

On Mon, Jul 13, 2020 at 10:12:54AM +0200, Daniel Gustafsson wrote: > Does it? PGgetvalue will return an empty string and not NULL, so atol will > convert that to zero wont it? It can be argued whether zero is the right size > for a missing file, but it shouldn't crash at least. Nay, you are righ

Editing errors in the comments of tableam.h and heapam.c

Hi, Some comments in tableam.h and heapam.c contain three old function names although these have been renamed by this commit 73b8c3bd2889fed986044e15aefd0911f96ccdd3. Old: table_insert, table_fetch_row_version, table_get_latest_tid. New: table_tuple_insert, table_tuple_fetch_row_version, ta

Re: output columns of \dAo and \dAp

On Sat, Jul 11, 2020 at 10:59 PM Tom Lane wrote: > Alexander Korotkov writes: > > The proposed patch is attached. This patch is fixes two points: > > * Adds strategy number and purpose to output of \dAo > > * Renames "Left/right arg type" columns of \dAp to "Registered left/right > > type" >

Re: Editing errors in the comments of tableam.h and heapam.c

On Mon, Jul 13, 2020 at 02:25:39PM +0200, Hironobu SUZUKI wrote: > Some comments in tableam.h and heapam.c contain three old function names > although these have been renamed by this commit > 73b8c3bd2889fed986044e15aefd0911f96ccdd3. > > Old: table_insert, table_fetch_row_version, table_get_latest

Re: Binary support for pgoutput plugin

On Sat, 11 Jul 2020 at 10:20, Tom Lane wrote: > Petr Jelinek writes: > > On 11/07/2020 14:14, Dave Cramer wrote: > >> So is there any point in having them as options then ? > > > I am guessing this is copied from pglogical, right? We have them there > > because it can optionally send data in the

Re: Default setting for enable_hashagg_disk

On 2020-07-13 14:16, David Rowley wrote: Isn't that what temp_file_limit is for? Yeah, I guess that is so rarely used that I had forgotten about it. So maybe that is also something that more users will want to be aware of. -- Peter Eisentraut http://www.2ndQuadrant.com/ Postgre

Re: Default setting for enable_hashagg_disk

Greetings, * Peter Geoghegan (p...@bowt.ie) wrote: > On Sat, Jul 11, 2020 at 7:22 AM Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Have you got a better proposal that is reasonably implementable for v13? > > > (I do not accept the argument that "do nothing" is a better pro

Re: [PATCH] Performance Improvement For Copy From Binary Files

On Mon, Jul 13, 2020 at 8:02 AM Amit Langote wrote: > By the way, considering the rebase over cd22d3cdb9b, it seemed to me > that we needed to update the comments in CopyStateData struct > definition a bit more. While doing that, I realized > CopyReadFromRawBuf as a name for the new function migh

Re: proposal: possibility to read dumped table's name from file

On Mon, Jul 13, 2020 at 1:51 PM Pavel Stehule wrote: >> Can this be changed to dump objects and data based on the filter >> expressions from the filter file. > > > I am sorry, I don't understand. This should work for data from specified by > filter without any modification. > I meant can this: pr

Re: OpenSSL 3.0.0 compatibility

Peter Eisentraut writes: >>> where would be a good place to define >>> OPENSSL_API_COMPAT? > Actually, it would be most formally correct to set it using AC_DEFINE in > configure.in, so that configure tests see it. Yeah, very good point. regards, tom lane

Commitfest 2020-07 almost halfway

We are fast approaching mid-July, and with it Mid-commitfest. As has been the case with most commitfests for a while, this CF had a record number of entries with 246 patches. As of this writing, the status breakdown looks like this: Needs review: 139 Waiting on Author: 34 Ready for Committ

Re: Default setting for enable_hashagg_disk

On Mon, Jul 13, 2020 at 01:51:42PM +0200, Peter Eisentraut wrote: On 2020-04-07 20:20, Jeff Davis wrote: Now that we have Disk-based Hash Aggregation, there are a lot more situations where the planner can choose HashAgg. The enable_hashagg_disk GUC, if set to true, chooses HashAgg based on costi

Re: Default setting for enable_hashagg_disk

On Tue, 14 Jul 2020 at 01:13, Stephen Frost wrote: > Yes, increasing work_mem isn't unusual, at all. What that tweet shows > that I don't think folks who are suggesting things like setting this > factor to 2.0 is that people may have a work_mem configured in the > gigabytes- meaning that a 2.0 va

Re: proposal: possibility to read dumped table's name from file

On Mon, Jul 13, 2020 at 12:04:09PM +0200, Daniel Gustafsson wrote: > Sorry for jumping in late, but thinking about this extension to pg_dump: > doesn't it make more sense to use an existing file format like JSON for this, > given that virtually all devops/cd/etc tooling know about JSON already? >

Re: output columns of \dAo and \dAp

Alexander Korotkov writes: > Good compromise. Done as you proposed. I'm OK with this version. regards, tom lane

Re: Default setting for enable_hashagg_disk

On Tue, 2020-07-14 at 02:25 +1200, David Rowley wrote: > Updated summary: > * For hash_mem = Tomas [7], Justin [16] > * For hash_mem_multiplier with a default > 1.0 = DavidG [21] > * For hash_mem_multiplier with default = 1.0 = PeterG [15][0], Tom > [20][24] I am OK with these options, but I stil

Re: pg_dump bug for extension owned tables

On Sat, Jul 11, 2020 at 8:07 PM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > On 6/26/20 2:10 PM, Fabrízio de Royes Mello wrote: > > > > On Fri, Jun 26, 2020 at 11:55 AM Fabrízio de Royes Mello > > mailto:fabriziome...@gmail.com>> wrote: > > > > > > > > > On Fri, Jun 26, 2020 at 11:

Re: proposal: possibility to read dumped table's name from file

> On 13 Jul 2020, at 13:02, Pavel Stehule wrote: > I like JSON format. But why here? For this purpose the JSON is over > engineered. I respectfully disagree, JSON is a commonly used and known format in systems administration and most importantly: we already have code to parse it in the frontend

Re: WIP: BRIN multi-range indexes

On Mon, Jul 13, 2020 at 02:54:56PM +0900, Masahiko Sawada wrote: On Mon, 13 Jul 2020 at 09:33, Alvaro Herrera wrote: On 2020-Jul-13, Tomas Vondra wrote: > On Sun, Jul 12, 2020 at 07:58:54PM -0400, Alvaro Herrera wrote: > > Maybe we can try to handle this with some other function that interpr

Re: [PATCH] Performance Improvement For Copy From Binary Files

> > I had one small comment: > +{ > + int copied_bytes = 0; > + > +#define BUF_BYTES (cstate->raw_buf_len - cstate->raw_buf_index) > +#define DRAIN_COPY_RAW_BUF(cstate, dest, nbytes)\ > + do {\ > + memcpy((dest), (cstate)->raw_buf + > (cstate)->raw_buf_ind

Re: [patch] demote

Hi, Another summary + patch + tests. This patch supports 2PC. The goal is to keep them safe during demote/promote actions so they can be committed/rollbacked later on a primary. See tests. The checkpointer is now shutdowned after the demote shutdown checkpoint. It removes some useless code compl

Re: GSSENC'ed connection stalls while reconnection attempts.

Kyotaro Horiguchi writes: > At Fri, 10 Jul 2020 12:01:10 -0400, Tom Lane wrote in >> The attached patch makes this all act more like the way SSL is handled, >> and for me it resolves the reconnection problem. > It looks good to me. OK, thanks. >>> The reason that psql doesn't notice the error

Re: Default setting for enable_hashagg_disk

On 2020-07-13 16:11, Tomas Vondra wrote: Why is running out of disk space worse experience than running out of memory? Sure, it'll take longer and ultimately the query fails (and if it fills the device used by the WAL then it may also cause shutdown of the main instance due to inability to write

Re: [PATCH] fix GIN index search sometimes losing results

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Hi, all! It seems that as of now we have two sets of patches for thi

Re: proposal: possibility to read dumped table's name from file

po 13. 7. 2020 v 16:57 odesílatel Daniel Gustafsson napsal: > > On 13 Jul 2020, at 13:02, Pavel Stehule wrote: > > > I like JSON format. But why here? For this purpose the JSON is over > engineered. > > I respectfully disagree, JSON is a commonly used and known format in > systems > administrati

Re: Default setting for enable_hashagg_disk

On Mon, Jul 13, 2020 at 6:13 AM Stephen Frost wrote: > Yes, increasing work_mem isn't unusual, at all. It's unusual as a way of avoiding OOMs! > Eh? That's not at all what it looks like- they were getting OOM's > because they set work_mem to be higher than the actual amount of memory > they had

Re: Default setting for enable_hashagg_disk

On 2020-Jul-13, Jeff Davis wrote: > On Tue, 2020-07-14 at 02:25 +1200, David Rowley wrote: > > Updated summary: > > * For hash_mem = Tomas [7], Justin [16] > > * For hash_mem_multiplier with a default > 1.0 = DavidG [21] > > * For hash_mem_multiplier with default = 1.0 = PeterG [15][0], Tom > > [

PostgreSQL 13 Beta 3 Release Date

Hi, The PostgreSQL 13 Release Management Team is pleased to announce the release date of PostgreSQL 13 Beta 3 is set to 2020-08-13, which is the same day as the cumulative update release[1]. Please be sure to have your patches committed for PostgreSQL 13 no latter than Sunday, 2020-08-09 AOE[2].

Re: output columns of \dAo and \dAp

On 7/13/20 10:37 AM, Tom Lane wrote: > Alexander Korotkov writes: >> Good compromise. Done as you proposed. > > I'm OK with this version. I saw this was committed and the item was adjusted on the Open Items list. Thank you! Jonathan signature.asc Description: OpenPGP digital signature

Re: output columns of \dAo and \dAp

On Mon, Jul 13, 2020 at 7:54 PM Jonathan S. Katz wrote: > On 7/13/20 10:37 AM, Tom Lane wrote: > > Alexander Korotkov writes: > >> Good compromise. Done as you proposed. > > > > I'm OK with this version. > > I saw this was committed and the item was adjusted on the Open Items list. Thank you!

Fix header identification

Hi hackers, PFA a patch that fixes up the identification for 4 header files. I did a little archaeology trying to find plausible reasons for why we committed the wrong identification in the first place, and here's what I came up with: jsonfuncs.h was created in ce0425b162d0a to house backend-onl

Re: min_safe_lsn column in pg_replication_slots view

A much more sensible answer is to initialize the segno to the segment currently being written, as in the attached. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From 699e3a25e0673353fcb10fa92577f7534e594227 Mon

Re: Compatible defaults for LEAD/LAG

Hi ne 31. 5. 2020 v 22:02 odesílatel Vik Fearing napsal: > On 5/31/20 9:53 PM, Tom Lane wrote: > > Vik Fearing writes: > >> postgres=# SELECT LAG(n, 1, -99) OVER (ORDER BY n) > >> postgres-# FROM (VALUES (1.1), (2.2), (3.3)) AS v (n) > >> postgres-# ORDER BY n; > >> ERROR: function lag

Re: pg_dump bug for extension owned tables

On Mon, Jul 13, 2020 at 11:52 AM Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Sat, Jul 11, 2020 at 8:07 PM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > > > > On 6/26/20 2:10 PM, Fabrízio de Royes Mello wrote: > > > > > > On Fri, Jun 26, 2020 at 11:55 AM Fabríz

Re: min_safe_lsn column in pg_replication_slots view

On 2020-Jul-13, Alvaro Herrera wrote: > A much more sensible answer is to initialize the segno to the segment > currently being written, as in the attached. Ran the valgrind test locally and it passes. Pushed it now. Thanks, -- Álvaro Herrerahttps://www.2ndQuadrant.com/ Postgr

Re: proposal: possibility to read dumped table's name from file

On Mon, Jul 13, 2020 at 08:15:42AM +0200, Pavel Stehule wrote: > > Do you want to add any more documentation ? > > > > done Thanks - I think the documentation was maybe excessive. See attached. -- Justin >From b6ceedcd7f4395fac822059229cb475aa2805c1e Mon Sep 17 00:00:00 2001 From: Pavel Stehul

Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM

On Sun, May 31, 2020 at 10:13:39PM +, Bossart, Nathan wrote: > Here is a rebased version of the patch. Should bin/vacuumdb support this? Should vacuumdb have a way to pass an arbitrary option to the server, instead of tacking on options (which are frequently forgotten on the initial commit to

Re: Report error position in partition bound check

> On 2 July 2020, at 06:39, Daniel Gustafsson wrote: > > On 10 Apr 2020, at 23:50, Alexandra Wang wrote: > > > On Fri, Apr 10, 2020 at 8:37 AM Ashutosh Bapat > > mailto:ashutosh.ba...@2ndquadrant.com>> > > wrote: > > > for a multi-key value the ^ > > > points to the first column and the reader

Re: Proposal: Automatic partition creation

On 06.07.2020 19:10, Tom Lane wrote: Robert Haas writes: On Mon, Jul 6, 2020 at 6:46 AM Anastasia Lubennikova wrote: I am going to implement this via SPI, which allow to simplify checks and calculations. Do you see any pitfalls in this approach? I don't really see why we need SPI here. I wo

Re: pg_dump bug for extension owned tables

On 7/13/20 10:52 AM, Fabrízio de Royes Mello wrote: > > On Sat, Jul 11, 2020 at 8:07 PM Andrew Dunstan > > wrote: > > > > > > On 6/26/20 2:10 PM, Fabrízio de Royes Mello wrote: > > > > > > On Fri, Jun 26, 2020 at 11:55 AM Fabrízio de Royes Mello > > > mailt

Re: Default setting for enable_hashagg_disk

Alvaro Herrera writes: > I'm in favor of hash_mem_multiplier. I think a >1 default is more > sensible than =1 in the long run, but if strategic vote is what we're > doing, then I support the =1 option. FWIW, I also think that we'll eventually end up with >1 default. But the evidence to support t

Re: Default setting for enable_hashagg_disk

On Mon, Jul 13, 2020 at 12:47:36PM -0400, Alvaro Herrera wrote: > On 2020-Jul-13, Jeff Davis wrote: > > > On Tue, 2020-07-14 at 02:25 +1200, David Rowley wrote: > > > Updated summary: > > > * For hash_mem = Tomas [7], Justin [16] > > > * For hash_mem_multiplier with a default > 1.0 = DavidG [21] >

Re: Default setting for enable_hashagg_disk

On Mon, Jul 13, 2020 at 7:25 AM David Rowley wrote: > I think it would be good if we could try to move towards getting > consensus here rather than reiterating our arguments over and over. +1 > Updated summary: > * For hash_mem = Tomas [7], Justin [16] > * For hash_mem_multiplier with a default

Re: Proposal: Automatic partition creation

Anastasia Lubennikova writes: > On 06.07.2020 19:10, Tom Lane wrote: >> Robert Haas writes: >>> I think the big problem here is identifying the operator to use. We >>> have no way of identifying the "plus" or "minus" operator associated >>> with a datatype; indeed, that constant doesn't exist. >

Partitioning and postgres_fdw optimisations for multi-tenancy

Hi Hackers, The idea of achieving Postgres scaling via sharding using postgres_fdw + partitioning got a lot of attention last years. Many optimisations have been done in this direction: partition pruning, partition-wise aggregates / joins, postgres_fdw push-down of LIMIT, GROUP BY, etc. In ma

Re: pg_dump bug for extension owned tables

On Mon, Jul 13, 2020 at 3:29 PM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > On 7/13/20 10:52 AM, Fabrízio de Royes Mello wrote: > > > > On Sat, Jul 11, 2020 at 8:07 PM Andrew Dunstan > > > > wrote: > > > > > > > > > On 6/26/20 2:10 PM, Fabrí

Re: Default setting for enable_hashagg_disk

On Mon, Jul 13, 2020 at 11:50 AM Peter Geoghegan wrote: > > Primarily in favor of escape hatch: > > Jeff, > DavidR, > Pavel, > Andres, > Robert ??, > Amit ?? > > To be clear, by "escape hatch" you mean "add a GUC that instructs the PostgreSQL executor to ignore hash_mem when deciding whether to s

Re: pg_dump bug for extension owned tables

On 7/13/20 2:46 PM, Fabrízio de Royes Mello wrote: > > > > > > yeah, that's the fix I came up with too. The only thing I added was > > "Assert(tbinfo->attgenerated);" at about line 2097. > > > > Cool. > > > > > Will wait for your TAP tests. > > > > Actually I've sent it already but it seems to ha

Re: Default setting for enable_hashagg_disk

On Mon, Jul 13, 2020 at 12:57 PM David G. Johnston wrote: > To be clear, by "escape hatch" you mean "add a GUC that instructs the > PostgreSQL executor to ignore hash_mem when deciding whether to spill the > contents of the hash table to disk - IOW to never spill the contents of a > hash table

Re: Default setting for enable_hashagg_disk

"David G. Johnston" writes: > To be clear, by "escape hatch" you mean "add a GUC that instructs the > PostgreSQL executor to ignore hash_mem when deciding whether to spill the > contents of the hash table to disk - IOW to never spill the contents of a > hash table to disk"? If so that seems separ

Re: Proposal: Automatic partition creation

On 06.07.2020 13:45, Anastasia Lubennikova wrote: The previous discussion of automatic partition creation [1] has addressed static and dynamic creation of partitions and ended up with several syntax proposals. In this thread, I want to continue this work. ... [1] https://www.postgresql.org/me

recovering from "found xmin ... from before relfrozenxid ..."

Hi, A number of EDB customers have had this error crop on their tables for reasons that we have usually not been able to determine. In many cases, it's probably down to things like running buggy old releases for a long time before upgrading, or bad backup and recovery procedures. It's more than po

Re: Proposal: Automatic partition creation

On 06.07.2020 17:59, Justin Pryzby wrote: I think you'd want to have an ALTER command for that (we would use that to change tables between daily/monthly based on their current size). That should also support setting the MODULUS of a HASH partitioned table, to allow changing the size of its parti

Re: pg_dump bug for extension owned tables

On Mon, Jul 13, 2020 at 5:05 PM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > On 7/13/20 2:46 PM, Fabrízio de Royes Mello wrote: > > > > > > > > > > yeah, that's the fix I came up with too. The only thing I added was > > > "Assert(tbinfo->attgenerated);" at about line 2097. > > > >

Re: recovering from "found xmin ... from before relfrozenxid ..."

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > - Do people think it would me smart/good/useful to include something > like this in PostgreSQL? Absolutely, yes. > - If so, how? I would propose a new contrib module that we back-patch > all the way, because the VACUUM errors were back-pa

Re: recovering from "found xmin ... from before relfrozenxid ..."

Stephen Frost writes: > * Robert Haas (robertmh...@gmail.com) wrote: >> - If so, how? I would propose a new contrib module that we back-patch >> all the way, because the VACUUM errors were back-patched all the way, >> and there seems to be no advantage in making people wait 5 years for a >> new ve

Re: recovering from "found xmin ... from before relfrozenxid ..."

On Mon, Jul 13, 2020 at 2:12 PM Robert Haas wrote: > 1. There's nothing to identify the tuple that has the problem, and no > way to know how many more of them there might be. Back-patching > b61d161c146328ae6ba9ed937862d66e5c8b035a would help with the first > part of this. I am in favor of backpa

Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

On Mon, Jul 13, 2020 at 2:12 AM Pavel Stehule wrote: > I am reading this patch. I don't think so text for domains and types are > correct (or minimally it is little bit messy) > This case is a little bit more complex - domains are not subset of > relations. But relations (in Postgres) extends typ

Re: recovering from "found xmin ... from before relfrozenxid ..."

Hi, On 2020-07-13 17:12:18 -0400, Robert Haas wrote: > 1. There's nothing to identify the tuple that has the problem, and no > way to know how many more of them there might be. Back-patching > b61d161c146328ae6ba9ed937862d66e5c8b035a would help with the first > part of this. Not fully, I'm afraid

Re: Stale external URL in doc?

At Mon, 13 Jul 2020 11:36:17 +0200, Daniel Gustafsson wrote in > > On 11 Jul 2020, at 05:25, Thomas Munro wrote: > > > Is it OK that I see the following warning many times when running > > "make" under src/backend/utils/mb/Unicode? It looks like this code is > > from commit 1de9cc0d. Horiguc

Re: Transactions involving multiple postgres foreign servers, take 2

I've attached the latest version patches. I've incorporated the review comments I got so far and improved locking strategy. Thanks for updating the patch! I have three questions about the v23 patches. 1. messages related to user canceling In my understanding, there are two messages which can

Re: recovering from "found xmin ... from before relfrozenxid ..."

On Mon, Jul 13, 2020 at 6:15 PM Tom Lane wrote: > Yeah, I don't care for that either. That's a pretty huge violation of our > normal back-patching rules, and I'm not convinced that it's justified. I think that our normal back-patching rules are based primarily on the risk of breaking things, and

Re: recovering from "found xmin ... from before relfrozenxid ..."

On Mon, Jul 13, 2020 at 6:38 PM Andres Freund wrote: > Not fully, I'm afraid. Afaict it doesn't currently tell you the item > pointer offset, just the block numer, right? We probably should extend > it to also include the offset... Oh, I hadn't realized that limitation. That would be good to fix.

Re: recovering from "found xmin ... from before relfrozenxid ..."

Robert Haas writes: > Oh, I hadn't realized that limitation. That would be good to fix. It > would be even better, I think, if we could have VACUUM proceed with > the rest of vacuuming the table, emitting warnings about each > instance, instead of blowing up when it hits the first bad tuple, but >

Re: recovering from "found xmin ... from before relfrozenxid ..."

On Mon, Jul 13, 2020 at 8:58 PM Tom Lane wrote: > Robert Haas writes: > > Oh, I hadn't realized that limitation. That would be good to fix. It > > would be even better, I think, if we could have VACUUM proceed with > > the rest of vacuuming the table, emitting warnings about each > > instance, in

Re: recovering from "found xmin ... from before relfrozenxid ..."

Hi, On 2020-07-13 20:47:10 -0400, Robert Haas wrote: > On Mon, Jul 13, 2020 at 6:38 PM Andres Freund wrote: > > Not fully, I'm afraid. Afaict it doesn't currently tell you the item > > pointer offset, just the block numer, right? We probably should extend > > it to also include the offset... > >

Re: recovering from "found xmin ... from before relfrozenxid ..."

On Mon, Jul 13, 2020 at 8:58 PM Tom Lane wrote: > The more that I think about it, the more I think that the proposed > functions are tools for wizards only, and so I'm getting hesitant > about having them in contrib at all. We lack a better place to > put them, but that doesn't mean they should b

Re: recovering from "found xmin ... from before relfrozenxid ..."

On Mon, Jul 13, 2020 at 9:10 PM Andres Freund wrote: > > What if clog has been truncated so that the xmin can't be looked up? > > That's possible, but probably only in cases where xmin actually > committed. Isn't that the normal case? I'm imagining something like: - Tuple gets inserted. Transact

Re: recovering from "found xmin ... from before relfrozenxid ..."

Robert Haas writes: > On Mon, Jul 13, 2020 at 8:58 PM Tom Lane wrote: >> The more that I think about it, the more I think that the proposed >> functions are tools for wizards only, and so I'm getting hesitant >> about having them in contrib at all. We lack a better place to >> put them, but that

Re: recovering from "found xmin ... from before relfrozenxid ..."

On 2020/07/14 9:41, Robert Haas wrote: On Mon, Jul 13, 2020 at 6:15 PM Tom Lane wrote: Yeah, I don't care for that either. That's a pretty huge violation of our normal back-patching rules, and I'm not convinced that it's justified. I think that our normal back-patching rules are based pri

Re: Ideas about a better API for postgres_fdw remote estimates

On Mon, Jul 6, 2020 at 11:28:28AM -0400, Stephen Frost wrote: > > Yeah, thinking about it as a function that inspects partial planner > > results, it might be useful for other purposes besides postgres_fdw. > > As I said before, I don't think this necessarily has to be bundled as > > part of postg

  1   2   >