Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

Hi, On 2017-09-08 22:35:39 +0300, Sokolov Yura wrote: > From 722a8bed17f82738135264212dde7170b8c0f397 Mon Sep 17 00:00:00 2001 > From: Sokolov Yura > Date: Mon, 29 May 2017 09:25:41 + > Subject: [PATCH 1/6] More correct use of spinlock inside LWLockWaitListLock.

Re: [HACKERS] Re: protocol version negotiation (Re: Libpq PGRES_COPY_BOTH - version compatibility)

Hi Robert, Thanks very much for your quick response. PFA the patch containing the BE changes for pgwire v3.1, correctly formatted using pgindent this time  A few salient points: >> SendServerProtocolVersionMessage should be adjusted to use the new >> facilities added by commit

Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA

Hi, On 2017-06-05 16:22:58 +0300, Sokolov Yura wrote: > Patch changes the way LWLock is acquired. > > Before patch, lock is acquired using following procedure: > 1. first LWLock->state is checked for ability to take a lock, and CAS > performed (either lock could be acquired or not). And it is

Re: [HACKERS] 64-bit queryId?

On Thu, Oct 19, 2017 at 4:12 AM, Robert Haas wrote: > On Wed, Oct 18, 2017 at 9:20 AM, Julien Rouhaud wrote: >> Sorry for replying so late, but I have a perhaps naive question about >> the hashtable handling with this new version. >> >> IIUC, the shared

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

On Wed, Oct 18, 2017 at 02:45:47PM -0700, David G. Johnston wrote: > On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams > wrote: > > On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote: > > > > More useful than this, for me, would be a way to get the top-most

Re: [HACKERS] [COMMITTERS] pgsql: Fix traversal of half-frozen update chains

On Wed, Oct 18, 2017 at 1:54 PM, Robert Haas wrote: > Well, I guess what I don't understand is, suppose we have a HOT chain > that looks like this, where [x,y] denotes a tuple with an xmin of x > and an xmax of y. > > [a,b]->[b,c]->[c,d] > > If b is eligible to be frozen,

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams wrote: > On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote: > > > More useful than this, for me, would be a way to get the top-most user. > > > > That would be "session_user"? > > It's not quite since there's a

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote: > > More useful than this, for me, would be a way to get the top-most user. > > That would be "session_user"? It's not quite since there's a difference between SET SESSION AUTHORIZATION and SET SESSION ROLE. But yes, it's what

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

On Wed, Oct 18, 2017 at 2:08 PM, Nico Williams wrote: > On Wed, Oct 18, 2017 at 01:43:30PM -0700, David G. Johnston wrote: > > More useful than this, for me, would be a way to get the top-most user. > > ​That would be "session_user"?​ > Introducing the concept of a stack

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

On Wed, Oct 18, 2017 at 01:43:30PM -0700, David G. Johnston wrote: > Regardless of the merits of the proposed feature, the function > "session_user" is SQL-defined and should not be modified or enhanced. > > I could see "calling_role()" being useful - it returns the same value > as "current_role"

Re: [HACKERS] [COMMITTERS] pgsql: Fix traversal of half-frozen update chains

On Tue, Oct 17, 2017 at 6:02 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> I haven't really followed this thread in depth, but I'm very nervous >> about the idea that we should ever be examining the raw-xmin of a >> tuple that has been marked HEAP_XMIN_FROZEN for

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

On Wed, Oct 18, 2017 at 1:26 PM, Nico Williams wrote: > On Wed, Oct 18, 2017 at 10:15:01PM +0200, Pavel Stehule wrote: > > there is a function session_user() already > > But it doesn't do this. Are you saying that I should add a > session_user(int)? > > ​Regardless of the

Re: [HACKERS] [POC] Faster processing at Gather node

Hi, On 2017-10-18 15:46:39 -0400, Robert Haas wrote: > > 2) The spinlocks both on the the sending and receiving side a quite hot: > > > >rafia query leader: > > + 36.16% postgres postgres[.] shm_mq_receive > > + 19.49% postgres postgres[.] s_lock > > + 13.24%

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

On Wed, Oct 18, 2017 at 10:15:01PM +0200, Pavel Stehule wrote: > there is a function session_user() already But it doesn't do this. Are you saying that I should add a session_user(int)? Nico -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

2017-10-18 22:01 GMT+02:00 Nico Williams : > It'd be nice if SECURITY DEFINER functions could see what user invoked > them, but current_user is the DEFINER user, naturally, since that's how > this is done in fmgr_security_definer(). > > I was thinking that

Re: [HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

Alternatively, a way to get at the OuterUserId? Or the outer-most current_user in the function stack? I should explain why I need this: for audit functionality where I want the triggers' procedures to be SECURITY DEFINER so only they can write to audit tables and such, but I want them to see the

[HACKERS] Interest in a SECURITY DEFINER function current_user stack access mechanism?

It'd be nice if SECURITY DEFINER functions could see what user invoked them, but current_user is the DEFINER user, naturally, since that's how this is done in fmgr_security_definer(). I was thinking that fmgr_security_definer() could keep a global pointer to a linked list (with automatic nodes)

Re: [HACKERS] [GENERAL] huge RAM use in multi-command ALTER of table heirarchy

Hi, I just ran into this again in another context (see original dicussion, quoted below). Some time ago, while initially introducting non-default stats target, I set our non-filtering columns to "STATISTICS 10", lower than default, to minimize the size of pg_statistic, which (at least at one

Re: [HACKERS] [POC] Faster processing at Gather node

On Tue, Oct 17, 2017 at 5:39 PM, Andres Freund wrote: > The precise query doesn't really matter, the observations here are more > general, I hope. > > 1) nodeGather.c re-projects every row from workers. As far as I can tell >that's now always exactly the same targetlist as

[HACKERS] Re: heap/SLRU verification, relfrozenxid cut-off, and freeze-the-dead bug (Was: amcheck (B-Tree integrity checking tool))

On Mon, Oct 16, 2017 at 8:09 PM, Noah Misch wrote: > That presupposes construction of two pieces of software, the server and the > checker, such that every disagreement is a bug in the server. But checkers > get bugs just like servers get bugs. You make a good point, which is

Re: [HACKERS] 64-bit queryId?

On Wed, Oct 18, 2017 at 9:20 AM, Julien Rouhaud wrote: > Sorry for replying so late, but I have a perhaps naive question about > the hashtable handling with this new version. > > IIUC, the shared hash table is now created with HASH_BLOBS instead of > HASH_FUNCTION, so since

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

On Wed, Oct 18, 2017 at 2:50 PM, Tom Lane wrote: > Robert Haas writes: >> Heikki, do you have any plans to work more on this? >> Or does anyone else? > > FWIW, I have some interest in the Apple Secure Transport patch that > is in the CF queue, and will

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Wed, Oct 18, 2017 at 1:18 PM, Alvaro Herrera wrote: > I'm okay with prohibiting the case of different persistence values as > you suggest. And I do suggest to back-patch that prohibition to pg10. I disagree. There's nothing any more broken about the way this works

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Alvaro Herrera writes: > And the previous code crashes in 45 minutes? That's solid enough for > me; I'll clean up the patch and push in the next few days. I think what > you have now should be sufficient for the time being for your production > system. I'm still of the

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

Robert Haas writes: > Heikki, do you have any plans to work more on this? > Or does anyone else? FWIW, I have some interest in the Apple Secure Transport patch that is in the CF queue, and will probably pick that up at some point if no one beats me to it (but it's not real

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Wed, Oct 18, 2017 at 07:22:27PM +0200, Alvaro Herrera wrote: > Do you still have those core dumps? If so, would you please verify the > database that autovacuum was running in? Just open each with gdb (using > the original postgres binary, not the one you just installed) and do > "print

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby wrote: > On Wed, Oct 18, 2017 at 06:54:09PM +0200, Alvaro Herrera wrote: > > And the previous code crashes in 45 minutes? That's solid enough for > > me; I'll clean up the patch and push in the next few days. I think what > > you have now should be sufficient for the time being

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

Robert Haas wrote: > On Wed, Oct 18, 2017 at 11:27 AM, Alvaro Herrera > wrote: > > Maybe there are combinations of different persistence values that can be > > allowed to differ (an unlogged partition is probably OK with a permanent > > parent), but I don't think the

Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement

On Tue, Aug 12, 2014 at 1:52 PM, Heikki Linnakangas wrote: > On 08/06/2014 08:37 PM, Jeff Janes wrote: >> >> But now it looks like 0002 needs a rebase > > I've committed the refactoring patch, and here's a rebased and improved > version of the Windows SChannel

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Wed, Oct 18, 2017 at 06:54:09PM +0200, Alvaro Herrera wrote: > Justin Pryzby wrote: > > > No crashes in ~28hr. It occurs to me that it's a weaker test due to not > > preserving most compilation options. > > And the previous code crashes in 45 minutes? That's solid enough for > me; I'll

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Wed, Oct 18, 2017 at 11:27 AM, Alvaro Herrera wrote: > Maybe there are combinations of different persistence values that can be > allowed to differ (an unlogged partition is probably OK with a permanent > parent), but I don't think the current check is good enough.

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby wrote: > No crashes in ~28hr. It occurs to me that it's a weaker test due to not > preserving most compilation options. And the previous code crashes in 45 minutes? That's solid enough for me; I'll clean up the patch and push in the next few days. I think what you have now

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Tue, Oct 17, 2017 at 09:07:40AM -0500, Justin Pryzby wrote: > On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote: > > Justin Pryzby writes: > > > On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: > > >> Anyway, can give this patch a try? > > > > The

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

Robert Haas writes: > On Wed, Oct 18, 2017 at 4:53 AM, Alvaro Herrera > wrote: >> My view is that the fact that partitioning uses inheritance is just an >> implementation detail. We shouldn't let historical behavior for >> inheritance dictate

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Wed, Oct 18, 2017 at 4:53 AM, Alvaro Herrera wrote: > My view is that the fact that partitioning uses inheritance is just an > implementation detail. We shouldn't let historical behavior for > inheritance dictate behavior for partitioning. Inheritance has many >

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

This check is odd (tablecmds.c ATExecAttachPartition line 13861): /* Temp parent cannot have a partition that is itself not a temp */ if (rel->rd_rel->relpersistence == RELPERSISTENCE_TEMP && attachrel->rd_rel->relpersistence != RELPERSISTENCE_TEMP) ereport(ERROR,

Re: [HACKERS] 64-bit queryId?

On Thu, Oct 12, 2017 at 2:46 AM, Michael Paquier wrote: > On Thu, Oct 12, 2017 at 9:05 AM, Robert Haas wrote: >> On Wed, Oct 4, 2017 at 9:00 PM, Michael Paquier >> wrote: >>> v4 looks correct to me. Testing it through

Re: [HACKERS] alter table doc fix

Amit Langote wrote: > Hi. > > Noticed that a alter table sub-command's name in Description (where it's > OWNER) differs from that in synopsis (where it's OWNER TO). Attached > patch to make them match, if the difference is unintentional. I agree -- pushed. This paragraph The actions

Re: [HACKERS] v10 telease note for pg_basebackup refers to old --xlog-method argument

Pushed. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Re: Is anything preventing us from allowing write to foreign tables from standby?

Hi guys, please help me to understand the proposal. Take a simple configuration: Two "live" systems S1 and S2 and for each of them a Replica R1 and R2. So S1 sends data to R1 and S2 to R2. S1 has foreign tables on S2 with write access, meaning you can change a few data from S1 where information

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

Amit Langote wrote: > On 2017/10/18 1:52, Alvaro Herrera wrote: > > Alvaro Herrera wrote: > >> Robert Haas wrote: > >>> Implement table partitioning. > >> > >> Is it intentional that you can use ALTER TABLE OWNER TO on the parent > >> table, and that this does not recurse to modify the partitions'

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

On Wed, Oct 18, 2017 at 5:32 AM, Fabien COELHO wrote: > > Hello Masahiko-san, > >>> Attached the updated version patch. >> >> >> Applies, compiles, make check & tap test ok, doc is fine. >> >> All is well for me: the feature is useful, code is simple and clean, it is >> easy