On Thu, Oct 19, 2017 at 1:08 AM, Michael Paquier
wrote:
> On Thu, Oct 19, 2017 at 4:12 AM, Robert Haas wrote:
>> On Wed, Oct 18, 2017 at 9:20 AM, Julien Rouhaud wrote:
>>> WIth current pgssHashKey definition, there shouldn't be padding bits,
>>> so it should be safe. But I wonder if adding an e
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.
>
> SpinDelayStatus should be
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 1de09ad8eb1fa673
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 r
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 hash table is now created with HASH_BLOBS i
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 user.
> > >
> > > That would
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, then b is committed and a
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 difference between SET
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 I'
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 at the SQL level here se
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"
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 anything other than
>> forensi
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 merits of the proposed
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%
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 subs
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 fmgr_security_definer() could keep a glob
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
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) of
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 poin
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 it's coming from the
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 that *some* code mu
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 sizeof(pgssHashKey) !=
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 probably pick that up at some point if
> no
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
with partitioning in v10 th
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 opinion that the presente
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 high on my to-do list).
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 MyData
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 for
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 current check is good enough.
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 implementation over that.
>
> Ser
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 clean
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.
This is also a sort of long-
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 should
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 trick in this sort of si
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 behavior for partitioning. Inheritance has many
>>
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
> undesirable warts.
I am OK wi
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,
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 (pgbench and some custom
>>> queries) I have not spotted issues. If the final
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 fo
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:
http://www.postgresql.org/mailpref/pgsql-hacke
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 i
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'
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 to invoke, easy to ext
43 matches
Mail list logo