pg_basebackup failure after setting default_table_access_method option

Hi, *I noticed pg_basebackup failure when default_table_access_method option is set.* *Test steps:* Step 1: Init database ./initdb -D data Step 2: Start Server ./postgres -D data & Step 3: Set Guc option export PGOPTIONS='-c default_table_access_method=zheap' Step 4: Peform backup

Re: pg_basebackup failure after setting default_table_access_method option

Thanks Hari for helping in verifying. Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com On Thu, Jun 6, 2019 at 6:50 AM Haribabu Kommi wrote: > > On Thu, Jun 6, 2019 at 1:46 AM vignesh C wrote: > >> >> Hi, >> >> *I noticed pg_basebackup failure when d

Re: Is ParsePrepareRecord dead function

On Tue, Jul 30, 2019 at 2:34 AM Alvaro Herrera wrote: > > On 2019-Jul-29, vignesh C wrote: > > > On Mon, Jul 29, 2019 at 8:24 PM Robert Haas wrote: > > > > > > On Mon, Jul 29, 2019 at 4:10 AM vignesh C wrote: > > > > I could not loc

Re: Unused header file inclusion

On Wed, Jul 31, 2019 at 12:26 PM Andres Freund wrote: > > Hi, > > On 2019-07-31 11:19:08 +0530, vignesh C wrote: > > I noticed that there are many header files being > > included which need not be included. > > I have tried this in a few files and found the

Re: block-level incremental backup

On Thu, Aug 1, 2019 at 5:06 PM Jeevan Chalke wrote: > > On Tue, Jul 30, 2019 at 9:39 AM Jeevan Chalke > wrote: >> >> I am almost done writing the patch for pg_combinebackup and will post soon. > > > Attached patch which implements the pg_combinebackup utility used to combine > full basebackup

Re: block-level incremental backup

On Fri, Aug 16, 2019 at 8:07 PM Ibrar Ahmed wrote: > > What do you mean by bigger file, a file greater than 1GB? In which case you > get file > 1GB? > > > Few comments: Comment: + buf = (char *) malloc(statbuf->st_size); + if (buf == NULL) + ereport(ERROR, + (errcode(ERRCODE_OUT_OF_MEMORY), +

Re: POC: Cleaning up orphaned files using undo logs

Hi Thomas, While testing one of the recovery scenarios I found one issue: FailedAssertion("!(logno == context->recovery_logno) The details of the same is mentioned below: The context's try_location was not updated in UndoLogAllocateInRecovery, in PrepareUndoInsert the try_location was updated

Re: psql - improve test coverage from 41% to 88%

On Thu, Sep 12, 2019 at 11:56 AM Fabien COELHO wrote: > > > On Wed, Sep 11, 2019 at 10:52:01PM +0200, Fabien COELHO wrote: > >> AFAICR this is because the coverage was not the same:-) Some backslash > >> commands just skip silently to the end of the line, so that intermediate > >> \commands on

Re: psql - improve test coverage from 41% to 88%

On Thu, Sep 12, 2019 at 2:15 PM Fabien COELHO wrote: > > > >> Ok. Rebased version added, with some minor changes to improve readability > >> (comments, variables). > > > > Few comments: [...] > > > > Commented line can be removed > > Commented lines can be removed > > ??? can be changed to some

Re: block-level incremental backup

On Mon, Sep 9, 2019 at 4:51 PM Jeevan Chalke wrote: > > > > 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, >> + (e

Re: Psql patch to show access methods info

On Sat, Sep 14, 2019 at 1:45 PM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > > On Sat, Sep 14, 2019 at 10:39 AM Alexander Korotkov > wrote: > > On Sat, Sep 14, 2019 at 12:36 AM Alvaro Herrera > > wrote: > > > On 2019-Aug-06, Alexander Korotkov wrote: > > > > > > > Revised patch is

Re: psql - improve test coverage from 41% to 88%

On Thu, Sep 12, 2019 at 4:49 PM Fabien COELHO wrote: > > > >> Here is a v5. > > > Few more in icommand_checks subroutine: > > Few unwanted code can be removed. > > Indeed, more debug and test code. > > Attached v6 fixes these, and I checked for remaining scrubs without > finding any. > Few

Re: progress report for ANALYZE

On Thu, Sep 5, 2019 at 2:31 AM Alvaro Herrera wrote: > > There were some minor problems in v5 -- bogus Docbook as well as > outdated rules.out, small "git diff --check" complaint about whitespace. > This v6 (on today's master) fixes those, no other changes. > + + The command is

Re: dropdb --force

On Wed, Sep 18, 2019 at 8:30 AM Pavel Stehule wrote: > > Hi Pavel, One Comment: In the documentation we say drop database will fail after 60 seconds FORCE Attempt to terminate all existing connections to the target database. This will fail, if current

Re: dropdb --force

On Wed, Sep 18, 2019 at 9:41 AM Pavel Stehule wrote: > > > > st 18. 9. 2019 v 5:59 odesílatel vignesh C napsal: >> >> On Wed, Sep 18, 2019 at 8:30 AM Pavel Stehule >> wrote: >> > >> > >> Hi Pavel, >> >> One Comment: >&

Re: Option to dump foreign data in pg_dump

On Mon, Jul 15, 2019 at 6:09 PM Luis Carril wrote: > > On 15.07.19 12:06, Daniel Gustafsson wrote: > Few comments: As you have specified required_argument in above: + {"include-foreign-data", required_argument, NULL, 11}, The below check may not be required: + if (strcmp(optarg, "") == 0) + { +

Re: Option to dump foreign data in pg_dump

On Thu, Sep 19, 2019 at 3:08 PM vignesh C wrote: > > On Mon, Jul 15, 2019 at 6:09 PM Luis Carril wrote: > > > > On 15.07.19 12:06, Daniel Gustafsson wrote: > > > Few comments: > > As you have specified required_argument in above: > + {"include-f

Re: Unused struct member in pgcrypto pgp.c

On Tue, Jul 30, 2019 at 9:19 PM Daniel Gustafsson wrote: > > Hi, > > In contrib/pgcrypto/pgp.c we have a struct member int_name in digest_info > which > isn’t used, and seems to have never been used (a potential copy/pasteo from > the > cipher_info struct?). Is there a reason for keeping this,

Unused header file inclusion

Hi, I noticed that there are many header files being included which need not be included. I have tried this in a few files and found the compilation and regression to be working. I have attached the patch for the files that I tried. I tried this in CentOS, I did not find the header files to be

Re: Unused header file inclusion

On Wed, Jul 31, 2019 at 11:26 AM Michael Paquier wrote: > > On Wed, Jul 31, 2019 at 11:19:08AM +0530, vignesh C wrote: > > I noticed that there are many header files being included which need > > not be included. I have tried this in a few files and found the > > co

Re: Unused header file inclusion

On Wed, Jul 31, 2019 at 11:55 AM Amit Kapila wrote: > > On Wed, Jul 31, 2019 at 11:31 AM vignesh C wrote: > > > > On Wed, Jul 31, 2019 at 11:26 AM Michael Paquier > > wrote: > > > > > > On Wed, Jul 31, 2019 at 11:19:08AM +0530, vignesh C wrote: &g

Re: SegFault on 9.6.14

On Wed, Jul 31, 2019 at 9:37 AM Amit Kapila wrote: > > On Wed, Jul 31, 2019 at 12:05 AM Robert Haas wrote: > > > > On Thu, Jul 18, 2019 at 9:45 AM Tom Lane wrote: > > > I think this is going in the wrong direction. Nodes should *always* > > > assume that a rescan is possible until ExecEndNode

Re: Store FullTransactionId in TwoPhaseFileHeader/GlobalTransactionData

On Mon, Aug 5, 2019 at 8:31 AM Andres Freund wrote: > > Hi, > > On 2019-08-05 14:44:37 +1200, Thomas Munro wrote: > > Yeah. I think we're agreed for now that we don't want to change > > procarray (though we still need to figure out how to compute the 64 > > bit horizons correctly and efficiently)

Re: block-level incremental backup

On Tue, Jul 30, 2019 at 1:58 AM Robert Haas wrote: > > On Wed, Jul 10, 2019 at 2:17 PM Anastasia Lubennikova > wrote: > > In attachments, you can find a prototype of incremental pg_basebackup, > > which consists of 2 features: > > > > 1) To perform incremental backup one should call

Store FullTransactionId in TwoPhaseFileHeader/GlobalTransactionData

Hi, In the undo system, we use full-transaction-id for transactions. For rollback of prepared transactions, we were planning to use FullTransactionId by combining TransactionId and epoch, but as suggested by multiple people in that email chain [1][2], the better idea is to store

Is ParsePrepareRecord dead function

Hi, I could not locate the caller of ParsePrepareRecord function in twophase.c. Any idea how it gets called? or Is it a dead function? Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com

Re: Is ParsePrepareRecord dead function

On Mon, Jul 29, 2019 at 8:24 PM Robert Haas wrote: > > On Mon, Jul 29, 2019 at 4:10 AM vignesh C wrote: > > I could not locate the caller of ParsePrepareRecord function in twophase.c. > > Any idea how it gets called? > > or > > Is it a dead function? > &

Re: Store FullTransactionId in TwoPhaseFileHeader/GlobalTransactionData

On Thu, Aug 1, 2019 at 5:36 PM Thomas Munro wrote: > > Hi Vignesh, > > On Thu, Aug 1, 2019 at 9:32 PM vignesh C wrote: > > In the undo system, we use full-transaction-id for transactions. For > > rollback of prepared transactions, we were planning to use > >

Re: block-level incremental backup

Hi Jeevan, The idea is very nice. When Insert/update/delete and truncate/drop happens at various combinations, How the incremental backup handles the copying of the blocks? On Wed, Jul 17, 2019 at 8:12 PM Jeevan Chalke wrote: > > > > On Wed, Jul 17, 2019 at 7:38 PM Ibrar Ahmed wrote: >> >> >>

Re: block-level incremental backup

om the checkpoint onwards up to a consistent point. > > My two cents! > > Regards, > Jeevan Ladhe > > On Sat, Jul 20, 2019 at 11:22 PM vignesh C wrote: >> >> Hi Jeevan, >> >> The idea is very nice. >> When Insert/update/delete and truncate/drop hap

Re: psql ctrl+f skips displaying of one record and displays skipping one line

I'm able to get the same behaviour in centos as well. Should we do anything to handle this in Postgres or any documentation required? On Wed, Jul 17, 2019 at 10:05 AM Tom Lane wrote: > Thomas Munro writes: > > Pretty sure this is coming from your system's pager. You can see the > > same thing

psql ctrl+f skips displaying of one record and displays skipping one line

Hi, One observation when we execute a select query having results more than the screen space available and press ctrl+f to display the remaining records, one of the record was not displayed and the message "...skipping one line" was displayed. I'm not sure if this is intentional behaviour.

Re: psql ctrl+f skips displaying of one record and displays skipping one line

Thanks Tom. That sounds good to me. On Wed, Jul 17, 2019 at 10:17 AM Tom Lane wrote: > vignesh C writes: > > I'm able to get the same behaviour in centos as well. > > Should we do anything to handle this in Postgres or any documentation > > required? > &g

Re: POC: Cleaning up orphaned files using undo logs

Hi, I have done some review of undolog patch series and here are my comments: 0003-Add-undo-log-manager.patch 1) As undo log is being created in tablespace, if the tablespace is dropped later, will it have any impact? +void +UndoLogDirectory(Oid tablespace, char *dir) +{ + if (tablespace ==

Re: POC: Cleaning up orphaned files using undo logs

On Thu, Jul 25, 2019 at 7:48 AM Amit Kapila wrote: > > On Wed, Jul 24, 2019 at 11:04 PM vignesh C wrote: > > > > Hi, > > > > I have done some review of undolog patch series > > and here are my comments: > > 0003-Add-undo-log-manager.patch > > &

Initdb failure

Hi, Initdb fails when following path is provided as input:

Re: POC: Cleaning up orphaned files using undo logs

re out how far we + * have to move insert to create space for 'size' usable bytes, stepping + * over any intervening headers. + */ + Assert(slot->meta.unlogged.insert % BLCKSZ >= UndoLogBlockHeaderSize); + if (context->try_location != InvalidUndoRecPtr) Regards, Vignesh EnterpriseDB: http://www.ente

Re: Initdb failure

On Thu, Jul 25, 2019 at 4:52 PM Rafia Sabih wrote: > > On Thu, 25 Jul 2019 at 07:39, vignesh C wrote: > > > > Hi, > > > > Initdb fails when follo

Re: block-level incremental backup

On Fri, Jul 26, 2019 at 11:21 AM Jeevan Ladhe wrote: > Hi Vignesh, > > Please find my comments inline below: > > 1) If relation file has changed due to truncate or vacuum. >> During incremental backup the new files will be copied. >> There are chances that both the old file and new file

Re: Initdb failure

On Thu, Jul 25, 2019 at 8:39 PM Rafia Sabih wrote: > > On Thu, 25 Jul 2019 at 16:44, Tom Lane wrote: > > > > Rafia Sabih writes: > > > On Thu, 25 Jul 2019 at 13:50, vignesh C wrote: > > >>> Initdb fail

Warning messages appearing twice

Hi, I have noticed in some cases the warning messages appear twice, one such instance is given below: postgres=# begin; BEGIN postgres=# prepare transaction 't1'; PREPARE TRANSACTION postgres=# rollback; *WARNING: there is no transaction in progressWARNING: there is no transaction in progress*

Re: Warning messages appearing twice

On Fri, Jul 26, 2019 at 11:23 AM Dilip Kumar wrote: > On Fri, Jul 26, 2019 at 11:04 AM vignesh C wrote: > > > > Hi, > > > > I have noticed in some cases the warning messages appear twice, one such > instance is given below: > > postgres=# begin; > > BE

Re: dropdb --force

On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule wrote: > > Hi > > I am sending updated version - the changes against last patch are two. I use > pg_terminate_backed for killing other terminates like Tom proposed. I am not > sure if it is 100% practical - on second hand the necessary right to

Re: dropdb --force

On Thu, Sep 19, 2019 at 11:41 PM Pavel Stehule wrote: > > > > čt 19. 9. 2019 v 13:52 odesílatel vignesh C napsal: >> >> On Thu, Sep 19, 2019 at 12:14 AM Pavel Stehule >> wrote: >> > >> > Hi >> > >> > I am sending upd

Re: psql - add SHOW_ALL_RESULTS option

On Fri, Sep 13, 2019 at 1:01 AM Alvaro Herrera wrote: > > This v6 is just Fabien's v5, rebased over a very minor conflict, and > pgindented. No further changes. I've marked this Ready for Committer. > Should we add function header for the below function to maintain the common standard of this

Re: dropdb --force

On Tue, Sep 24, 2019 at 6:22 PM Amit Kapila wrote: > > On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule > wrote: > > > > Thank you for check. I am sending updated patch > > > Session termination in case of drop database is solved. Some typos: + /* + * Similar code to pg_terminate_backend, but we

Ordering of header file inclusion

Hi, I noticed that some of the header files inclusion is not ordered as per the usual standard that is followed. The attached patch contains the fix for the order in which the header files are included. Let me know your thoughts on the same. Regards, Vignesh EnterpriseDB:

Re: psql - add SHOW_ALL_RESULTS option

On Fri, Sep 20, 2019 at 1:41 PM Fabien COELHO wrote: > > > > Should we add function header for the below function to maintain the > > common standard of this file: > > Yes. Attached v6 does that. > Thanks for fixing it. The below addition can be removed, it seems to be duplicate: @@ -3734,6

Re: dropdb --force

On Thu, Oct 3, 2019 at 11:18 PM vignesh C wrote: > > On Wed, Oct 2, 2019 at 10:21 PM Pavel Stehule wrote: > > > > Thank you for careful review. I hope so all issues are out. > > > > > Thanks Pavel for fixing the comments. > Few comments: > The else part

Re: Remove unused function argument

On Tue, Oct 29, 2019 at 2:51 PM Peter Eisentraut wrote: > > The cache_plan argument to ri_PlanCheck has not been used since > e8c9fd5fdf768323911f7088e8287f63b513c3c6. I propose to remove it. > > That commit said "I left it alone in case there is any future need for > it" but there hasn't been a

Re: Reorderbuffer crash during recovery

On Sat, Nov 9, 2019 at 5:07 PM Amit Kapila wrote: > > On Fri, Nov 8, 2019 at 10:05 AM vignesh C wrote: > > > > On Thu, Nov 7, 2019 at 10:01 PM Andres Freund wrote: > > > > > > Hi, > > > > > > On 2019-11-07 17:03:44 +0530, Amit Kapila wrot

Reorderbuffer crash during recovery

Hi, I found couple of crashes in reorderbuffer while review/testing of logical_work_mem and logical streaming of large in-progress transactions. Stack trace of the same are given below: Issue 1: #0 0x7f985c7d8337 in raise () from /lib64/libc.so.6 #1 0x7f985c7d9a28 in abort () from

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

On Mon, Nov 4, 2019 at 5:22 PM Amit Kapila wrote: > > On Wed, Oct 30, 2019 at 9:38 AM vignesh C wrote: > > > > On Tue, Oct 22, 2019 at 10:52 PM Tomas Vondra > > wrote: > > > > > > I think the patch should do the simplest thing possible, i.e. what it &

Re: Reorderbuffer crash during recovery

On Thu, Nov 7, 2019 at 10:01 PM Andres Freund wrote: > > Hi, > > On 2019-11-07 17:03:44 +0530, Amit Kapila wrote: > > On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra > > wrote: > > > > > > I'm a bit confused - does this happen only with the logical_work_mem > > > patches, or with clean master too? >

Re: dropdb --force

On Sat, Nov 16, 2019 at 1:25 PM Pavel Stehule wrote: >> > >> > updated patch attached >> > >> >> Thanks Pavel for providing updated version. >> Few comments: >> I felt the help text seems incomplete: >> @@ -159,6 +167,7 @@ help(const char *progname) >> printf(_("\nOptions:\n")); >>

Re: dropdb --force

On Fri, Nov 15, 2019 at 1:23 PM Pavel Stehule wrote: > > updated patch attached > Thanks Pavel for providing updated version. Few comments: I felt the help text seems incomplete: @@ -159,6 +167,7 @@ help(const char *progname) printf(_("\nOptions:\n")); printf(_(" -e, --echo

Re: Ordering of header file inclusion

On Tue, Nov 12, 2019 at 11:19 AM Amit Kapila wrote: > > On Tue, Nov 12, 2019 at 6:33 AM vignesh C wrote: > > > > > > Thanks Amit for your comments. Please find the updated patch which > > does not include the changes mentioned above. > > > > Thanks for w

Copyright information in source files

Hi, I noticed that some of the source files does not include the copyright information. Most of the files have included it, but few files have not included it. I felt it should be included. The attached patch contains the fix for including the copyright information in the source files. Let me

Re: Reorderbuffer crash during recovery

On Wed, Nov 6, 2019 at 5:41 PM Dilip Kumar wrote: > > On Wed, Nov 6, 2019 at 5:20 PM vignesh C wrote: > > > > Hi, > > > > I found couple of crashes in reorderbuffer while review/testing of > > logical_work_mem and logical streaming of large in-progress >

Re: dropdb --force

On Mon, Nov 18, 2019 at 6:30 PM Pavel Stehule wrote: >> >> I'll send this test today > > > here is it > Thanks for adding the test. Few comments: This function is same as in test/recovery/t/013_crash_restart.pl, we can add to a common file and use in both places: +# Pump until string is matched,

Re: Copyright information in source files

On Fri, Nov 22, 2019 at 2:12 AM Tom Lane wrote: > > Thomas Munro writes: > > I'd like to get rid of those IDENTIFICATION lines completely (they are > > left over from the time when the project used CVS, and that section > > had a $Header$ "ident" tag, but in the git era, those ident tags are > >

Re: Ordering of header file inclusion

On Thu, Nov 21, 2019 at 2:11 PM Amit Kapila wrote: > > On Sat, Nov 16, 2019 at 7:01 AM vignesh C wrote: > > > > On Tue, Nov 12, 2019 at 11:19 AM Amit Kapila > > wrote: > > > > > > On Tue, Nov 12, 2019 at 6:33 AM vignesh C wrote: > > > >

Re: segmentation fault when cassert enabled

On Fri, Dec 6, 2019 at 5:30 PM Amit Kapila wrote: > > On Mon, Nov 25, 2019 at 8:25 PM Jehan-Guillaume de Rorthais > wrote: > > > > On Wed, 6 Nov 2019 14:34:38 +0100 > > Peter Eisentraut wrote: > > > > > On 2019-11-05 17:29, Jehan-Guillaume de Rorthais wrote: > > > > My best bet so far is that

Re: Reorderbuffer crash during recovery

> I found couple of crashes in reorderbuffer while review/testing of > logical_work_mem and logical streaming of large in-progress > transactions. Stack trace of the same are given below: > Issue 1: > #0 0x7f985c7d8337 in raise () from /lib64/libc.so.6 > #1 0x7f985c7d9a28 in abort ()

Re: segmentation fault when cassert enabled

http://www.enterprisedb.com From 2c4123d514473a9203c3617655229286a84487e6 Mon Sep 17 00:00:00 2001 From: vignesh Date: Tue, 17 Dec 2019 17:05:35 +0530 Subject: [PATCH] Fix subscriber invalid memory access on DDL. This patch allows building the local relmap cache for a subscribed relation after pro

closesocket behavior in different platforms

Hi, In few scenarios the message displayed in psql console is not consistent in windows and linux. The execution results from few scenarios in windows and linux is listed below: In CentOS *After transaction idle timeout*postgres=# SET

Re: Ordering of header file inclusion

On Sun, Oct 20, 2019 at 2:44 AM Andres Freund wrote: > > Hi, > > On 2019-10-19 21:50:03 +0200, Peter Eisentraut wrote: > > diff --git a/contrib/bloom/blcost.c b/contrib/bloom/blcost.c > > index f9fe57f..6224735 100644 > > --- a/contrib/bloom/blcost.c > > +++ b/contrib/bloom/blcost.c > > @@ -12,10

Re: Ordering of header file inclusion

On Sun, Oct 20, 2019 at 1:20 AM Peter Eisentraut wrote: > > diff --git a/contrib/bloom/blcost.c b/contrib/bloom/blcost.c > index f9fe57f..6224735 100644 > --- a/contrib/bloom/blcost.c > +++ b/contrib/bloom/blcost.c > @@ -12,10 +12,10 @@ > */ > #include "postgres.h" > > +#include "bloom.h" >

Typos and inconsistencies in code

Hi, Please find the attached patch having the fix for the typos and inconsistencies present in code. The patch contains the following changes: 1) attibute -> attribute 2) efficent -> efficient 3) becuase -> because 4) fallthru -> fall through 5) uncoming -> upcoming 6) ans -> and 7) requrested ->

Re: Ordering of header file inclusion

On Wed, Oct 16, 2019 at 8:10 AM Amit Kapila wrote: > > Thanks for working on this. I will look into this in the coming few > days or during next CF. Can you please register it for the next CF > (https://commitfest.postgresql.org/25/)? > Thanks, I have added it to the commitfest. Regards,

Re: Typos and inconsistencies in code

On Tue, Oct 29, 2019 at 9:19 AM Dilip Kumar wrote: > > Few comments: > 1. > * The act of allocating pages to recycle may have invalidated the > - * results of our previous btree reserch, so repeat it. (We could > + * results of our previous btree search, so repeat it. (We could > * recheck

Re: Ordering of header file inclusion

On Tue, Oct 22, 2019 at 12:56 PM Amit Kapila wrote: > Few comments on 0001-Ordering-of-header-files-in-contrib-dir-oct21.patch > --- > 1. > --- a/contrib/isn/isn.c > +++ b/contrib/isn/isn.c >

Re: Proposal: Make use of C99 designated initialisers for nulls/values arrays

On Tue, Oct 8, 2019 at 4:43 AM Smith, Peter wrote: > > From: Amit Kapila Sent: Friday, 4 October 2019 4:50 > PM > > >>How about I just define them both the same? > >>#define INIT_ALL_ELEMS_ZERO {0} > >>#define INIT_ALL_ELEMS_FALSE{0} > > > >I think using one define would be preferred,

Cleanup - Removal of apply_typmod function in #if 0

Hi, One of the function apply_typmod in numeric.c file present within #if 0. This is like this for many years. I felt this can be removed. Attached patch contains the changes to handle removal of apply_typmod present in #if 0. Thoughts? Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com

Re: Ordering of header file inclusion

On Tue, Oct 22, 2019 at 3:42 PM Amit Kapila wrote: > Review for 0003-Ordering-of-header-files-remaining-dir-oct21 > - > 1. > --- a/src/bin/pg_basebackup/pg_recvlogical.c > +++

Re: Ordering of header file inclusion

On Tue, Oct 22, 2019 at 11:05 PM vignesh C wrote: > > On Tue, Oct 22, 2019 at 3:42 PM Amit Kapila wrote: > > Review for 0003-Ordering-of-header-files-remaining-dir-oct21 > > - > &

initdb SegFault

Hi, While checking initdb code, I found one segmentation fault, stack trace for the same is: Core was generated by `./initdb -D data6'. Program terminated with signal 11, Segmentation fault. #0 0x0040ea22 in main (argc=3, argv=0x7ffc82237308) at initdb.c:3340 3340

Re: Copyright information in source files

On Sun, Nov 24, 2019 at 8:44 PM Tom Lane wrote: > > John Naylor writes: > > On Sat, Nov 23, 2019 at 11:39 PM vignesh C wrote: > >> * Copyright (c) 2016-2019, PostgreSQL Global Development Group > > > While we're talking about copyrights, I noticed while

Re: dropdb --force

On Tue, Nov 26, 2019 at 11:37 AM Amit Kapila wrote: > > On Mon, Nov 25, 2019 at 11:22 PM vignesh C wrote: > > > > On Sun, Nov 24, 2019 at 5:06 PM Pavel Stehule > > wrote: > > > > > > > > > > > > ne 24. 11. 2019 v 11:25 odesílatel vign

Re: dropdb --force

On Sun, Nov 24, 2019 at 5:06 PM Pavel Stehule wrote: > > > > ne 24. 11. 2019 v 11:25 odesílatel vignesh C napsal: >> >> On Sat, Nov 23, 2019 at 4:42 PM Amit Kapila wrote: >> > >> > On Fri, Nov 22, 2019 at 3:16 PM vignesh C wrote: >> > > &g

Re: dropdb --force

On Sat, Nov 23, 2019 at 4:42 PM Amit Kapila wrote: > > On Fri, Nov 22, 2019 at 3:16 PM vignesh C wrote: > > > > Thanks for fixing the comments. The changes looks fine to me. I have > > fixed the first comment, attached patch has the changes for the sa

Re: Copyright information in source files

On Sun, Nov 24, 2019 at 7:24 AM John Naylor wrote: > > On Sat, Nov 23, 2019 at 11:39 PM vignesh C wrote: > > > * Copyright (c) 2016-2019, PostgreSQL Global Development Group > > While we're talking about copyrights, I noticed while researching > something else that the

Re: dropdb --force

On Thu, Nov 28, 2019 at 8:54 AM Amit Kapila wrote: > > On Wed, Nov 27, 2019 at 10:15 AM vignesh C wrote: > > > > > > Attached patch has the fixes for the above comments. > > > > I have pushed the refactoring patch. In the second patch, I have a > few m

Re: dropdb --force

On Fri, Nov 29, 2019 at 1:36 PM Juan José Santamaría Flecha wrote: > > > > On Fri, Nov 29, 2019 at 7:30 AM Michael Paquier wrote: >> >> On Thu, Nov 28, 2019 at 08:53:56AM +0530, Amit Kapila wrote: >> > I have pushed the refactoring patch. In the second patch, I have a >> > few more comments. I

Re: Typos and inconsistencies in code

On Wed, Oct 30, 2019 at 6:35 AM Michael Paquier wrote: > > On Tue, Oct 29, 2019 at 05:27:20PM +0530, vignesh C wrote: > > I have attached the updated patch with the fixes. > > The changes in rangetypes_gist.c are not correct, the usual pattern to > add an "s" af

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

On Tue, Oct 22, 2019 at 10:52 PM Tomas Vondra wrote: > > I think the patch should do the simplest thing possible, i.e. what it > does today. Otherwise we'll never get it committed. > I found a couple of crashes while reviewing and testing flushing of open transaction data: Issue 1: #0

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

On Thu, Oct 24, 2019 at 7:07 PM Amit Kapila wrote: > > On Tue, Oct 22, 2019 at 10:30 AM Dilip Kumar wrote: > > > > I have merged bugs_and_review_comments_fix.patch changes to 0001 and 0002. > > > > I was wondering whether we have checked the code coverage after this > patch? Previously, the

Re: dropdb --force

On Fri, Nov 22, 2019 at 12:10 AM Pavel Stehule wrote: > > > > čt 21. 11. 2019 v 6:33 odesílatel vignesh C napsal: >> >> On Mon, Nov 18, 2019 at 6:30 PM Pavel Stehule >> wrote: >> >> >> >> I'll send this test today >> > >> >

Re: dropdb --force

On Wed, Nov 13, 2019 at 8:05 PM Pavel Stehule wrote: > > > > st 13. 11. 2019 v 7:13 odesílatel Pavel Stehule > napsal: >> >> >> >> st 13. 11. 2019 v 7:12 odesílatel Amit Kapila >> napsal: >>> >>> On Tue, Nov 12, 2019 at 11:17 AM Amit Kapila >>> wrote: >>> > >>> > I am planning to commit

Re: dropdb --force

On Sat, Sep 21, 2019 at 10:09 PM Pavel Stehule wrote: > fixed > > Thank you for check. I am sending updated patch > Thanks for fixing all the comments. Couple of suggestions: -DROP DATABASE [ IF EXISTS ] name +DROP DATABASE [ ( option [, ...] ) ] [ IF EXISTS ] name + +where option can be one of:

Re: Updated some links which are not working with new links

On Sat, Oct 5, 2019 at 7:13 AM vignesh C wrote: > > Hi, > > There are some links referred in the source files which are currently > not working. > > The below link: > <http://www.UNIX-systems.org/online.html> > is updated with: > <http://www.unix.org/online.

Non-Active links being referred in our source code

Hi, There are few links present in our source files for which the web links are no more active. Details for the same is given below: Sl No Link Referred File 1 http://h21007.www2.hp.com/portal/download/files/unprot/Itanium/inline_assem_ERS.pdf

Re: dropdb --force

On Wed, Oct 2, 2019 at 10:21 PM Pavel Stehule wrote: > > Thank you for careful review. I hope so all issues are out. > > Thanks Pavel for fixing the comments. Few comments: The else part cannot be hit in DropDatabase function as gram.y expects FORCE. + + if (strcmp(opt->defname, "force") == 0) +

Re: dropdb --force

On Fri, Oct 4, 2019 at 9:54 PM Pavel Stehule wrote: > > > > čt 3. 10. 2019 v 19:48 odesílatel vignesh C napsal: >> >> On Wed, Oct 2, 2019 at 10:21 PM Pavel Stehule >> wrote: >> > >> > Thank you for careful review. I hope so all issues are out. &

Re: Updated some links which are not working with new links

On Mon, Oct 7, 2019 at 1:18 PM Michael Paquier wrote: > > Hi Vignesh, > > On Mon, Oct 07, 2019 at 09:38:41AM +0530, vignesh C wrote: > > The attached patch in previous mail contain the changes for the updated > > links requested in [1]. It is not the complete set,

Re: Updated some links which are not working with new links

On Tue, Oct 8, 2019 at 11:06 AM Michael Paquier wrote: > > On Mon, Oct 07, 2019 at 02:14:05PM +0530, vignesh C wrote: > > Sorry Michael for the miscommunication, the patch was present in the > > first mail of this mail thread. > > I'm re-attaching the patch in th

Updated some links which are not working with new links

Hi, There are some links referred in the source files which are currently not working. The below link: is updated with: The below links:

Re: [HACKERS] Block level parallel vacuum

On Fri, Oct 4, 2019 at 4:18 PM Amit Kapila wrote: > > On Wed, Oct 2, 2019 at 7:29 PM Masahiko Sawada wrote: >> >> On Sat, Sep 21, 2019 at 9:31 PM Amit Kapila wrote: >> > One comment: We can check if parallel_workers is within range something within MAX_PARALLEL_WORKER_LIMIT. + int

Re: Non-Active links being referred in our source code

On Tue, Oct 8, 2019 at 10:35 AM Michael Paquier wrote: > > On Mon, Oct 07, 2019 at 05:11:40PM +0200, Juan José Santamaría Flecha wrote: > > About the broken links in win32_port.h, they are all referring to > > ntstatus. As for first case that shows the code groups, there is an up > > to date

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

On Mon, Dec 2, 2019 at 2:02 PM Dilip Kumar wrote: > > On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier wrote: > > > > On Fri, Nov 22, 2019 at 01:18:11PM +0530, Dilip Kumar wrote: > > > I have rebased the patch on the latest head and also fix the issue of > > > "concurrent abort handling of the

  1   2   3   4   5   6   7   8   9   10   >