Re: pgbench - allow to create partitioned tables

On Mon, Aug 26, 2019 at 11:04 PM Fabien COELHO wrote: > > > > Just one suggestion --partition-method option should be made dependent > > on --partitions, because it has no use unless used with --partitions. > > What do you think? > Some comments: * + case 11: /* partitions */ +

Re: Change atoi to strtol in same place

On Mon, Sep 09, 2019 at 11:02:49PM -0500, Joe Nelson wrote: > Alvaro Herrera from 2ndQuadrant wrote: > > Okay, so who is submitting a new version here? Surafel, Joe? > > I've attached a revision that uses pg_strtoint64 from str2int-10.patch > (posted in ). My patch is > based off that one and

Re: PostgreSQL 12 Beta 4

On Tue, Sep 10, 2019 at 09:34:34AM +0530, Sandeep Thakkar wrote: > What's the date for PostgreSQL 12 GA? This is not decided yet. -- Michael signature.asc Description: PGP signature

Re: PostgreSQL 12 Beta 4

Hi What's the date for PostgreSQL 12 GA? On Fri, Sep 6, 2019 at 1:57 AM Jonathan S. Katz wrote: > Hi, > > PostgreSQL 12 Beta 4 will be released on 2019-09-12. Please make sure > that fixes for bugs and other open items[1] are committed by the end of > the weekend. > > Thanks for all of your

Re: Change atoi to strtol in same place

Alvaro Herrera from 2ndQuadrant wrote: > Okay, so who is submitting a new version here? Surafel, Joe? I've attached a revision that uses pg_strtoint64 from str2int-10.patch (posted in ). My patch is based off that one and c5bc7050af. It covers the same front-end utilities as

Re: refactoring - share str2*int64 functions

On Mon, Sep 09, 2019 at 05:27:04AM -0700, Andres Freund wrote: > On 2019-09-09 20:57:46 +0900, Michael Paquier wrote: > But ISTM all of them ought to just use the C types, rather than the SQL > types however. Since in the above proposal the caller determines the > type names, if you want a

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On Tue, Sep 10, 2019 at 10:21 AM Amit Kapila wrote: > > On Mon, Sep 9, 2019 at 6:22 PM Alvaro Herrera from 2ndQuadrant > wrote: > > > > On 2019-Sep-08, Amit Kapila wrote: > > > > > On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada > > > wrote: > > > > > > > > Thanks. I hope the attached new patch

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On Tue, Sep 10, 2019 at 8:03 AM Masahiko Sawada wrote: > > On Tue, Sep 10, 2019 at 10:21 AM Amit Kapila wrote: > > > > On Mon, Sep 9, 2019 at 6:22 PM Alvaro Herrera from 2ndQuadrant > > wrote: > > > I think that other table AMs are not necessarily going to use the same > > > infomask flags, so

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On Tue, Sep 10, 2019 at 07:51:08AM +0530, Amit Kapila wrote: > It will look bit strange to use heapam as a prefix for this function > when all others use heap. I guess if we want to keep it AM specific, > then the proposed name (heap_infomask_flags) is better or > alternatively we can consider

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On Mon, Sep 9, 2019 at 6:22 PM Alvaro Herrera from 2ndQuadrant wrote: > > On 2019-Sep-08, Amit Kapila wrote: > > > On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada > > wrote: > > > > > > Thanks. I hope the attached new patch fixes this issue. > > * > > +-- decode infomask flags as human readable

Re: refactoring - share str2*int64 functions

On Mon, Sep 09, 2019 at 03:17:38AM -0700, Andres Freund wrote: > On 2019-09-09 14:28:14 +0900, Michael Paquier wrote: >> @@ -80,7 +81,7 @@ >> #define READ_UINT64_FIELD(fldname) \ >> token = pg_strtok(); /* skip :fldname */ \ >> token = pg_strtok(); /* get field

Re: Should we add xid_current() or a int8->xid cast?

Thomas Munro writes: > On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro wrote: >> Adding to CF. > Rebased. An OID clashed so re-roll the dice. Also spotted a typo. FWIW, I'd move *all* the OIDs added by this patch up to >= 8000. I don't feel a strong need to fill in the gaps in the low-numbered

Re: Should we add xid_current() or a int8->xid cast?

On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro wrote: > Adding to CF. Rebased. An OID clashed so re-roll the dice. Also spotted a typo. -- Thomas Munro https://enterprisedb.com 0001-Add-SQL-type-xid8-to-expose-FullTransactionId-to--v2.patch Description: Binary data

Re: Consolidate 'unique array values' logic into a reusable function?

On Fri, Aug 30, 2019 at 3:34 PM Thomas Munro wrote: > Adding to CF. Rebased due to bitrot. Spotted one more place to use this, in src/backend/utils/adt/txid.c. -- Thomas Munro https://enterprisedb.com 0001-Consolidate-code-that-makes-a-sorted-array-unique-v2.patch Description: Binary data

Re: [HACKERS] CLUSTER command progress monitor

On Fri, Sep 6, 2019 at 5:11 AM Robert Haas wrote: > On Fri, Sep 6, 2019 at 1:44 AM Michael Paquier wrote: > > I don't see exactly why we could not switch to a fixed number of > > slots, say 8, with one code path to start a progress which adds an > > extra report on the stack, one to remove one

Re: Shared Memory: How to use SYSV rather than MMAP ?

On Wed, Sep 4, 2019 at 10:30 AM Alvaro Herrera wrote: > On 2019-Feb-03, Thomas Munro wrote: > > On Sat, Feb 2, 2019 at 12:49 AM Thomas Munro > > wrote: > > > I am planning to commit the 0001 patch shortly, unless there are > > > objections. I attach a new version, which improves the

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

On Wed, Sep 04, 2019 at 09:17:10PM +0200, Tomas Vondra wrote: On Wed, Sep 04, 2019 at 11:37:48AM +0200, Rafia Sabih wrote: On Tue, 30 Jul 2019 at 02:17, Tomas Vondra wrote: On Sun, Jul 21, 2019 at 01:34:22PM +0200, Tomas Vondra wrote: ... I wonder if we're approaching this wrong. Maybe we

Re: Replication & recovery_min_apply_delay

On Wed, Sep 4, 2019 at 4:37 PM Konstantin Knizhnik wrote: > receivedUpto is just static variable in xlog.c, maintained by WAL receiver. > But as I mentioned above, WAL receiver is not started at the moment when > we need to know LSN of last record. > > Certainly it should be possible to somehow

Re: [PATCH] ltree, lquery, and ltxtquery binary protocol support

Hi! On Sun, Aug 18, 2019 at 6:53 PM Nino Floris wrote: > Attached is a patch to support send/recv on ltree, lquery and ltxtquery. > I'm a contributor to the Npgsql .NET PostgreSQL driver and we'll be > the first to have official support once those ltree changes have been > released. > You can

Re: Rethinking opclass member checks and dependency strength

On Sun, Aug 18, 2019 at 10:00 PM Tom Lane wrote: > Here's a preliminary patch along these lines. It adds an AM callback > that can adjust the dependency types before they're entered into > pg_depend. There's a lot of stuff that's open for debate and/or > remains to be done: > > * Is the

Re: [PATCH] kNN for btree

On Sun, Sep 8, 2019 at 11:35 PM Alexander Korotkov wrote: > I'm going to push 0001 changing "attno >= 1" to assert. Pushed. Rebased patchset is attached. I propose to limit consideration during this commitfest to this set of 7 remaining patches. The rest of patches could be considered later.

Re: Bug in GiST paring heap comparator

On Mon, Sep 9, 2019 at 8:32 PM Nikita Glukhov wrote: > On 08.09.2019 22:32, Alexander Korotkov wrote: > > > On Fri, Sep 6, 2019 at 5:44 PM Alexander Korotkov > > wrote: > >> I'm going to push both if no objections. > > So, pushed! > > Two years ago there was a similar patch for this issue: >

Re: add a MAC check for TRUNCATE

On Fri, Sep 6, 2019 at 9:09 PM Joe Conway wrote: > > On 9/6/19 8:07 PM, Tom Lane wrote: > > Joe Conway writes: > >> On 9/6/19 2:18 PM, Tom Lane wrote: > >>> sepgsql hasn't worked on RHEL6 in a long time, if ever; it requires > >>> a newer version of libselinux than what ships in RHEL6. So I'm

Re: Does PostgreSQL support debian Linux on Arm CPU Platform?

On 9/9/19 11:07 AM, gc...@sina.cn wrote: > Hi,I just want know does PostgreSQL support debian Linux with ARM CPU > Platform,Thank you! See cheers andrew -- Andrew Dunstan

Re: pg_regress restart cluster?

Jeremy Finzel writes: > I am using the basic extension building infrastructure with sql and > expected files, but what I want to test is changing a config setting and > then restarting the cluster with shared_preload_libraries in place. Is > there a canonical way to do this or does anyone have

Sloppy port assignment in src/test/ldap/

I wondered about this transient failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake=2019-09-09%2008%3A48%3A25 The only information that was captured was # Running: /usr/sbin/slapd -f /home/bf/bfr/root/HEAD/pgsql.build/src/test/ldap/tmp_check/slapd.conf -h

Re: Bug in GiST paring heap comparator

On 08.09.2019 22:32, Alexander Korotkov wrote: On Fri, Sep 6, 2019 at 5:44 PM Alexander Korotkov wrote: I'm going to push both if no objections. So, pushed! Two years ago there was a similar patch for this issue:

Re: Libpq support to connect to standby server as priority

Question about 0001. In the CONNECTION_SETENV state, you end by falling through to the CONNECTION_CHECK_TARGET case; but in that switch it seems a bit unnatural to do that. I think doing "goto keep_trying" is another way of doing the same thing, but more in line with what every other piece of

Re: having issues with PG12 debian packaging repository

On Mon, Sep 9, 2019 at 6:03 PM Murat Tuncer wrote: > > On Sun, Sep 8, 2019, 21:43 Magnus Hagander wrote: > >> On Wed, Sep 4, 2019 at 5:43 PM Murat Tuncer >> wrote: >> >>> Hello hackers >>> >>> I am getting sporadic errors when I tried to use PG12 bionic debian >>> repository. >>> >>> Here is

Does PostgreSQL support debian Linux on Arm CPU Platform?

Hi,I just want know does PostgreSQL support debian Linux with ARM CPU Platform,Thank you!

pg_upgrade issues

pgjdbc has a bug report which is as follows: The database has a table that has a description and a constraint. The constraint also has a description. somehow the constraint and the table end up with the same OID's after pg_upgrade. My understanding of pg_upgrade suggests that shouldn't happen ?

Re: having issues with PG12 debian packaging repository

On Sun, Sep 8, 2019, 21:43 Magnus Hagander wrote: > On Wed, Sep 4, 2019 at 5:43 PM Murat Tuncer wrote: > >> Hello hackers >> >> I am getting sporadic errors when I tried to use PG12 bionic debian >> repository. >> >> Here is the error message that is result of apt-get update. >> --- >>

Re: using explicit_bzero

Hi, On 2019-09-05 08:38:36 +0200, Peter Eisentraut wrote: > On 2019-09-05 04:12, Michael Paquier wrote: > > On Wed, Sep 04, 2019 at 04:38:21PM -0400, Alvaro Herrera wrote: > >> Marked RfC. Can we get on with this? > > > > FWIW, I have been able to test this one on Windows with MSVC and > >

Re: Built-in connection pooler

On 06.09.2019 19:41, Konstantin Knizhnik wrote: On 06.09.2019 1:01, Jaime Casanova wrote: Sadly i got a lot of FAILED tests, i'm attaching the diffs on regression with installcheck and installcheck-parallel. btw, after make installcheck-parallel i wanted to do a new test but wasn't able to

Re: Hypothetical indexes using BRIN broken since pg10

Alvaro Herrera from 2ndQuadrant writes: > On 2019-Sep-02, Tom Lane wrote: >> The right answer IMO is basically for the brinGetStats call to go >> away from brincostestimate and instead happen during plancat.c's >> building of the IndexOptInfo. In the case of a hypothetical index, >> it'd fall to

Re: Hypothetical indexes using BRIN broken since pg10

On 2019-Sep-02, Tom Lane wrote: > Julien Rouhaud writes: > > On Fri, Jul 26, 2019 at 1:34 PM Heikki Linnakangas wrote: > >> The patch assumes the default pages_per_range setting, but looking at > >> the code at https://github.com/HypoPG/hypopg, the extension actually > >> takes pages_per_range

Re: Set of header files for Ryu floating-point stuff in src/common/

> "Michael" == Michael Paquier writes: Michael> Hi all, Michael> (Andrew G. in CC) Michael> We have the following set of header files in src/common/: Michael> digit_table.h Michael> d2s_full_table.h Michael> d2s_intrinsics.h Michael> ryu_common.h Michael> Shouldn't all these files

Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)

> > Thank for rebasing. > > I didn't like 0001 very much. > > * It seems now would be the time to stop pretending we're using a file > called recovery.conf; I know we still support older server versions that > use that file, but it sounds like we should take the opportunity to > rename the

Re: Commit fest 2019-09

On this CF's second week, numbers are: statusstring │ week1 │ week2 ┼───┼─── Needs review │ 165 │ 138 Waiting on Author │30 │44 Ready for Committer│11 │ 5 Returned with Feedback │ 1 │ 4 Moved to next CF

Re: [PATCH] Fix Proposal - Deadlock Issue in Single User Mode When IO Failure Occurs

On Sat, Jul 27, 2019 at 6:22 AM Chengchao Yu wrote: > > Thus, I have updated the patch v3 according to your suggestions. Could you > help to review again? > Please let me know should you have more suggestions or feedbacks. > I have tried to look into this patch and I don't think it fixes the

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On 2019-Sep-08, Amit Kapila wrote: > On Thu, Sep 5, 2019 at 2:17 PM Masahiko Sawada wrote: > > > > Thanks. I hope the attached new patch fixes this issue. > * > +-- decode infomask flags as human readable flag names > +CREATE FUNCTION heap_infomask_flags( > + infomask integer, > +

Re: block-level incremental backup

On Fri, Aug 30, 2019 at 6:52 PM Jeevan Ladhe wrote: > Here are some comments: > Or maybe we can just say: > "cannot verify checksum in file \"%s\"" if checksum requested, disable the > checksum and leave it to the following message: > > + ereport(WARNING, > +

Re: msys2 vs pg_upgrade/test.sh

On 9/9/19 4:48 AM, Peter Eisentraut wrote: > On 2019-09-09 00:06, Andrew Dunstan wrote: >> Diagnosing this took quite a lot of time and detective work. For some >> reason I don't quite understand, when calling the Windows command >> processor in a modern msys2/WindowsServer2019 installation, you

Re: refactoring - share str2*int64 functions

Hi, On 2019-09-09 20:57:46 +0900, Michael Paquier wrote: > > I don't really buy that saving a few copies of a strings is worth that > > much. But if you really want to do that, the right approach imo would be > > to move the error reporting into a separate function. I.e. something > > > > void

Re: Compiler warnings with MinGW

On Sat, Sep 7, 2019 at 4:58 AM Michael Paquier wrote: > On Sat, Sep 07, 2019 at 12:11:25AM +0200, Peter Eisentraut wrote: > > I'm not sure exactly what the upstream of mingw is these days, but I > > think the original issue that led to 811be893 has long been fixed [0], > > and the other stuff in

Set of header files for Ryu floating-point stuff in src/common/

Hi all, (Andrew G. in CC) We have the following set of header files in src/common/: digit_table.h d2s_full_table.h d2s_intrinsics.h ryu_common.h Shouldn't all these files be in src/include/common/ instead? HEAD is not really consistent with the common practice here. Thanks, -- Michael

Re: refactoring - share str2*int64 functions

On Mon, Sep 09, 2019 at 03:17:38AM -0700, Andres Freund wrote: > On 2019-09-09 14:28:14 +0900, Michael Paquier wrote: > I *VEHEMENTLY* oppose the introduction of any future pseudo-generic > routines taking the type width as a parameter. They're weakening the > type system and they're unnecessarily

Re: block-level incremental backup

On Tue, Sep 3, 2019 at 12:11 PM Dilip Kumar wrote: > On Fri, Aug 16, 2019 at 3:54 PM Jeevan Chalke > wrote: > > > 0003: > +/* > + * When to send the whole file, % blocks modified (90%) > + */ > +#define WHOLE_FILE_THRESHOLD 0.9 > > How this threshold is selected. Is it by some test? >

Re: block-level incremental backup

On Wed, Sep 4, 2019 at 5:21 PM Dilip Kumar wrote: > > I have not yet completed the review for 0004, but I have few more > comments. Tomorrow I will try to complete the review and some testing > as well. > > 1. It seems that the output full backup generated with > pg_combinebackup also contains

Re: block-level incremental backup

On Tue, Aug 27, 2019 at 11:59 PM Robert Haas wrote: > On Fri, Aug 16, 2019 at 6:23 AM Jeevan Chalke > wrote: > > [ patches ] > > Reviewing 0002 and 0003: > > - Commit message for 0003 claims magic number and checksum are 0, but > that (fortunately) doesn't seem to be the case. > Oops, updated

Re: block-level incremental backup

On Tue, Aug 27, 2019 at 4:46 PM vignesh C wrote: > Few comments: > Comment: > + buf = (char *) malloc(statbuf->st_size); > + if (buf == NULL) > + ereport(ERROR, > + (errcode(ERRCODE_OUT_OF_MEMORY), > + errmsg("out of memory"))); > + > + if ((cnt = fread(buf, 1, statbuf->st_size, fp)) > 0) > + {

Re: block-level incremental backup

Hi, Attached new set of patches adding support for the tablespace handling. This patchset also fixes the issues reported by Vignesh, Robert, Jeevan Ladhe, and Dilip Kumar. Please have a look and let me know if I missed any comments to account. Thanks -- Jeevan Chalke Technical Architect,

Re: Fetching timeline during recovery

On Sat, Sep 7, 2019 at 12:06 AM Jehan-Guillaume de Rorthais wrote: > > On Wed, 4 Sep 2019 00:32:03 +0900 > Fujii Masao wrote: > > > On Mon, Jul 29, 2019 at 7:26 PM Jehan-Guillaume de Rorthais > > wrote: > > > > > > On Fri, 26 Jul 2019 18:22:25 +0200 > > > Jehan-Guillaume de Rorthais wrote: > >

Re: Minimal logical decoding on standbys

On Tue, 3 Sep 2019 at 23:10, Alvaro Herrera wrote: > > On 2019-Jul-19, Amit Khandekar wrote: > > > Attached are the split patches. Included is an additional patch that > > has doc changes. Here is what I have added in the docs. Pasting it > > here so that all can easily spot how it is supposed to

Re: Batch insert in CTAS/MatView code

On Fri, Aug 2, 2019 at 2:55 AM Heikki Linnakangas wrote: > On 17/06/2019 15:53, Paul Guo wrote: > > I noticed that to do batch insert, we might need additional memory copy > > sometimes comparing with "single insert" > > (that should be the reason that we previously saw a bit regressions) so a >

Re: Attempt to consolidate reading of XLOG page

Alvaro Herrera wrote: > Hi Antonin, could you please rebase again? Attached. -- Antonin Houska Web: https://www.cybertec-postgresql.com >From 7b15d7bbdae13c743ddeae10b8ff79e9b02d8243 Mon Sep 17 00:00:00 2001 From: Antonin Houska Date: Mon, 9 Sep 2019 11:53:54 +0200 Subject: [PATCH 1/4]

Re: refactoring - share str2*int64 functions

Hi, On 2019-09-09 14:28:14 +0900, Michael Paquier wrote: > On Thu, Sep 05, 2019 at 03:52:48PM +0900, Michael Paquier wrote: > > Right, there was this part. This brings also the point of having one > > interface for the backend as all the error messages for the backend > > are actually the same,

patch: psql - enforce constant width of last column

Hi When I played with vertical cursor support I got badly displayed last columns when border was not 2. Only when border is 2, then psql displays last column with same width for each row. I think so we can force column width alignment for any border styles today (for alignment and wrapping

Re: BUG #15977: Inconsistent behavior in chained transactions

It looks good now. Thank you again. 2019年9月9日(月) 17:43 Peter Eisentraut : > On 2019-09-09 05:58, fn ln wrote: > > Confirmed. Thank you all for your help. > > > > The only concern is that this test: > > > >SET TRANSACTION READ WRITE\; COMMIT AND CHAIN; -- error > >SHOW

Re: msys2 vs pg_upgrade/test.sh

On 2019-09-09 00:06, Andrew Dunstan wrote: > Diagnosing this took quite a lot of time and detective work. For some > reason I don't quite understand, when calling the Windows command > processor in a modern msys2/WindowsServer2019 installation, you need to > double the slash, thus: > >     cmd

Re: BUG #15977: Inconsistent behavior in chained transactions

On 2019-09-09 05:58, fn ln wrote: > Confirmed. Thank you all for your help. > > The only concern is that this test: > >    SET TRANSACTION READ WRITE\; COMMIT AND CHAIN;  -- error >    SHOW transaction_read_only; > >    SET TRANSACTION READ WRITE\; ROLLBACK AND CHAIN;  -- error >    SHOW

Re: [HACKERS] CLUSTER command progress monitor

On Fri, Sep 06, 2019 at 10:27:02AM -0400, Alvaro Herrera from 2ndQuadrant wrote: > That said, I did spend some time on this type of issue when doing CREATE > INDEX support; you can tell because I defined the columns for block > numbers in a scan separately from CREATE INDEX specific fields, >

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On Fri, Aug 30, 2019 at 7:06 PM Nikhil Sontakke wrote: > > Hi, > > > > This patch has been around for some time now, the last version fails to > > > apply cleanly and in-depth reviews have happened. I am moving that to > > > the next CF, waiting on its author. > > > > Unfortunately, nothing was

RE: [PATCH] Speedup truncates of relation forks

On Friday, September 6, 2019 11:51 PM (GMT+9), Alvaro Herrera wrote: Hi Alvaro, Thank you very much for the review! > On 2019-Sep-05, Jamison, Kirk wrote: > > > I also mentioned it from my first post if we can just remove this dead code. > > If not, it would require to modify the function