Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

Hello, On Sun, Oct 6, 2019 at 9:48 PM Nikolay Shaplov wrote: > This message is follow up to the "Get rid of the StdRdOptions" patch thread: > https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m > > I've split patch into even smaller parts and commitfest want each patch in > separate th

Re: maintenance_work_mem used by Vacuum

On Thu, Oct 10, 2019 at 9:58 AM Masahiko Sawada wrote: > > On Wed, Oct 9, 2019 at 7:12 PM Dilip Kumar wrote: > > > > I think the current situation is not good but if we try to cap it to > > maintenance_work_mem + gin_*_work_mem then also I don't think it will > > make the situation much better.

Re: adding partitioned tables to publications

On Mon, Oct 7, 2019 at 9:55 AM Amit Langote wrote: > One cannot currently add partitioned tables to a publication. > > create table p (a int, b int) partition by hash (a); > create table p1 partition of p for values with (modulus 3, remainder 0); > create table p2 partition of p for values with (m

Re: [PATCH] use separate PartitionedRelOptions structure to store partitioned table options

Hello, On Tue, Oct 8, 2019 at 7:50 PM Nikolay Shaplov wrote: > В письме от вторник, 8 октября 2019 г. 16:00:49 MSK пользователь Amit Langote > написал: > > IIUC, this patch invents PartitionedRelOptions as the binary > > representation for future RELOPT_KIND_PARTITIONED parameters. As long > > a

Re: dropping column prevented due to inherited index

Hello, On Thu, Oct 10, 2019 at 1:13 PM Michael Paquier wrote: > On Wed, Oct 09, 2019 at 06:36:35AM -0300, Alvaro Herrera wrote: > > Right, something like that. Needs a comment to explain what we do and > > how recursing=true correlates with addrs=NULL, I think. Maybe add an > > assert. > > Yes,

configure fails for perl check on CentOS8

Hello, While I'm moving to CentOS8 environment, I got stuck at ./configure with the following error. configure: error: libperl library is requred for Perl It complains that it needs -fPIC. Configure uses only $Config{ccflags}, but it seems that $Config{cccdlflags} is also required. The attached

Re: [HACKERS] Block level parallel vacuum

On Fri, Oct 4, 2019 at 7:48 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: >> > >> > * >> > +end_parallel_vacuum(LVParallelState *lps, Relation *Irel, int nindexes) >> > { >> > .. >> > + /* Shutdown worker

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: >> Few more comments: - 1. Caurrently parallel vacuum is allowed for temporary relations which is wrong. It leads to below error: postgres=# create tempo

Re: Include RELKIND_TOASTVALUE in get_relkind_objtype

On Fri, Oct 04, 2019 at 05:55:40PM +0900, Michael Paquier wrote: > 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. Howev

Re: pgbench - extend initialization phase control

Hello Fabien, -- Forwarded message - From: Fabien COELHO Date: Tue, Jul 16, 2019 at 4:58 PM Subject: Re: pgbench - extend initialization phase control To: Ibrar Ahmed Cc: PostgreSQL Developers Hello Ibrar, The following review has been posted through the commitfest applic

Re: maintenance_work_mem used by Vacuum

On Wed, Oct 9, 2019 at 7:12 PM Dilip Kumar wrote: > > On Wed, Oct 9, 2019 at 2:40 PM Amit Kapila wrote: > > > > On Wed, Oct 9, 2019 at 2:00 PM Dilip Kumar wrote: > > > > > > On Wed, Oct 9, 2019 at 10:22 AM Masahiko Sawada > > > wrote: > > > > > > > > On Tue, Oct 8, 2019 at 2:45 PM Amit Kapila

Re: dropping column prevented due to inherited index

On Wed, Oct 09, 2019 at 06:36:35AM -0300, Alvaro Herrera wrote: > Right, something like that. Needs a comment to explain what we do and > how recursing=true correlates with addrs=NULL, I think. Maybe add an > assert. Yes, that would be a thing to do. So I have added more comments regarding that

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

On Wed, Oct 09, 2019 at 09:37:34AM -0400, Stephen Frost wrote: > Yes, this is absolutely the right answer, we shouldn't be removing > symbols without an SONAME bump. If we don't want to bump the SONAME, > then don't remove the symbol. This is utterly basic proper library > maintenance and it isn'

Re: [HACKERS] Block level parallel vacuum

On Wed, Oct 9, 2019 at 6:13 AM Masahiko Sawada wrote: > > On Sat, Oct 5, 2019 at 4:36 PM Dilip Kumar wrote: > > > > 3. > > @@ -2888,6 +2888,8 @@ table_recheck_autovac(Oid relid, HTAB > > *table_toast_map, > > (!wraparound ? VACOPT_SKIP_LOCKED : 0); > > tab->at_params.index_cleanup = VACOPT_T

Re: Minimal logical decoding on standbys

On Tue, 1 Oct 2019 at 02:08, Robert Haas wrote: > > Why does create_logical_slot_on_standby include sleep(1)? Yeah, we really need to avoid sleeps in regression tests. If you need to wait, use a DO block that polls the required condition, and wrap the sleep in that with a much longer total tim

Re: Minimal logical decoding on standbys

On Sat, 6 Apr 2019 at 07:15, Andres Freund wrote: > Hi, > > Thanks for the new version of the patch. Btw, could you add Craig as a > co-author in the commit message of the next version of the patch? Don't > want to forget him. > That's kind, but OTOH you've picked it up and done most of the wor

Re: Shared memory

On Fri, 4 Oct 2019 at 17:51, Natarajan R wrote: > Why postgres not providing freeing shared memory? > It does. You are presumably looking at static shared memory segments which are assigned at server start. Most extensions need to use one of these, of fixed size, for housekeeping and things lik

Re: pg_init

On Wed, 9 Oct 2019 at 00:33, Natarajan R wrote: > I want to read pg_database from pg_init... > > Is using heap_open() is possible? or else any other way is there ? > It's not possible from _PG_init . I replied to a similar thread with details on how bgworkers can access different databases; loo

Re: Transparent Data Encryption (TDE) and encrypted files

On Wed, 9 Oct 2019 at 22:30, Stephen Frost wrote: > > - All decryption happens in a given backend when it's sending data to > the client > That is not what I think of as TDE. But upon review, it looks like I'm wrong, and the usual usage of TDE is for server-side-only encryption at-rest. But w

Re: TCP Wrappers

On Thu, 10 Oct 2019 at 07:15, Tom Lane wrote: > > That doesn't bode well for the number of people who would use or care > about such a feature. > Agreed. tcp_wrappers predates the widespread availability of easy, effective software firewalls. Back when services listened on 0.0.0.0 and if you we

Re: TCP Wrappers

Steve Crawford writes: > On Wed, Oct 9, 2019 at 12:56 PM Timmy Siu wrote: >> May I suggest the community to have postgres to work with TCP wrappers.?? >> Its security will be better. > The last stable release of TCP Wrappers was a couple decades ago. It's > deprecated in RHEL7 and removed in RHE

RE: Proposal: Add more compile-time asserts to expose inconsistencies.

From: Andres Freund Sent: Tuesday, 1 October 2019 3:14 AM >I wonder if defining the fallback static assert code to something like > extern void static_assert_func(int static_assert_failed[(condition) ? 1 : > -1]); isn't a solution, however. I *think* that's standard C. Seems to work > at least

Re: TCP Wrappers

Yeah, why bother. Even ’native’ encryption/SSL in PG (were one to use it ‘natively’, as we do) is so good; adding yet another layer seems overkill… Lou Picciano > On Oct 9, 2019, at 6:39 PM, Steve Crawford > wrote: > > > On Wed, Oct 9, 2019 at 12:56 PM Timmy Siu >

Re: TCP Wrappers

On Wed, Oct 9, 2019 at 12:56 PM Timmy Siu wrote: > Dear all postgresql developers, > > I have tested postgres v11 against TCP Wrappers but it does not respond > to TCP wrappers port blocking. > > May I suggest the community to have postgres to work with TCP wrappers.?? > Its security will be bett

Re: Missed check for too-many-children in bgworker spawning

Robert Haas writes: > On Wed, Oct 9, 2019 at 10:21 AM Tom Lane wrote: >> We could improve on matters so far as the postmaster's child-process >> arrays are concerned, by defining separate slot "pools" for the different >> types of child processes. But I don't see much point if the code is >> not

Re: [PATCH] Do not use StdRdOptions in Access Methods

В письме от среда, 9 октября 2019 г. 20:26:14 MSK пользователь Dent John написал: > I didn’t spot it was an existing pattern. Sorry, this might be my mistake I should explicitly mention it in the first place. > And I agree — making the code uniform will make it easier to evolve in > future. >

Re: Standby accepts recovery_target_timeline setting?

On 2019-09-30 03:48, Fujii Masao wrote: > Also we need to do the same thing for other recovery options like > restore_command. Attached is the patch which makes crash recovery > ignore restore_command and recovery_end_command. This patch looks correct to me. Do we need to handle archive_cleanup_c

Re: Change atoi to strtol in same place

David Rowley writes: > On Tue, 8 Oct 2019 at 19:46, Joe Nelson wrote: >> David Rowley wrote: >>> The translation string here must be consistent over all platforms. I >>> think this will cause issues if the translation string uses %ld and >>> the platform requires %lld? >> A very good and subtle

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On Wed, 9 Oct 2019 at 08:15, Dave Cramer wrote: > > > On Tue, 8 Oct 2019 at 11:57, Craig Ringer wrote: > >> On Thu, 11 Jul 2019 at 04:34, Tom Lane wrote: >> >>> Robert Haas writes: >>> > On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer wrote: >>> >> I'm still a bit conflicted about what to do with

TCP Wrappers

Dear all postgresql developers, I have tested postgres v11 against TCP Wrappers but it does not respond to TCP wrappers port blocking. May I suggest the community to have postgres to work with TCP wrappers.?? Its security will be better. Regards, Timmy

Re: Collation versioning

On 2019-10-09 21:19, Peter Eisentraut wrote: > On 2019-10-03 14:25, Thomas Munro wrote: >>> The only open question on this patch was whether it's a good version to >>> use. I think based on subsequent discussions, there was the realization >>> that this is the best we can do and better than nothin

Re: [PATCH] Do not use StdRdOptions in Access Methods

> On 8 Oct 2019, at 11:33, Nikolay Shaplov wrote: > > Whoa-whoa! > > I am not inventing something new here. Same code is already used in brin > (brin.c:820), gin (ginutils.c:602) and gist (gistutils.c:909) indexes. I've > just copied the idea, to do all index code uniform. > > This does not m

Re: Collation versioning

On 2019-10-03 14:25, Thomas Munro wrote: >> The only open question on this patch was whether it's a good version to >> use. I think based on subsequent discussions, there was the realization >> that this is the best we can do and better than nothing. >> >> In the patch, I would skip the configure

Re: [HACKERS] Deadlock in XLogInsert at AIX

Noah Misch writes: > On Mon, Oct 07, 2019 at 03:06:35PM -0400, Tom Lane wrote: >> This still fails on Apple's compilers. ... > Thanks for testing. That error boils down to "need to use some other > register". The second operand of addi is one of the ppc instruction operands > that can hold a co

Re: Missed check for too-many-children in bgworker spawning

On Wed, Oct 9, 2019 at 10:21 AM Tom Lane wrote: > Well, that means we have a not-very-stable system then. > > We could improve on matters so far as the postmaster's child-process > arrays are concerned, by defining separate slot "pools" for the different > types of child processes. But I don't se

Re: Global shared meta cache

On 09.10.2019 9:06, ideriha.take...@fujitsu.com wrote: Hi, Konstantin From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru] I do not completely understand from your description when are are going to evict entry from local cache? Just once transaction is committed? I think it will be m

Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros)

On 2019-10-08 06:59, Noah Misch wrote: >> Btw., JUnit uses the ordering convention assertEquals(expected, actual), >> whereas Perl Test::More uses is(actual, expected). Let's make sure we >> pick something and stick with it. > Since we write "if (actual == expected)", I prefer f(actual, expected).

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

2019年10月8日(火) 1:56 Tom Lane : > > Kohei KaiGai writes: > > 2019年10月7日(月) 23:44 Robert Haas : > >> But if we want to stick with the ad-hoc method, we could also just > >> have four possible return values: dominates, dominated-by, both, or > >> neither. > > > It seems to me this is a bit different f

Re: Transparent Data Encryption (TDE) and encrypted files

On Mon, Oct 7, 2019 at 12:34:36PM -0400, Bruce Momjian wrote: > On Mon, Oct 7, 2019 at 12:30:37PM -0400, Robert Haas wrote: > > On Mon, Oct 7, 2019 at 11:48 AM Bruce Momjian wrote: > > > Well, I am starting with the things I _know_ need encrypting, and am > > > then waiting for others to tell me

Re: Standby accepts recovery_target_timeline setting?

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Oct 9, 2019 at 8:42 AM Stephen Frost wrote: > > If anything, what we should be doing here is throwing a WARNING or > > similar that these settings don't make sense, because we aren't going > > through recovery, and blank them out.

Re: Transparent Data Encryption (TDE) and encrypted files

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Thu, Oct 3, 2019 at 4:40 PM Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > > > On Mon, Sep 30, 2019 at 5:26 PM Bruce Momjian wrote: > > > > For full-cluster Transparent Data Encryption (TDE), the current plan

Re: Missed check for too-many-children in bgworker spawning

Robert Haas writes: > On Mon, Oct 7, 2019 at 4:03 PM Tom Lane wrote: >> ... Moreover, we have to --- and already do, I trust --- deal with >> other resource-exhaustion errors in exactly the same code path, notably >> fork(2) failure which we simply can't predict or prevent. Doesn't the >> parall

Re: Missed check for too-many-children in bgworker spawning

On Mon, Oct 7, 2019 at 4:03 PM Tom Lane wrote: > I'm not following your point? Whatever you might think the appropriate > response is, I'm pretty sure "elog(FATAL) out of the postmaster" is not > it. Moreover, we have to --- and already do, I trust --- deal with > other resource-exhaustion error

Re: Standby accepts recovery_target_timeline setting?

On Wed, Oct 9, 2019 at 8:42 AM Stephen Frost wrote: > You're going to be really confused when you realize that, sure, it's > set, but we just completely ignored it ... No, I'm not, because I expect that settings will only take effect for operations to which they apply. As Fujii Masao also pointed

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

Greetings, * Christoph Berg (m...@debian.org) wrote: > Re: Tom Lane 2019-10-08 <9333.1570566...@sss.pgh.pa.us> > > Having said all that, if we conclude we can't break compatibility > > with this legacy code quite yet, I'd be inclined to put a > > separate, clearly-marked-as-legacy-code version of

Re: abort-time portal cleanup

On Tue, Oct 8, 2019 at 2:10 PM Andres Freund wrote: > On 2019-10-07 12:14:52 -0400, Robert Haas wrote: > > > - if (portal->status == PORTAL_READY) > > > - MarkPortalFailed(portal); > > > > > > Why it is safe to remove this check? It has been explained in commit > > > 7981c342 why we need that che

Remove size limitations of vacuums dead_tuples array

When dealing with a case where a 2TB table had 3 billion dead tuples I discovered that vacuum currently can't make use of more than 1GB of maintenance_work_mem - 179M tuples. This caused excessive amounts of index scanning even though there was plenty of memory available. I didn't see any good rea

Re: Standby accepts recovery_target_timeline setting?

Greetings, * Fujii Masao (masao.fu...@gmail.com) wrote: > On Wed, Oct 9, 2019 at 1:02 AM Stephen Frost wrote: > > * Fujii Masao (masao.fu...@gmail.com) wrote: > > > On Tue, Oct 8, 2019 at 10:58 PM Stephen Frost wrote: > > > > Having these options end up set but then hacking all of the other code

Re: v12 and pg_restore -f-

Greetings, * Euler Taveira (eu...@timbira.com.br) wrote: > Em ter, 8 de out de 2019 às 15:08, Stephen Frost > escreveu: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Andrew Gierth writes: > > > > "Tom" == Tom Lane writes: > > > > Tom> Perhaps we could change the back branches so that they

Re: Standby accepts recovery_target_timeline setting?

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Oct 8, 2019 at 9:58 AM Stephen Frost wrote: > > From a user > > perspective, what happens when you've started up PG as a primary, since > > you don't have a signal file in place to indicate that you're doing > > recovery, and you h

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

On Tue, 8 Oct 2019 at 11:57, Craig Ringer wrote: > On Thu, 11 Jul 2019 at 04:34, Tom Lane wrote: > >> Robert Haas writes: >> > On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer wrote: >> >> I'm still a bit conflicted about what to do with search_path as I do >> believe this is potentially a security

Re: v12 and pg_restore -f-

Em ter, 8 de out de 2019 às 15:08, Stephen Frost escreveu: > > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Andrew Gierth writes: > > > "Tom" == Tom Lane writes: > > > Tom> Perhaps we could change the back branches so that they interpret > > > Tom> "-f -" as "write to stdout", but

Re: Standby accepts recovery_target_timeline setting?

On Tue, Oct 8, 2019 at 9:58 AM Stephen Frost wrote: > From a user > perspective, what happens when you've started up PG as a primary, since > you don't have a signal file in place to indicate that you're doing > recovery, and you have a recovery_target set, so some user does > "show recovery_targe

Re: maintenance_work_mem used by Vacuum

On Wed, Oct 9, 2019 at 2:40 PM Amit Kapila wrote: > > On Wed, Oct 9, 2019 at 2:00 PM Dilip Kumar wrote: > > > > On Wed, Oct 9, 2019 at 10:22 AM Masahiko Sawada > > wrote: > > > > > > On Tue, Oct 8, 2019 at 2:45 PM Amit Kapila > > > wrote: > > > > > > > > On Tue, Oct 8, 2019 at 1:48 AM Peter G

Re: dropping column prevented due to inherited index

On 2019-Oct-09, Michael Paquier wrote: > On Tue, Oct 08, 2019 at 06:25:05PM +0900, Amit Langote wrote: > > I thought about doing something like that, but wasn't sure if > > introducing that much complexity is warranted. > > I looked at that. By experience, I think that it would be wiser to do >

Re: maintenance_work_mem used by Vacuum

On Wed, Oct 9, 2019 at 2:00 PM Dilip Kumar wrote: > > On Wed, Oct 9, 2019 at 10:22 AM Masahiko Sawada wrote: > > > > On Tue, Oct 8, 2019 at 2:45 PM Amit Kapila wrote: > > > > > > On Tue, Oct 8, 2019 at 1:48 AM Peter Geoghegan wrote: > > > > > > > > ISTM that the use of maintenance_work_mem wasn

Re: maintenance_work_mem used by Vacuum

On Wed, Oct 9, 2019 at 10:22 AM Masahiko Sawada wrote: > > On Tue, Oct 8, 2019 at 2:45 PM Amit Kapila wrote: > > > > On Tue, Oct 8, 2019 at 1:48 AM Peter Geoghegan wrote: > > > > > > On Mon, Oct 7, 2019 at 12:28 PM Robert Haas wrote: > > > > I would say that sucks, because it makes it harder to

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

Re: Tom Lane 2019-10-08 <9333.1570566...@sss.pgh.pa.us> > Having said all that, if we conclude we can't break compatibility > with this legacy code quite yet, I'd be inclined to put a > separate, clearly-marked-as-legacy-code version of pqsignal() > back into libpq, using the pre-9.3 SA_RESTART sem

Re: dropping column prevented due to inherited index

On Tue, Oct 08, 2019 at 06:25:05PM +0900, Amit Langote wrote: > I thought about doing something like that, but wasn't sure if > introducing that much complexity is warranted. I looked at that. By experience, I think that it would be wiser to do first the lookup of all the dependencies you would l