Re: format of pg_upgrade loadable_libraries warning

Bruce Momjian writes: > On Fri, Oct 4, 2019 at 05:40:08PM -0500, Justin Pryzby wrote: >> I would argue to include in 12.1, since 12 is what most everyone will use for >> upgrades, and patch for .1 will help people upgrading for 11 of the next 12 >> months. (But, your patch is more general than

Re: Change atoi to strtol in same place

Hi Joe, On a quick look, the patch seems to be going in a good direction although there are quite some pending work to be done. One suggestion: The start value for port number is set to 1, however it seems like the port number that falls in the range of 1-1023 is reserved and can't be used. So,

Re: refactoring - share str2*int64 functions

On Fri, Oct 4, 2019 at 8:58 PM Andres Freund wrote: > > Hi, > > On 2019-10-04 14:27:44 +0530, Ashutosh Sharma wrote: > > Is there any specific reason for hard coding the *base* of a number > > representing the string in strtouint64(). I understand that currently > > strtouint64() is being used

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: format of pg_upgrade loadable_libraries warning

On Fri, Oct 4, 2019 at 05:40:08PM -0500, Justin Pryzby wrote: > On Fri, Oct 04, 2019 at 05:37:46PM -0400, Bruce Momjian wrote: > > On Wed, Oct 2, 2019 at 12:23:37PM -0500, Justin Pryzby wrote: > > > Regarding the previous thread and commit here: > > >

Re: Transparent Data Encryption (TDE) and encrypted files

On Sat, Oct 5, 2019 at 12:54:35AM +0200, Tomas Vondra wrote: > On Fri, Oct 04, 2019 at 06:06:10PM -0400, Bruce Momjian wrote: > > For full-cluster TDE with AES-NI-enabled, the performance impact is > > usually ~4%, so doing anything more granular doesn't seem useful. See > > this PGCon

Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 04, 2019 at 06:06:10PM -0400, Bruce Momjian wrote: On Fri, Oct 4, 2019 at 11:48:19PM +0200, Tomas Vondra wrote: On Fri, Oct 04, 2019 at 04:58:14PM -0400, Bruce Momjian wrote: > On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote: > > Oracle also has a handy "TDE best

Re: format of pg_upgrade loadable_libraries warning

On Fri, Oct 04, 2019 at 05:37:46PM -0400, Bruce Momjian wrote: > On Wed, Oct 2, 2019 at 12:23:37PM -0500, Justin Pryzby wrote: > > Regarding the previous thread and commit here: > > https://www.postgresql.org/message-id/flat/20180713162815.GA3835%40momjian.us > >

Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 4, 2019 at 11:48:19PM +0200, Tomas Vondra wrote: > On Fri, Oct 04, 2019 at 04:58:14PM -0400, Bruce Momjian wrote: > > On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote: > > > Oracle also has a handy "TDE best practices" document [2], which says > > > when to use

Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 4, 2019 at 11:31:00PM +0200, Tomas Vondra wrote: > On Fri, Oct 04, 2019 at 03:57:32PM -0400, Bruce Momjian wrote: > > The current approach is to encrypt anything that contains user data, > > which includes heap, index, and WAL files. I think replication slots > > and logical

Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 04, 2019 at 04:58:14PM -0400, Bruce Momjian wrote: On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote: Oracle also has a handy "TDE best practices" document [2], which says when to use column-level encryption - let me quote a couple of points: * Location of sensitive

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

Hi, On 2019-10-04 17:08:29 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote: > >> Yeah, it is certainly weird that you have to assign the first array > >> element to get the rest to be zeros. By using a macro, we can document > >> this

Re: format of pg_upgrade loadable_libraries warning

On Wed, Oct 2, 2019 at 12:23:37PM -0500, Justin Pryzby wrote: > Regarding the previous thread and commit here: > https://www.postgresql.org/message-id/flat/20180713162815.GA3835%40momjian.us >

Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 04, 2019 at 03:57:32PM -0400, Bruce Momjian wrote: On Fri, Oct 4, 2019 at 09:18:58AM -0400, Robert Haas wrote: I think everyone would agree that if you have no information about a database other than the contents of pg_clog, that's not a meaningful information leak. You would be

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

Andres Freund writes: > On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote: >> Yeah, it is certainly weird that you have to assign the first array >> element to get the rest to be zeros. By using a macro, we can document >> this behavior in one place. > IDK, to me this seems like something one

Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote: > Oracle also has a handy "TDE best practices" document [2], which says > when to use column-level encryption - let me quote a couple of points: > > * Location of sensitive information is known > > * Less than 5% of all application

Re: Transparent Data Encryption (TDE) and encrypted files

On Thu, Oct 03, 2019 at 01:26:55PM -0400, Stephen Frost wrote: Greetings, * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: On Thu, Oct 03, 2019 at 11:51:41AM -0400, Stephen Frost wrote: >* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: >>On Thu, Oct 03, 2019 at 10:40:40AM -0400,

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

Hi, On 2019-10-04 16:31:29 -0400, Bruce Momjian wrote: > On Fri, Oct 4, 2019 at 02:05:41PM -0400, Chapman Flack wrote: > > On 10/4/19 1:44 PM, Ashwin Agrawal wrote: > > > > > macro exist in first place will be hard to remember. So, irrespective > > > in long run, {0} might get used in code and

Re: Tighten error control for OpenTransientFile/CloseTransientFile

Hi, On 2019-03-07 10:56:25 +0900, Michael Paquier wrote: > diff --git a/src/backend/access/heap/rewriteheap.c > b/src/backend/access/heap/rewriteheap.c > index f5cf9ffc9c..bce4274362 100644 > --- a/src/backend/access/heap/rewriteheap.c > +++ b/src/backend/access/heap/rewriteheap.c > @@ -1202,7

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

On Fri, Oct 4, 2019 at 02:05:41PM -0400, Chapman Flack wrote: > On 10/4/19 1:44 PM, Ashwin Agrawal wrote: > > > macro exist in first place will be hard to remember. So, irrespective > > in long run, {0} might get used in code and hence seems better > > to just use {0} from start itself instead

Re: Memory Accounting

On Tue, Sep 24, 2019 at 2:47 PM Melanie Plageman wrote: > I think it would be helpful if we could repeat the performance tests > Robert did on that machine with the current patch (unless this version > of the patch is exactly the same as the ones he tested previously). I still have access to a

Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 04, 2019 at 07:52:48AM +0200, Magnus Hagander wrote: On Fri, Oct 4, 2019 at 3:42 AM Stephen Frost wrote: > It doesn't seem like it would require > much work at all to construct an argument that a hacker might enjoy > having unfettered access to pg_clog even if no other part of

Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 4, 2019 at 09:18:58AM -0400, Robert Haas wrote: > I think everyone would agree that if you have no information about a > database other than the contents of pg_clog, that's not a meaningful > information leak. You would be able to tell which transactions > committed and which

Re: Problem with repalloc downsizing patch

I wrote: > I'm also wondering a bit whether there's anyplace *else* that is > cheating by assuming that a downsizing repalloc doesn't move the block. > We could investigate that by testing with a modified form of > AllocSetRealloc that always moves the block, but of course that won't > find bugs

Re: Memory Accounting

Peter Geoghegan writes: > On Fri, Oct 4, 2019 at 7:32 AM Jeff Davis wrote: >> The patch has been floating around for a very long time, so I don't >> remember exactly why I chose a signed value. Sorry. > I am reminded of the fact that int64 is used to size buffers within > tuplesort.c, because

Re: Memory Accounting

On Fri, Oct 4, 2019 at 7:32 AM Jeff Davis wrote: > The patch has been floating around for a very long time, so I don't > remember exactly why I chose a signed value. Sorry. I am reminded of the fact that int64 is used to size buffers within tuplesort.c, because it needs to support negative

Re: Memory Accounting

I wrote: > Just to make things even more mysterious, prairiedog finally showed > the Assert failure on its fourth run with c477f3e449 included: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog=2019-10-04%2012%3A35%3A41 > It's also now apparent that lapwing and locust were

Re: tableam vs. TOAST

On Fri, Sep 6, 2019 at 10:59 AM Robert Haas wrote: > On Thu, Sep 5, 2019 at 4:07 PM Andres Freund wrote: > > Yea, makes sense to me. > > OK, done. Here's the remaining patches again, with a slight update to > the renaming patch (now 0002). In the last version, I renamed >

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

On 10/4/19 1:44 PM, Ashwin Agrawal wrote: > macro exist in first place will be hard to remember. So, irrespective > in long run, {0} might get used in code and hence seems better > to just use {0} from start itself instead of macro/wrapper on top. > > Plus, even if someone starts out with

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

On Fri, Oct 4, 2019 at 8:49 AM Tom Lane wrote: > Jacob Champion writes: > > On Fri, Oct 4, 2019 at 7:51 AM Tom Lane wrote: > >> I concur with Joe here. The reason why some of the existing > >> memset's use "false" is for symmetry with other places where we use > >> "memset(p, true, n)" to set

Problem with repalloc downsizing patch

skink just found what seems like a serious problem with commit c477f3e44: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2019-10-04%2010%3A15%3A05 performing post-bootstrap initialization ... TRAP: FailedAssertion("newlist == list", File:

Re: dropdb --force

č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. > > > > > Thanks Pavel for fixing the comments. > Few comments: > The else part cannot be hit in DropDatabase function

Re: How to retain lesser paths at add_path()?

On Mon, Aug 12, 2019 at 12:28 AM Kohei KaiGai wrote: > For implementation of the concept, this patch puts a hook on add_path > / add_partial_path > to override the path removal decision by extensions, according to its > own viewpoint. I don't think this hook is a very useful approach to this

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

Jacob Champion writes: > On Fri, Oct 4, 2019 at 7:51 AM Tom Lane wrote: >> I concur with Joe here. The reason why some of the existing >> memset's use "false" is for symmetry with other places where we use >> "memset(p, true, n)" to set an array of bools to all-true. > Why introduce a macro at

Re: Memory Accounting

Tomas Vondra writes: > On Fri, Oct 04, 2019 at 12:36:01AM -0400, Tom Lane wrote: >> What I think is happening is that c477f3e449 allowed this bit in >> AllocSetRealloc: >> context->mem_allocated += blksize - oldblksize; >> to be executed in situations where blksize < oldblksize, where before >>

Re: Change atoi to strtol in same place

On 2019-Oct-03, Joe Nelson wrote: > Kyotaro Horiguchi wrote: > > > pg_standby: -k keepfiles could not parse 'hoge' as integer > > > > I didn't checked closely, but -k of pg_standby's message looks > > somewhat strange. Needs a separator? > > Good point, how about this: > > pg_standby: -k

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

On Fri, Oct 4, 2019 at 7:51 AM Tom Lane wrote: > I concur with Joe here. The reason why some of the existing > memset's use "false" is for symmetry with other places where we use > "memset(p, true, n)" to set an array of bools to all-true. That > coding is unfortunately a bit dubious --- it

Re: refactoring - share str2*int64 functions

Hi, On 2019-10-04 14:27:44 +0530, Ashutosh Sharma wrote: > Is there any specific reason for hard coding the *base* of a number > representing the string in strtouint64(). I understand that currently > strtouint64() is being used just to convert an input string to decimal > unsigned value but what

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

Joe Nelson writes: > One might argue that INIT_ALL_ELEMS_FALSE as a synonym for > INIT_ALL_ELEMS_ZERO is good for readability in the same way that "false" > is for 0. However I want to avoid creating the impression that there is, > or can be, a collection of INIT_ALL_ELEMS_xxx macros invoking

Re: Memory Accounting

Jeff Davis writes: > On Fri, 2019-10-04 at 10:26 +0200, Tomas Vondra wrote: >> Yeah, I think that's an oversight. Maybe there's a reason why Jeff >> used int64, but I can't think of any. > I had chosen a 64-bit value to account for the situation Tom mentioned: > that, in theory, Size might not

Remove some code for old unsupported versions of MSVC

As of d9dd406fe281d22d5238d3c26a7182543c711e74, we require MSVC 2013, which means _MSC_VER >= 1800. This means that conditionals about older versions of _MSC_VER can be removed or simplified. Previous code was also in some cases handling MinGW, where _MSC_VER is not defined at all, incorrectly,

Re: Memory Accounting

On Fri, 2019-10-04 at 10:26 +0200, Tomas Vondra wrote: > On Fri, Oct 04, 2019 at 12:36:01AM -0400, Tom Lane wrote: > > So ... why exactly did this patch define > > MemoryContextData.mem_allocated > > as int64? That seems to me to be doubly wrong: it is not the right > > width > > on 32-bit

Re: Memory Accounting

On Fri, Oct 04, 2019 at 10:26:44AM +0200, Tomas Vondra wrote: On Fri, Oct 04, 2019 at 12:36:01AM -0400, Tom Lane wrote: I haven't chased down exactly what else would need to change. It might be that s/int64/Size/g throughout the patch is sufficient, but I haven't analyzed it. I think so too,

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

Amit Kapila wrote: > > 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, but you can wait and see > if others prefer defining different macros for the same thing. +1 on using

Re: [HACKERS] Block level parallel vacuum

On Fri, Oct 4, 2019 at 2:31 PM Amit Kapila wrote: > > On Fri, Oct 4, 2019 at 10:28 AM Masahiko Sawada wrote: >> >> On Thu, Oct 3, 2019 at 9:06 PM Dilip Kumar wrote: >> > >> > On Wed, Oct 2, 2019 at 7:29 PM Masahiko Sawada >> > wrote: >> > >> > + else >> > + { >> > + if (for_cleanup) >> > + {

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

On 04.10.2019 11:37, Michael Paquier wrote: On Thu, Oct 03, 2019 at 12:43:37PM +0300, Alexey Kondratov wrote: On 03.10.2019 6:07, Michael Paquier wrote: I have reworked your first patch as per the attached. What do you think about it? The part with the control file needs to go down to v12,

Re: [HACKERS] Block level parallel vacuum

On Fri, Oct 4, 2019 at 2:02 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: >> > * >> > In function compute_parallel_workers, don't we want to cap the number >> > of workers based on maintenance_work_mem as

Re: Close stdout and stderr in syslogger

On Thu, Oct 3, 2019 at 8:30 AM Святослав Ермилин wrote: > There is another way to solve this problem: > We can give users the opportunity to leave or close descriptors. > I.e. config switch for this. But I think that it's too complicated. The typical solution to this problem is to send the

Re: Transparent Data Encryption (TDE) and encrypted files

On Thu, Oct 3, 2019 at 9:42 PM Stephen Frost wrote: > > It doesn't seem like it would require > > much work at all to construct an argument that a hacker might enjoy > > having unfettered access to pg_clog even if no other part of the > > database can be read. > > The question isn't about what

Re: fairywren failures

On 10/3/19 4:13 PM, Tom Lane wrote: > Andres Freund writes: >> * It's certainly curious that the failures so far only have happended as >> part of pg_upgradeCheck, rather than the plain regression tests. > Isn't it though. We spent a long time wondering why we saw parallel > plan instability

Re: HashTable KeySize

On Fri, Oct 04, 2019 at 05:06:47PM +0530, Natarajan R wrote: typedef struct HashTableKey { Oid dbId; // 4 bytes int64 productid; // 8 bytes }HashTableKey; (total size - 12 bytes) typedef struct HashTableEntry { HashTableKey key; ProductInfo *pdt; }HashTableEntry; HASHCTL hashInfo;

Re: Consider low startup cost in add_partial_path

On Wed, Oct 2, 2019 at 10:22 AM James Coleman wrote: > In all cases I've been starting with: > > set enable_hashjoin = off; > set enable_nestloop = off; > set max_parallel_workers_per_gather = 4; > set min_parallel_index_scan_size = 0; > set min_parallel_table_scan_size = 0; > set

Re: max_parallel_workers question

On Sat, Sep 28, 2019 at 1:36 PM Jeff Davis wrote: > In that case, PGC_SIGHUP seems most appropriate. Yeah. > It also might make more sense to rename it to reserved_worker_processes > and invert the meaning. To me, that would be more clear that it's > designed to prevent parallel query from

Re: let's kill AtSubStart_Notify

On Fri, Sep 27, 2019 at 5:41 AM Jeevan Ladhe wrote: > I have reviewed your patch, and it seems correctly implementing the > actions per subtransactions using stack. Atleast I could not find > any flaw with your implementation here. Thanks for the review. Based on this and other positive

Re: WIP/PoC for parallel backup

On Fri, Oct 4, 2019 at 7:02 AM Asif Rehman wrote: > Based on my understanding your main concern is that the files won't be > distributed fairly i.e one worker might get a big file and take more time > while others get done early with smaller files? In this approach I have > created a list of

Re: recovery_min_apply_delay in archive recovery causes assertion failure in latch

On Mon, Sep 30, 2019 at 12:49 AM Fujii Masao wrote: > > Hi, > > I got the following assertion failure when I enabled recovery_min_apply_delay > and started archive recovery (i.e., I put only recovery.signal not > standby.signal). > > TRAP: FailedAssertion("latch->owner_pid == MyProcPid", File: >

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: pg_upgrade fails with non-standard ACL

27.09.2019 15:51, Bruce Momjian wrote: On Fri, Sep 27, 2019 at 04:22:15PM +0900, Michael Paquier wrote: On Thu, Sep 26, 2019 at 04:19:38PM -0400, Bruce Momjian wrote: On Thu, Sep 26, 2019 at 05:16:19PM -0300, Alvaro Herrera wrote: On 2019-Sep-26, Bruce Momjian wrote: Well, right now,

HashTable KeySize

typedef struct HashTableKey { Oid dbId; // 4 bytes int64 productid; // 8 bytes }HashTableKey; (total size - 12 bytes) typedef struct HashTableEntry { HashTableKey key; ProductInfo *pdt; }HashTableEntry; HASHCTL hashInfo; hashInfo.keysize = sizeof(HashTableKey); hashInfo.entrysize =

Re: WIP/PoC for parallel backup

On Thu, Oct 3, 2019 at 6:40 PM Robert Haas wrote: > On Fri, Sep 27, 2019 at 12:00 PM Asif Rehman > wrote: > >> > - SEND_FILES_CONTENTS (file1, file2,...) - returns the files in given > list. > >> > pg_basebackup will then send back a list of filenames in this > command. This commands will be

Re: [HACKERS] Block level parallel vacuum

On Wed, Oct 2, 2019 at 7:29 PM Masahiko Sawada wrote: > On Sat, Sep 21, 2019 at 9:31 PM Amit Kapila > wrote: > > > > * > > +end_parallel_vacuum(LVParallelState *lps, Relation *Irel, int nindexes) > > { > > .. > > + /* Shutdown worker processes and destroy the parallel context */ > > +

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 cannot be hit in DropDatabase function as

Re: Attempt to consolidate reading of XLOG page

This is the next version. -- Antonin Houska Web: https://www.cybertec-postgresql.com >From 01f5cc8b0c1e6133e16242ec99957a78551058a7 Mon Sep 17 00:00:00 2001 From: Antonin Houska Date: Fri, 4 Oct 2019 12:07:22 +0200 Subject: [PATCH 1/2] Use only xlogreader.c:XLogRead() The implementations in

Re: [HACKERS] Block level parallel vacuum

On Fri, Oct 4, 2019 at 11:01 AM Amit Kapila wrote: > > On Fri, Oct 4, 2019 at 10:28 AM Masahiko Sawada wrote: >> Some more comments.. 1. + for (idx = 0; idx < nindexes; idx++) + { + if (!for_cleanup) + lazy_vacuum_index(Irel[idx], [idx], vacrelstats->dead_tuples, +

Re: pgsql: Remove pqsignal() from libpq's official exports list.

Re: Tom Lane 2018-09-28 > Remove pqsignal() from libpq's official exports list. > > Client applications should get this function, if they need it, from > libpgport. > > The fact that it's exported from libpq is a hack left over from before > we set up libpgport. It's never been documented, and

Shared memory

Why postgres not providing freeing shared memory?

Re: Standby accepts recovery_target_timeline setting?

On Wed, Oct 02, 2019 at 03:30:38AM -0400, Stephen Frost wrote: > * David Steele (da...@pgmasters.net) wrote: >> On 9/28/19 1:26 PM, Fujii Masao wrote: >>> There might be some recovery parameters that we can safely use >>> even in crash recovery, e.g., maybe recovery_end_command >>> (now, you can

Re: refactoring - share str2*int64 functions

Is there any specific reason for hard coding the *base* of a number representing the string in strtouint64(). I understand that currently strtouint64() is being used just to convert an input string to decimal unsigned value but what if we want it to be used for hexadecimal values or may be some

Re: dropping column prevented due to inherited index

On Thu, Oct 03, 2019 at 09:18:12AM -0300, Alvaro Herrera wrote: > Hmm. I wonder if we shouldn't adopt the coding pattern we've used > elsewhere of collecting all columns to be dropped first into an > ObjectAddresses array, then use performMultipleDeletions. +1. That's the common pattern these

Re: Include RELKIND_TOASTVALUE in get_relkind_objtype

On Thu, Oct 03, 2019 at 09:52:34AM -0400, Tom Lane wrote: > FWIW, I really dislike this patch, mainly because it is based on the > assumption (as John said) that get_relkind_objtype is used only > in aclcheck_error calls. However it's not obvious why that should > be true, and there certainly is

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

On Thu, Oct 03, 2019 at 12:43:37PM +0300, Alexey Kondratov wrote: > On 03.10.2019 6:07, Michael Paquier wrote: >> I have reworked your first patch as per the attached. What do you >> think about it? The part with the control file needs to go down to >> v12, and I would likely split that into two

Re: Memory Accounting

On Fri, Oct 04, 2019 at 12:36:01AM -0400, Tom Lane wrote: So ... why exactly did this patch define MemoryContextData.mem_allocated as int64? That seems to me to be doubly wrong: it is not the right width on 32-bit machines, and it is not the right signedness anywhere. I think that field ought

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

On Fri, Oct 4, 2019 at 12:10 PM Smith, Peter wrote: > From: Tom Lane Sent: Friday, 4 October 2019 2:08 PM > > >> #define INIT_ALL_ELEMS_ZERO {0} > >> #define INIT_ALL_ELEMS_FALSE {false} > > >I would say that's 100% wrong. The entire point here is that it's > memset-equivalent, and therefore

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

From: Tom Lane Sent: Friday, 4 October 2019 2:08 PM >> #define INIT_ALL_ELEMS_ZERO {0} >> #define INIT_ALL_ELEMS_FALSE {false} >I would say that's 100% wrong. The entire point here is that it's >memset-equivalent, and therefore writes zeroes, regardless of what the >datatype is. I agree