Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Thu, Jul 2, 2020 at 8:47 AM James Coleman wrote: > It seems like the consensus over at another discussion on this topic > [1] is that we ought to go ahead and print the zeros [for machine > readable output formats], even though that creates some interesting > scenarios like the fact that disk s

Re: Reducing WaitEventSet syscall churn

On Sun, Jul 12, 2020 at 7:22 AM Tom Lane wrote: > [...complaints about 0005 and 0006...] We already have > PGEVT_CONNRESET and PGEVT_CONNDESTROY as application-visible connection > state change events, and I don't see why those aren't sufficient. I think Horiguchi-san's general idea of using even

Re: Improvements in Copy From

On Tue, Jul 14, 2020 at 11:13 AM David Rowley wrote: > > On Tue, 14 Jul 2020 at 17:22, David Rowley wrote: > > > > On Thu, 2 Jul 2020 at 00:46, vignesh C wrote: > > > b) CopyMultiInsertInfoNextFreeSlot had an unused function parameter > > > that is not being used, it can be removed. > > > > This

Re: replication_origin and replication_origin_lsn usage on subscriber

On Tue, Jul 14, 2020 at 11:14 AM Amit Kapila wrote: > > On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar wrote: > > > > On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila wrote: > > > > > > On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek wrote: > > > > > > > > > > > > If we were to support the origin forwardin

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

po 13. 7. 2020 v 15:33 odesílatel vignesh C napsal: > 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 spe

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

po 13. 7. 2020 v 20:00 odesílatel Justin Pryzby napsal: > 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. > I merged your patch - thank y

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

Hi! > 14 июля 2020 г., в 02:12, Robert Haas написал(а): > > So I have these questions: > > - Do people think it would me smart/good/useful to include something > like this in PostgreSQL? > > - If so, how? I would propose a new contrib module that we back-patch > all the way My 0.05₽. At Yan

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Thu, Jul 9, 2020 at 12:06 PM Jonathan S. Katz wrote: > On 7/2/20 11:47 AM, James Coleman wrote: > > It seems like the consensus over at another discussion on this topic > > [1] is that we ought to go ahead and print the zeros [for machine > > readable output formats], even though that creates s

RE: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM

On Tuesday, July 14, 2020 3:01 AM (GMT+9), Bossart, Nathan wrote: Hi Nathan, >On 7/13/20, 11:02 AM, "Justin Pryzby" wrote: >> Should bin/vacuumdb support this? > >Yes, it should. I've added it in v5 of the patch. Thank you for the updated patch. I've joined as a reviewer. I've also noticed tha

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

On Tue, Jul 14, 2020 at 2:02 PM vignesh C wrote: > On Tue, Jul 14, 2020 at 7:26 AM Amit Langote wrote: > > In CopyLoadRawBuf(), we could also change the condition if > > (cstate->raw_buf_index < cstate->raw_buf_len) to if (BUF_BYTES > 0), > > which looks clearer. > > > > Also, if we are going to

Re: replication_origin and replication_origin_lsn usage on subscriber

On Tue, Jul 14, 2020 at 11:00 AM Dilip Kumar wrote: > > On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila wrote: > > > > On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek wrote: > > > > > > > > > If we were to support the origin forwarding, then strictly speaking we > > > need everything only at commit time

Re: Improvements in Copy From

On Tue, 14 Jul 2020 at 17:22, David Rowley wrote: > > On Thu, 2 Jul 2020 at 00:46, vignesh C wrote: > > b) CopyMultiInsertInfoNextFreeSlot had an unused function parameter > > that is not being used, it can be removed. > > This was raised in [1]. We decided not to remove it. I just added a comme

Re: TAP tests and symlinks on Windows

On Fri, Jul 10, 2020 at 07:58:02AM -0400, Andrew Dunstan wrote: > After much frustration and gnashing of teeth here's a patch that allows > almost all the TAP tests involving symlinks to work as expected on all > Windows build environments, without requiring an additional Perl module. > I have test

Re: replication_origin and replication_origin_lsn usage on subscriber

On Thu, Jul 9, 2020 at 6:55 PM Amit Kapila wrote: > > On Thu, Jul 9, 2020 at 6:14 PM Petr Jelinek wrote: > > > > Hi, > > > > On 09/07/2020 14:34, Amit Kapila wrote: > > > On Thu, Jul 9, 2020 at 5:16 PM Petr Jelinek wrote: > > >> > > >> On 09/07/2020 13:10, Amit Kapila wrote: > > >>> On Thu, Feb

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

út 14. 7. 2020 v 0:37 odesílatel David G. Johnston < david.g.johns...@gmail.com> napsal: > 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

Re: Improvements in Copy From

On Thu, 2 Jul 2020 at 00:46, vignesh C wrote: > b) CopyMultiInsertInfoNextFreeSlot had an unused function parameter > that is not being used, it can be removed. This was raised in [1]. We decided not to remove it. David [1] https://www.postgresql.org/message-id/flat/CAKJS1f-A5aYvPHe10Wy9LjC4Rz

Re: ALTER TABLE validate foreign key dependency problem

On Mon, 13 Jul 2020 at 08:13, Simon Riggs wrote: > > On Sun, 12 Jul 2020 at 05:51, David Rowley wrote: > >> >> > I also considered that we could just delay all foreign key validations >> > until phase 3, but I ended up just doing then only when a rewrite is >> > pending. >> >> I still wonder if i

Re: Improvements in Copy From

On Wed, Jul 1, 2020 at 6:16 PM vignesh C wrote: > Attached patch has the changes for the same. > Thoughts? > Added a commitfest entry for this: https://commitfest.postgresql.org/29/2642/ Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com

Re: Stale external URL in doc?

At Tue, 14 Jul 2020 15:40:41 +1200, Thomas Munro wrote in > On Tue, Jul 14, 2020 at 3:27 PM Kyotaro Horiguchi > wrote: > > A. I didn't find the files gb-18030-2000.xml and windows-949-2000.xml > > in the ICU site. We have our own copy in our repository so it's not > > a serious problem but

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

On Tue, Jul 14, 2020 at 7:26 AM Amit Langote wrote: > > Good idea, thanks. > > In CopyLoadRawBuf(), we could also change the condition if > (cstate->raw_buf_index < cstate->raw_buf_len) to if (BUF_BYTES > 0), > which looks clearer. > > Also, if we are going to use the macro more generally, let's m

Re: Fix header identification

On Mon, Jul 13, 2020 at 09:31:58AM -0700, Jesse Zhang wrote: > PFA a patch that fixes up the identification for 4 header files. Thanks, Jesse. Applied. -- Michaelx signature.asc Description: PGP signature

Re: min_safe_lsn column in pg_replication_slots view

At Mon, 13 Jul 2020 13:52:12 -0400, Alvaro Herrera wrote in > 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. -

Re: GSSENC'ed connection stalls while reconnection attempts.

At Mon, 13 Jul 2020 11:08:09 -0400, Tom Lane wrote in > Kyotaro Horiguchi writes: > > At Fri, 10 Jul 2020 12:01:10 -0400, Tom Lane wrote > > intgl> >> I'm disinclined to mess with that, because (a) I don't think it's > > the > >> actual source of the problem, and (b) it would affect way more

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

On Mon, Jul 13, 2020 at 09:52:12PM +0900, Michael Paquier wrote: > Yeah. We also recommend to look at tableam.h in the docs, so while > usually I just bother fixing comments on HEAD, it would be better to > back-patch this one. Committed and back-patched down to 12. Thanks, Suzuki-san. -- Michae

Re: max_slot_wal_keep_size and wal_keep_segments

On 2020/07/13 16:01, Kyotaro Horiguchi wrote: 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 wrot

Re: Stale external URL in doc?

On Tue, Jul 14, 2020 at 3:27 PM Kyotaro Horiguchi wrote: > A. I didn't find the files gb-18030-2000.xml and windows-949-2000.xml > in the ICU site. We have our own copy in our repository so it's not > a serious problem but I'm not sure what we should do for this. The patch I posted earlier f

Re: Stale external URL in doc?

It is found to be a time capsule full of worms.. At Tue, 14 Jul 2020 09:00:11 +0900 (JST), Kyotaro Horiguchi wrote in > > Use of uninitialized value $b1_lower in printf at convutils.pm line 560. > > Mmm. I see the same, too. I'm looking into that. There are three easy-to-fix issues: 1. The s

Re: POC and rebased patch for CSN based snapshots

On 2020/07/14 11:02, movead...@highgo.ca wrote: When checking each tuple visibility, we always have to get the CSN corresponding to XMIN or XMAX from CSN SLRU. In the past discussion, there was the suggestion that CSN should be stored in the tuple header or somewhere (like hint bit) to avoid

Re: Default setting for enable_hashagg_disk

On Mon, Jul 13, 2020 at 9:50 PM Peter Geoghegan wrote: > > 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

Re: Transactions involving multiple postgres foreign servers, take 2

On 2020/07/14 9:08, Masahiro Ikeda wrote: 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! +1 I'm interested in these patches and now studying them. While checking the behaviors of the

Re: POC and rebased patch for CSN based snapshots

>When checking each tuple visibility, we always have to get the CSN >corresponding to XMIN or XMAX from CSN SLRU. In the past discussion, >there was the suggestion that CSN should be stored in the tuple header >or somewhere (like hint bit) to avoid the overhead by very frequehntly >lookup for CSN

Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away

> > You could get a backend's PID using PQbackendPID and then kill it by > calling pg_terminate_backend() to kill the remote backend to automate > scenario of remote backend being killed. > I already added the test case in v2 patch itself(added one more test case in v3 patch), using the similar ap

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

On Mon, Jul 13, 2020 at 11:58 PM Bharath Rupireddy wrote: > > 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 {\ > > +

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >