Re: [HACKERS] Regression tests vs existing users in an installation

[Alvaro Herrera]

Tom Lane wrote:
> We've talked before about how the regression tests should be circumspect
> about what role names they create/drop, so as to avoid possibly blowing
> up an installation's existing users during "make installcheck".  In
> particular I believe there was consensus that such names should begin
> with, or at least include, "regress".  I got around today to instrumenting
> CreateRole to see what names we were actually creating, and was quite
> depressed as to how thoroughly that guideline is being ignored (see
> attached).
> 
> I propose to go through the regression tests and fix this (in HEAD only).

I would propose that we have one test run near the beginning or right at
the beginning of the serial schedule that sets up a small number of
roles to cover most of the needs of every other test, so that most such
other tests do not need to create any roles at all.  (Of course, there
would be a few cases where this would defeat the purpose of the test
because creating or dropping the role is precisely what is being
created; those cases would have additional roles, with the proposed
prefix.)

So currently we have 97 roles?  Probably we can get away with a dozen or
so, maybe even less than that.

> What I'm inclined to do with this is to reduce the test to be something
> like
> 
> BEGIN;
> CREATE ROLE "Public";
> CREATE ROLE "None";
> CREATE ROLE "current_user";
> CREATE ROLE "session_user";
> CREATE ROLE "user";
> ROLLBACK;
> 
> with maybe a couple of ALTERs and GRANTs inside the transaction to verify
> that the names can be referenced as well as created.  This would be safe
> against modifying any conflicting existing users; the only bad consequence
> would be a phony failure of the test.
>
> I thought about trying to preserve all the existing test cases while still
> keeping these roles inside a transaction, by inserting savepoints around
> the intentional failures.  But there are enough intentional failures in
> rolenames.sql that that would be really tedious.  The existing test cases
> seem enormously duplicative to me anyway, so I think a fairly short
> transaction with a few tests would be sufficient to cover this territory.


> A more aggressive answer would be to decide we don't need these test cases
> at all and drop them.

Hmm ... I think a blanket removal would go against generally accepted
principle that our tests need to cover more functionality.

Maybe we did go overboard on that one and the rolled-back creation is
enough test for that functionality.

-- 
Álvaro Herrerahttp://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-hackers

Re: [HACKERS] Reviewing freeze map code

[Andres Freund]

On 2016-07-13 23:06:07 -0700, Andres Freund wrote:
> > +   /* Clear only the all-frozen bit on visibility map if needed */
> > +   if (PageIsAllVisible(BufferGetPage(buffer)) &&
> > +   VM_ALL_FROZEN(relation, block, ))
> > +   {
> > +   visibilitymap_clear_extended(relation, block, vmbuffer,
> > +   
> >  VISIBILITYMAP_ALL_FROZEN);
> > +   }
> > +
> 
> FWIW, I don't think it's worth introducing visibilitymap_clear_extended.
> As this is a 9.6 only patch, i think it's better to change
> visibilitymap_clear's API.

Besides that easily fixed issue, the code also has the significant issue
that it's only performing the the visibilitymap processing in the
BLK_NEEDS_REDO case. But that's not ok, because both in the BLK_RESTORED
and the BLK_DONE cases the visibilitymap isn't guaranteed (or even
likely in the former case) to have been updated.

I think we have two choices how to deal with that: First, we can add a
new flags variable to xl_heap_lock similar to
xl_heap_insert/update/... and bump page magic, or we can squeeze the
information into infobits_set.  The latter seems fairly ugly, and
fragile to me; so unless somebody protests I'm going with the former. I
think due to padding the additional byte doesn't make any size
difference anyway.

Regards,

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] visibilitymap_clear()s in vacuumlazy.c aren't WAL logged

[Andres Freund]

Hi,

The $subject says it all. Am I missing something, or is that not ok?
Now, these branches should never be hit, but it surely isn't good that
the corruption will persist on a primary, after it's explicitly been
fixed on the standby.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Reviewing freeze map code

[Andres Freund]

On 2016-07-14 20:53:07 -0700, Andres Freund wrote:
> On 2016-07-13 23:06:07 -0700, Andres Freund wrote:
> > won't enter the branch, because HEAP_XMAX_LOCK_ONLY won't be set.  Which
> > will leave t_ctid and HEAP_HOT_UPDATED set differently on the master and
> > standby / after crash recovery.   I'm failing to see any harmful
> > consequences right now, but differences between master and standby are a bad
> > thing.
> 
> I think it's actually critical, because HEAP_HOT_UPDATED /
> HEAP_XMAX_LOCK_ONLY are used to terminate ctid chasing loops (like
> heap_hot_search_buffer()).

I've pushed a quite heavily revised version of the first patch to
9.1-master. I manually verified using pageinspect, gdb breakpoints and a
standby that xmax, infomask etc are set correctly (leading to finding
a4d357bf).  As there's noticeable differences, especially 9.2->9.3,
between versions, I'd welcome somebody having a look at the commits.

Regards,

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Version number for pg_control

[Tom Lane]

I wrote:
> David Steele  writes:
>> Maybe this would affect pg_controldata or other supporting utilities but
>> the server itself should not be affected since it also checks the
>> catalog version.

> Right, that version number exists mostly for the benefit of pg_controldata
> and allied utilities.  You would get a CRC failure in any case when trying
> to go between inconsistent notions of what pg_control contains, but the
> version number is supposed to help you figure out why that happened.
> As things stand, though, it'd only mislead you.

Also notice that the server itself uses that heuristic to try to be
helpful about the reason for a pg_control read failure: it detects
PG_CONTROL_VERSION mismatch first, then checks CRC, then checks catversion
(see ReadControlFile(), which even goes to the trouble of trying to
diagnose endian issues this way).  So the users-eye view of the problem
here is that starting a 9.5 or 9.6 server against a 9.4 pg_control file
will tell you that there's a checksum problem, not that the file is the
wrong version.

The value of getting this right was shown only today:
https://www.postgresql.org/message-id/6f746a21-ccfe-d736-57cf-04e3f87fc...@wintek.com
where we'd have had a heckuva harder time diagnosing what was up
with a less on-point error message.

Like Alvaro, I was on the fence about whether it is worth changing now;
but this consideration makes me think that it is.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Version number for pg_control

[David Steele]

On 7/15/16 6:13 PM, Alvaro Herrera wrote:
> David Steele wrote:
>> On 7/15/16 5:47 PM, Alvaro Herrera wrote:
> 
>>> I can't quite make up my mind about it.  It seems pointless to change
>>> it now, but at the same time it seems wrong to let it continue to be
>>> unchanged from 9.4.
>>>
>>> I slightly lean towards changing it in 9.6.
>>
>> +1 for changing it.  However, I don't think it's such a big deal since
>> each version since 8.3 (at least) has had a unique catalog version.
>>
>> Maybe this would affect pg_controldata or other supporting utilities but
>> the server itself should not be affected since it also checks the
>> catalog version.
> 
> I didn't verify pg_resetxlog behavior, but hypothetically running 9.4's
> on a 9.5 installation would result in a broken pg_control file.

Yuck.  I think of the utilities as read-only but there are obviously
some notable exceptions.

So +2 for this change.  Why propagate that mess into the future?

-- 
-David
da...@pgmasters.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Version number for pg_control

[Tom Lane]

David Steele  writes:
> +1 for changing it.  However, I don't think it's such a big deal since
> each version since 8.3 (at least) has had a unique catalog version.

> Maybe this would affect pg_controldata or other supporting utilities but
> the server itself should not be affected since it also checks the
> catalog version.

Right, that version number exists mostly for the benefit of pg_controldata
and allied utilities.  You would get a CRC failure in any case when trying
to go between inconsistent notions of what pg_control contains, but the
version number is supposed to help you figure out why that happened.
As things stand, though, it'd only mislead you.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Version number for pg_control

[David Steele]

On 7/15/16 5:47 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> While researching a pgsql-general question, I noticed that commit
>> 73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields
>> to pg_control without bothering to touch PG_CONTROL_VERSION.  Thus,
>> PG_CONTROL_VERSION is still "942" even though the file contents
>> are not at all compatible with 9.4.
> 
> Oh crap :-(
> 
>> It's way too late to do anything about this in 9.5.  I wonder though
>> if we should advance PG_CONTROL_VERSION now, presumably to "960",
>> so that at least as of 9.6 the format is correctly distinguished
>> from the 9.4-era format.  Or will that just make things even more
>> confusing, given that 9.5 is what it is?
> 
> I can't quite make up my mind about it.  It seems pointless to change
> it now, but at the same time it seems wrong to let it continue to be
> unchanged from 9.4.
> 
> I slightly lean towards changing it in 9.6.

+1 for changing it.  However, I don't think it's such a big deal since
each version since 8.3 (at least) has had a unique catalog version.

Maybe this would affect pg_controldata or other supporting utilities but
the server itself should not be affected since it also checks the
catalog version.

-- 
-David
da...@pgmasters.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Regression tests vs existing users in an installation

[Tom Lane]

We've talked before about how the regression tests should be circumspect
about what role names they create/drop, so as to avoid possibly blowing
up an installation's existing users during "make installcheck".  In
particular I believe there was consensus that such names should begin
with, or at least include, "regress".  I got around today to instrumenting
CreateRole to see what names we were actually creating, and was quite
depressed as to how thoroughly that guideline is being ignored (see
attached).

I propose to go through the regression tests and fix this (in HEAD only).
However, there's one place where it's not so easy to just substitute a
different name, because rolenames.sql is intentionally doing this:

CREATE ROLE "Public";
CREATE ROLE "None";
CREATE ROLE "current_user";
CREATE ROLE "session_user";
CREATE ROLE "user";

in order to test whether we properly distinguish role-related keywords
from quoted identifiers.  Obviously, modifying these would defeat the
point of the test.

One could certainly argue that these are safe enough because nobody would
ever create real roles by those names anyway.  I'm not very comfortable
with that though; if we believe that, why did we go to the trouble of
making sure these cases work?

What I'm inclined to do with this is to reduce the test to be something
like

BEGIN;
CREATE ROLE "Public";
CREATE ROLE "None";
CREATE ROLE "current_user";
CREATE ROLE "session_user";
CREATE ROLE "user";
ROLLBACK;

with maybe a couple of ALTERs and GRANTs inside the transaction to verify
that the names can be referenced as well as created.  This would be safe
against modifying any conflicting existing users; the only bad consequence
would be a phony failure of the test.

I thought about trying to preserve all the existing test cases while still
keeping these roles inside a transaction, by inserting savepoints around
the intentional failures.  But there are enough intentional failures in
rolenames.sql that that would be really tedious.  The existing test cases
seem enormously duplicative to me anyway, so I think a fairly short
transaction with a few tests would be sufficient to cover this territory.

A more aggressive answer would be to decide we don't need these test cases
at all and drop them.  An advantage of that is that then we could
configure some buildfarm animal to fail the next time somebody ignores
the "test role names should contain 'regress'" rule.

Comments?

regards, tom lane


LOG:  created role tablespace_testuser1
LOG:  created role tablespace_testuser2
LOG:  created role regtestrole
LOG:  created role regress_rol_op1
LOG:  created role regress_rol_op3
LOG:  created role regress_rol_op4
LOG:  created role regress_rol_op5
LOG:  created role regress_rol_op6
LOG:  created role regression_reindexuser
LOG:  created role regtest_unpriv_user
LOG:  created role test_def_superuser
LOG:  created role test_superuser
LOG:  created role Public
LOG:  created role None
LOG:  created role current_user
LOG:  created role session_user
LOG:  created role user
LOG:  created role testrol0
LOG:  created role testrolx
LOG:  created role testrol2
LOG:  created role testrol1
LOG:  created role test_def_inherit
LOG:  created role test_inherit
LOG:  created role test_def_createrole
LOG:  created role test_createrole
LOG:  created role test_def_createdb
LOG:  created role test_createdb
LOG:  created role test_def_role_canlogin
LOG:  created role test_role_canlogin
LOG:  created role test_def_user_canlogin
LOG:  created role test_user_canlogin
LOG:  created role test_def_replication
LOG:  created role test_replication
LOG:  created role tu1
LOG:  created role tr1
LOG:  created role tg1
LOG:  created role test_def_bypassrls
LOG:  created role test_bypassrls
LOG:  created role view_user1
LOG:  created role view_user2
LOG:  created role selinto_user
LOG:  created role regtest_addr_user
LOG:  created role regress_rls_alice
LOG:  created role regress_rls_bob
LOG:  created role regress_rls_carol
LOG:  created role regress_rls_exempt_user
LOG:  created role regress_rls_group1
LOG:  created role regress_rls_group2
LOG:  created role regress_rol_lock1
LOG:  created role regressuser1
LOG:  created role regressuser2
LOG:  created role regressuser3
LOG:  created role regressuser4
LOG:  created role regressuser5
LOG:  created role regressgroup1
LOG:  created role regressgroup2
LOG:  created role seclabel_user1
LOG:  created role seclabel_user2
LOG:  created role schemauser1
LOG:  created role schemauser2
LOG:  renamed role schemauser2 to schemauser_renamed
LOG:  created role locktable_user
LOG:  created role regress_rls_eve
LOG:  created role regress_rls_frank
LOG:  created role regress_rls_dob_role1
LOG:  created role regress_rls_dob_role2
LOG:  created role regress_user_mvtest
LOG:  created role regtest_alter_user3
LOG:  created role regtest_alter_user2
LOG:  created role regtest_alter_user1
LOG:  created role regtest_alter_user
LOG:  created role regtest_alter_user5
LOG:  created 

Re: [HACKERS] Version number for pg_control

[Alvaro Herrera]

David Steele wrote:
> On 7/15/16 5:47 PM, Alvaro Herrera wrote:

> > I can't quite make up my mind about it.  It seems pointless to change
> > it now, but at the same time it seems wrong to let it continue to be
> > unchanged from 9.4.
> > 
> > I slightly lean towards changing it in 9.6.
> 
> +1 for changing it.  However, I don't think it's such a big deal since
> each version since 8.3 (at least) has had a unique catalog version.
> 
> Maybe this would affect pg_controldata or other supporting utilities but
> the server itself should not be affected since it also checks the
> catalog version.

I didn't verify pg_resetxlog behavior, but hypothetically running 9.4's
on a 9.5 installation would result in a broken pg_control file.

-- 
Álvaro Herrerahttp://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-hackers

Re: [HACKERS] Version number for pg_control

[Alvaro Herrera]

Tom Lane wrote:
> While researching a pgsql-general question, I noticed that commit
> 73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields
> to pg_control without bothering to touch PG_CONTROL_VERSION.  Thus,
> PG_CONTROL_VERSION is still "942" even though the file contents
> are not at all compatible with 9.4.

Oh crap :-(

> It's way too late to do anything about this in 9.5.  I wonder though
> if we should advance PG_CONTROL_VERSION now, presumably to "960",
> so that at least as of 9.6 the format is correctly distinguished
> from the 9.4-era format.  Or will that just make things even more
> confusing, given that 9.5 is what it is?

I can't quite make up my mind about it.  It seems pointless to change
it now, but at the same time it seems wrong to let it continue to be
unchanged from 9.4.

I slightly lean towards changing it in 9.6.

-- 
Álvaro Herrerahttp://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-hackers

Re: [HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

[Andres Freund]

On 2016-07-15 17:43:44 -0400, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2016-07-15 17:23:57 -0400, Alvaro Herrera wrote:
> 
> > > Maybe we should change fix_infomask_from_infobits() to reset
> > > HEAP_XMAX_BITS | HEAP_MOVED too (and HEAP_KEYS_UPDATED I suppose), to
> > > avoid doing it in each callsite.
> > 
> > Yea, I was thinking of that as well. But there's code like
> > htup->t_infomask &= ~(HEAP_XMAX_BITS | HEAP_MOVED);
> > htup->t_infomask2 &= ~HEAP_KEYS_UPDATED;
> > if (hot_update)
> > HeapTupleHeaderSetHotUpdated(htup);
> > else
> > HeapTupleHeaderClearHotUpdated(htup);
> > fix_infomask_from_infobits(xlrec->old_infobits_set, 
> > >t_infomask,
> >
> > >t_infomask2);
> > 
> > so I'd rather only clean this up in master.

Well, I think we should move setting hot updated into infomask as well,
then rename fix_infomask_from_infobits to set_infomask_from_infobits and
such. I want to get this fix and the heap_update stuff in now, before
the beta, with time to fix potential fallout. So it's the minimal fix,
if I do it...

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

[Alvaro Herrera]

Andres Freund wrote:
> On 2016-07-15 17:23:57 -0400, Alvaro Herrera wrote:

> > Maybe we should change fix_infomask_from_infobits() to reset
> > HEAP_XMAX_BITS | HEAP_MOVED too (and HEAP_KEYS_UPDATED I suppose), to
> > avoid doing it in each callsite.
> 
> Yea, I was thinking of that as well. But there's code like
>   htup->t_infomask &= ~(HEAP_XMAX_BITS | HEAP_MOVED);
>   htup->t_infomask2 &= ~HEAP_KEYS_UPDATED;
>   if (hot_update)
>   HeapTupleHeaderSetHotUpdated(htup);
>   else
>   HeapTupleHeaderClearHotUpdated(htup);
>   fix_infomask_from_infobits(xlrec->old_infobits_set, 
> >t_infomask,
>  
> >t_infomask2);
> 
> so I'd rather only clean this up in master.

Mumble.  I don't see any way that this would matter, but I don't object
to doing the cleanup in master only.

-- 
Álvaro Herrerahttp://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-hackers

Re: [HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

[Andres Freund]

On 2016-07-15 17:23:57 -0400, Alvaro Herrera wrote:
> Andres Freund wrote:
> 
> > While validating my patch for 
> > http://archives.postgresql.org/message-id/20160714060607.klwgq2qr7egt3zrr%40alap3.anarazel.de
> > I noticed that the standby's infomask still had HEAP_XMAX_INVALID set
> > after replaying a XLOG_HEAP_LOCK record.
> > 
> > That's bad, but not really commonly fatal, because unless prepared
> > transactions are used, locks don't need to be present / valid after
> > crash-recovery. But it's clearly something we need to fix.
> > 
> > Given that it's been this way for ages, it's not a blocker for
> > committing the fix for above URL, but I'll try to get in something today
> > for that as well.  
> 
> Yes, it looks broken, and the consequences for prepared xacts should be
> pretty obvious.  Other than those, I think it's pretty innocuous.

Yea, I can't see anything else right now.


> > Looks like the minimal fix is just to add
> > htup->t_infomask &= ~(HEAP_XMAX_BITS | HEAP_MOVED);
> > htup->t_infomask2 &= ~HEAP_KEYS_UPDATED;
> > to heap_xlog_lock and heap_xlog_lock_updated.
> 
> Maybe we should change fix_infomask_from_infobits() to reset
> HEAP_XMAX_BITS | HEAP_MOVED too (and HEAP_KEYS_UPDATED I suppose), to
> avoid doing it in each callsite.

Yea, I was thinking of that as well. But there's code like
htup->t_infomask &= ~(HEAP_XMAX_BITS | HEAP_MOVED);
htup->t_infomask2 &= ~HEAP_KEYS_UPDATED;
if (hot_update)
HeapTupleHeaderSetHotUpdated(htup);
else
HeapTupleHeaderClearHotUpdated(htup);
fix_infomask_from_infobits(xlrec->old_infobits_set, 
>t_infomask,
   
>t_infomask2);

so I'd rather only clean this up in master.

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

[Tom Lane]

I wrote:
> Etsuro Fujita  writes:
>> Here is a patch for that redesign proposed by you; reverts commits  
>> fbe5a3fb73102c2cfec114a67943f4474383 and  
>> 5d4171d1c70edfe3e9be1de9e66603af28e3afe1, adds changes for that redesign  
>> to the core, and adjusts the postgres_fdw code to that changes.  Also, I  
>> rearranged the postgres_fdw regression tests to match that changes.

> OK, I'll review this later today.

Pushed, after fooling around with it some more so that it would cover the
case we discussed where the join could be allowed if we restrict the plan
to be executed by the owner of a view used in the query.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

[Alvaro Herrera]

Andres Freund wrote:

> While validating my patch for 
> http://archives.postgresql.org/message-id/20160714060607.klwgq2qr7egt3zrr%40alap3.anarazel.de
> I noticed that the standby's infomask still had HEAP_XMAX_INVALID set
> after replaying a XLOG_HEAP_LOCK record.
> 
> That's bad, but not really commonly fatal, because unless prepared
> transactions are used, locks don't need to be present / valid after
> crash-recovery. But it's clearly something we need to fix.
> 
> Given that it's been this way for ages, it's not a blocker for
> committing the fix for above URL, but I'll try to get in something today
> for that as well.  

Yes, it looks broken, and the consequences for prepared xacts should be
pretty obvious.  Other than those, I think it's pretty innocuous.

> Looks like the minimal fix is just to add
>   htup->t_infomask &= ~(HEAP_XMAX_BITS | HEAP_MOVED);
>   htup->t_infomask2 &= ~HEAP_KEYS_UPDATED;
> to heap_xlog_lock and heap_xlog_lock_updated.

Maybe we should change fix_infomask_from_infobits() to reset
HEAP_XMAX_BITS | HEAP_MOVED too (and HEAP_KEYS_UPDATED I suppose), to
avoid doing it in each callsite.

-- 
Álvaro Herrerahttp://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-hackers

Re: [HACKERS] dumping database privileges broken in 9.6

[Stephen Frost]

* Noah Misch (n...@leadboat.com) wrote:
> On Sat, Jul 09, 2016 at 12:55:33AM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > This PostgreSQL 9.6 open item is past due for your status update.  Kindly 
> > > send
> > > a status update within 24 hours, and include a date for your subsequent 
> > > status
> > > update.  Refer to the policy on open item ownership:
> > > http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com
> > 
> > Unfortunately, not going to make any further progress on this tonight or
> > over the weekend as I'm going to be out of town.  I believe I've
> > convinced myself that adding a template1 entry to pg_init_privs will be
> > both sufficient and produce the correct results, along with adjusting
> > the query in pg_dumpall to join through it.  Will provide an update on
> > Monday.
> 
> This PostgreSQL 9.6 open item is long past due for your status update.  Kindly
> send a status update within 24 hours, and include a date for your subsequent
> status update.  (Your Tuesday posting lacked a date.)

Yeah, I realized that tablespaces have the same issue and have updated
the patch to address them as well, in the same way.

Going through and doing testing now.  Unfortunately, it doesn't look
like adding in testing of tablespaces into the TAP tests would be very
easy (the only TAP test that deals with tablespaces that I found was
pg_basebackup and that looks rather grotty..), so I'm not planning to do
that, at least not at this time.

As such, I'm planning to commit the patch with the fix+regression test
for database ACLs and the fix for tablespace ACLs either later today
or tomorrow.

Thanks!

Stephen


signature.asc
Description: Digital signature

[HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

[Andres Freund]

Hi,

While validating my patch for 
http://archives.postgresql.org/message-id/20160714060607.klwgq2qr7egt3zrr%40alap3.anarazel.de
I noticed that the standby's infomask still had HEAP_XMAX_INVALID set
after replaying a XLOG_HEAP_LOCK record.

That's bad, but not really commonly fatal, because unless prepared
transactions are used, locks don't need to be present / valid after
crash-recovery. But it's clearly something we need to fix.

Given that it's been this way for ages, it's not a blocker for
committing the fix for above URL, but I'll try to get in something today
for that as well.  Looks like the minimal fix is just to add
htup->t_infomask &= ~(HEAP_XMAX_BITS | HEAP_MOVED);
htup->t_infomask2 &= ~HEAP_KEYS_UPDATED;
to heap_xlog_lock and heap_xlog_lock_updated.

Regards,

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sslmode=require fallback

[Andrew Dunstan]

On 07/15/2016 09:55 AM, Tom Lane wrote:


I'm inclined to think that a better answer than changing libpq's behavior
is to encourage DBAs to specify "hostssl" in pg_hba.conf for all external
connections.



Do those packagers who install dummy certificates and turn SSL on also 
change their pg_hba.conf.sample files to use hostssl?. That could go a 
long way towards encouraging people.


cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[Матвеев Алексей]

Hi

>What I know about Oracle, PL/SQL, Java - all is executed as outprocess calls. 
>I am sure, so PL doesn't share process with SQL engine there

You are highly not correct. 
Sorry, I will answer more when i come to work. 

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[Pavel Stehule]

2016-07-15 19:57 GMT+02:00 Матвеев Алексей :

> Hi
>
> >What I know about Oracle, PL/SQL, Java - all is executed as outprocess
> calls. I am sure, so PL doesn't share process with SQL engine there
>
> You are highly not correct.
> Sorry, I will answer more when i come to work.


 https://sqlmdx.net/2014/09/30/measuring-context-switches/

Regards

Pavel

Re: [HACKERS] One process per session lack of sharing

[Pavel Stehule]

2016-07-15 18:43 GMT+02:00 james :

> On 15/07/2016 09:28, Craig Ringer wrote:
>
>> I don't think anyone's considering moving from multi-processing to
>> multi-threading in PostgreSQL. I really, really like the protection that
>> the shared-nothing-by-default process model gives us, among other things.
>>
>> As I understand it, the main issue is that it is hard to integrate
> extensions that use heavyweight runtimes and are focussed on isolation
> within a virtual machine.  Its not just
>
> Perhaps it would be possible for the postmaster (or a delegate process) to
> host such a runtime, and find a way for a user process that wants to use
> such a runtime to communicate with it, whether by copying function
> parameters over RPC or by sharing some of its address space explicitly to
> the runtime to operate on directly.
>
> Such a host delegate process could be explicitly built with multithread
> support and not 'infect' the rest of the code with its requirements.
>
> Using granular RPC is nice for isolation but I am concerned that the
> latencies might be high.


What I know about Oracle, PL/SQL, Java - all is executed as outprocess
calls. I am sure, so PL doesn't share process with SQL engine there

Regards

Pavel


>
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Re: [HACKERS] One process per session lack of sharing

[james]

On 15/07/2016 09:28, Craig Ringer wrote:
I don't think anyone's considering moving from multi-processing to 
multi-threading in PostgreSQL. I really, really like the protection 
that the shared-nothing-by-default process model gives us, among other 
things.


As I understand it, the main issue is that it is hard to integrate 
extensions that use heavyweight runtimes and are focussed on isolation 
within a virtual machine.  Its not just


Perhaps it would be possible for the postmaster (or a delegate process) 
to host such a runtime, and find a way for a user process that wants to 
use such a runtime to communicate with it, whether by copying function 
parameters over RPC or by sharing some of its address space explicitly 
to the runtime to operate on directly.


Such a host delegate process could be explicitly built with multithread 
support and not 'infect' the rest of the code with its requirements.


Using granular RPC is nice for isolation but I am concerned that the 
latencies might be high.





--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pgbench - allow to store select results into variables

[Fabien COELHO]

Hello again,


I'd be okay with

SELECT 1, 2 \into one two
SELECT 3 \into three


Here is a v2 with more or less this approach, although \into does not end 
the query, but applies to the current or last sql command. A query is 
still terminated with a ";".


Now it handles things like :

  -- standard sql command
  SELECT balance FROM bank WHERE id=1;
  \into balance

  -- compound sql command, three == 3.
  SELECT 1, 2 \; SELECT 3 ;
  \into three

  -- compound query with 2 selects & 3 variables
  SELECT i \into one
FROM generate_series(1, 1) AS i \;
  SELECT i+1, i+2 \into two three
FROM generate_series(1, 1) AS i ;


I had to add a few lines in psql scanner to count "\;", so the parsing 
logic is a little more complicated than before.


--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index f3afedb..cca2cc2 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -809,6 +809,30 @@ pgbench  options  dbname
   
 
   
+   
+
+ \into var1 [var2 ...]
+
+
+
+ 
+  Stores the first fields of the resulting row from the current or preceding
+  SELECT command into these variables.
+  The queries must yield exactly one row and the number of provided
+  variables must be less than the total number of columns of the results.
+  This meta command does not end the current SQL command.
+ 
+
+ 
+  Example:
+
+SELECT abalance \into abalance
+  FROM pgbench_accounts WHERE aid=5432;
+
+ 
+
+   
+

 
  \set varname expression
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 87fb006..667b63c 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -302,11 +302,14 @@ static const char *QUERYMODE[] = {"simple", "extended", "prepared"};
 
 typedef struct
 {
-	char	   *line;			/* text of command line */
+	char	   *line;			/* first line for short display */
+	char	   *lines;			/* full multi-line text of command */
 	int			command_num;	/* unique index of this Command struct */
 	int			type;			/* command type (SQL_COMMAND or META_COMMAND) */
 	int			argc;			/* number of command words */
 	char	   *argv[MAX_ARGS]; /* command word list */
+	int			compound;   /* last compound command (number of \;) */
+	char***intos;   /* per-compound command \into variables */
 	PgBenchExpr *expr;			/* parsed expression, if needed */
 	SimpleStats stats;			/* time spent in this command */
 } Command;
@@ -1148,6 +1151,107 @@ getQueryParams(CState *st, const Command *command, const char **params)
 		params[i] = getVariable(st, command->argv[i + 1]);
 }
 
+/* read all responses from backend */
+static bool
+read_response(CState *st, char ** intos[])
+{
+	PGresult   *res;
+	int			compound = -1;
+
+	while ((res = PQgetResult(st->con)) != NULL)
+	{
+		compound += 1;
+
+		switch (PQresultStatus(res))
+		{
+		case PGRES_COMMAND_OK: /* non-SELECT commands */
+			if (intos[compound] != NULL)
+			{
+fprintf(stderr,
+		"client %d state %d compound %d: "
+		"cannot apply \\into to non SELECT statement\n",
+		st->id, st->state, compound);
+st->ecnt++;
+return false;
+			}
+		case PGRES_EMPTY_QUERY: /* may be used for testing no-op overhead */
+			break; /* OK */
+
+		case PGRES_TUPLES_OK:
+			if (intos[compound] != NULL)
+			{
+/* store result into variables */
+int ntuples = PQntuples(res),
+	nfields = PQnfields(res),
+	f = 0;
+
+if (ntuples != 1)
+{
+	fprintf(stderr,
+			"client %d state %d compound %d: "
+			"expecting one row, got %d\n",
+			st->id, st->state, compound, ntuples);
+	st->ecnt++;
+	PQclear(res);
+	discard_response(st);
+	return false;
+}
+
+while (intos[compound][f] != NULL && f < nfields)
+{
+	/* store result as a string */
+	if (!putVariable(st, "into", intos[compound][f],
+	 PQgetvalue(res, 0, f)))
+	{
+		/* internal error, should it rather abort? */
+		fprintf(stderr,
+"client %d state %d compound %d: "
+"error storing into var %s\n",
+st->id, st->state, compound, intos[compound][f]);
+		st->ecnt++;
+		PQclear(res);
+		discard_response(st);
+		return false;
+	}
+
+	f++;
+}
+
+if (intos[compound][f] != NULL)
+{
+	fprintf(stderr,
+			"client %d state %d compound %d: missing results"
+			" to fill into variable %s\n",
+			st->id, st->state, compound, intos[compound][f]);
+	st->ecnt++;
+	return false;
+}
+			}
+			break;	/* OK */
+
+		default:
+			/* everything else is unexpected, so probably an error */
+			fprintf(stderr, "client %d aborted in state %d compound %d: %s",
+	st->id, st->state, compound, PQerrorMessage(st->con));
+			st->ecnt++;
+			PQclear(res);
+			discard_response(st);
+			return false;
+		}
+
+		PQclear(res);
+	}
+
+	if (compound == -1)
+	{
+		fprintf(stderr, "client %d state %d: no results\n", st->id, st->state);
+		

[HACKERS] Version number for pg_control

[Tom Lane]

While researching a pgsql-general question, I noticed that commit
73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields
to pg_control without bothering to touch PG_CONTROL_VERSION.  Thus,
PG_CONTROL_VERSION is still "942" even though the file contents
are not at all compatible with 9.4.

It's way too late to do anything about this in 9.5.  I wonder though
if we should advance PG_CONTROL_VERSION now, presumably to "960",
so that at least as of 9.6 the format is correctly distinguished
from the 9.4-era format.  Or will that just make things even more
confusing, given that 9.5 is what it is?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] \timing interval

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut  writes:
> > On 7/13/16 2:06 PM, Corey Huinker wrote:
> >> Time: 3601083.544 ms (1h 0m 1.084s)
> 
> > That works for me, except that the abbreviation for minute is "min".
> 
> Meh ... if we're using one-letter abbreviations for hour and second,
> using three letters for minute seems just arbitrarily inconsistent.
> There is zero possibility that anyone would misunderstand what unit
> the "m" stands for.  See also the typical output of time(1):
> 
> $ time sleep 1
> 
> real0m1.002s
> user0m0.001s
> sys 0m0.002s
> 
> (Well, I guess that's bash's builtin rather than /usr/bin/time,
> but the point stands: "m" is widely accepted in this context.)

Agreed.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] \timing interval

[Tom Lane]

Peter Eisentraut  writes:
> On 7/13/16 2:06 PM, Corey Huinker wrote:
>> Time: 3601083.544 ms (1h 0m 1.084s)

> That works for me, except that the abbreviation for minute is "min".

Meh ... if we're using one-letter abbreviations for hour and second,
using three letters for minute seems just arbitrarily inconsistent.
There is zero possibility that anyone would misunderstand what unit
the "m" stands for.  See also the typical output of time(1):

$ time sleep 1

real0m1.002s
user0m0.001s
sys 0m0.002s

(Well, I guess that's bash's builtin rather than /usr/bin/time,
but the point stands: "m" is widely accepted in this context.)

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] \timing interval

[Peter Eisentraut]

On 7/13/16 2:06 PM, Corey Huinker wrote:
> Time: 71041.022 ms (1m 11.041s)
>  pg_sleep
> --
> 
> (1 row)
> 
> Time: 3601083.544 ms (1h 0m 1.084s)
>  pg_sleep
> --
> 
> (1 row)

That works for me, except that the abbreviation for minute is "min".

-- 
Peter Eisentraut  http://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-hackers

Re: [HACKERS] Documentation fix for CREATE FUNCTION

[Tom Lane]

Albe Laurenz  writes:
> Tom Lane wrote:
>> I believe the reason for forcing pg_temp to the back of the path is to
>> prevent unqualified table names from being captured by pg_temp entries.
>> This risk exists despite the rule against searching pg_temp for functions
>> or operators.  A maliciously named temp table could at least prevent
>> a security definer function from doing what it was supposed to, and
>> could probably hijack control entirely via triggers or rules.
>> 
>> Possibly the documentation should be more explicit about why this is
>> being done, but the example code is good as-is.

> Maybe something like the attached would keep people like me from
> misunderstanding this.

I rewrote this a bit and pushed it.  Thanks for the suggestion!

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ce150e7e0fc1a127fee7933d71f4204a79ecce04

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sslmode=require fallback

[Tom Lane]

Magnus Hagander  writes:
> The entire "prefer" mode is a design flaw, that we unfortunately picked as
> default mode.
> ...
> If you care about encryption, you should pick something else
> (require/verify). If you don't care about encryption, you should pick
> something else (allow, probably) so as not to pay unnecessary overhead.

Yeah.  The problem with going over to any one of those as the built-in
default is that we can't know whether the user cares about encryption
or not; but all the other choices depend on making that value judgment.
"prefer" is surely an ugly compromise, but nonetheless it often manages
to do the right thing for both camps.

I'm inclined to think that a better answer than changing libpq's behavior
is to encourage DBAs to specify "hostssl" in pg_hba.conf for all external
connections.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

[Tom Lane]

Etsuro Fujita  writes:
> On 2016/07/15 11:48, Tom Lane wrote:
>> If we add a mechanism to let us know that the FDW doesn't care, we could
>> relax the requirement for such cases.  I don't have a strong opinion on
>> whether that's worthwhile.  It'd depend in part on how many FDWs there
>> are that don't care, versus those that do; and I have no idea about that.

> So, I'd vote for leaving that for future work if necessary.

Makes sense to me.

> Here is a patch for that redesign proposed by you; reverts commits  
> fbe5a3fb73102c2cfec114a67943f4474383 and  
> 5d4171d1c70edfe3e9be1de9e66603af28e3afe1, adds changes for that redesign  
> to the core, and adjusts the postgres_fdw code to that changes.  Also, I  
> rearranged the postgres_fdw regression tests to match that changes.

OK, I'll review this later today.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

[Michael Paquier]

On Thu, Jul 7, 2016 at 7:51 AM, Stephen Frost  wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> > I'm not sure how common a build without openssl is in the real world 
>> > though.
>> > RPMs, DEBs, Windows installers etc all build with OpenSSL. But we probably
>> > don't want to make it mandatory, no...
>>
>> I don't think that it is this much common to have an enterprise-class
>> build of Postgres without SSL, but each company has always its own
>> reasons, so things could exist.
>
> I agree that it's useful to have the support if PG isn't built with
> OpenSSL for some reason.

OK, I am doing that at the end.

And also while moving on...

On another topic, here are some ideas to extend CREATE/ALTER ROLE to
support SCRAM password directly:
1) protocol PASSWORD value, where protocol is { MD5 | PLAIN | SCRAM }, giving:
CREATE ROLE foorole SCRAM PASSWORD value;
2) PASSWORD (protocol) value.
3) Just add SCRAM PASSWORD
My mind is thinking about 1) as being the cleanest solution as this
does not touch the defaults, which may change a couple of releases
later. Other opinions?

Note that I am also switching password_encryption to an enum, able to
use as values on, off, md5, plain, scram. Of course, on => md5, off =>
plain to preserve the default.
Other things that I am making conservative:
- ENCRYPTED PASSWORD still implies MD5-encrypted password
- UNENCRYPTED PASSWORD still implies plain text password
- PASSWORD used alone depends on the value of password_encryption
So it would be possible to move to scram by default by setting
password_encryption to 'scram'.

Objections are welcome, I am moving into something respecting the
default behavior as much as possible.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[AMatveev]

Hi


> This is true, only when data are immutable and in memory. Elsewhere it is 
> false idea.

For   case   whenthe  server  works  24x7  and you need ability to
fix bugs(or update) on the fly in any app code. It's usual.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[Pavel Stehule]

2016-07-15 14:54 GMT+02:00 :

> Hi
>
>
> > but parallel processing doesn't requires threading support - see
> PostgreSQL 9.6 features.
>
> To   share  dynamic  execution  code between threads much more easy(If
> sharing this code between process is possible).
> There  is  many  other  interaction techniques  between threads which is
> absence between process.
>
>
This is true, only when data are immutable and in memory. Elsewhere it is
false idea.

Regards

Pavel

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

[Etsuro Fujita]

On 2016/07/15 11:48, Tom Lane wrote:

Etsuro Fujita  writes:

One thing I'm not sure about is: should we insist that a join can be
pushed down only if the checkAsUser fields of the relevant RTEs are
equal in the case where user mappings are meaningless to the FDW, like
file_fdw?



If we add a mechanism to let us know that the FDW doesn't care, we could
relax the requirement for such cases.  I don't have a strong opinion on
whether that's worthwhile.  It'd depend in part on how many FDWs there
are that don't care, versus those that do; and I have no idea about that.


So, I'd vote for leaving that for future work if necessary.

Here is a patch for that redesign proposed by you; reverts commits  
fbe5a3fb73102c2cfec114a67943f4474383 and  
5d4171d1c70edfe3e9be1de9e66603af28e3afe1, adds changes for that redesign  
to the core, and adjusts the postgres_fdw code to that changes.  Also, I  
rearranged the postgres_fdw regression tests to match that changes.


Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/expected/postgres_fdw.out
--- b/contrib/postgres_fdw/expected/postgres_fdw.out
***
*** 2053,2207  SELECT t1."C 1" FROM "S 1"."T 1" t1, LATERAL (SELECT DISTINCT t2.c1, t3.c1 FROM
 1
  (10 rows)
  
- -- create another user for permission, user mapping, effective user tests
- CREATE USER view_owner;
- -- grant privileges on ft4 and ft5 to view_owner
- GRANT ALL ON ft4 TO view_owner;
- GRANT ALL ON ft5 TO view_owner;
- -- prepare statement with current session user
- PREPARE join_stmt AS SELECT t1.c1, t2.c1 FROM ft4 t1 LEFT JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
- EXPLAIN (COSTS OFF, VERBOSE) EXECUTE join_stmt;
- QUERY PLAN 
- ---
-  Limit
-Output: t1.c1, t2.c1
-->  Foreign Scan
-  Output: t1.c1, t2.c1
-  Relations: (public.ft4 t1) LEFT JOIN (public.ft5 t2)
-  Remote SQL: SELECT r1.c1, r2.c1 FROM ("S 1"."T 3" r1 LEFT JOIN "S 1"."T 4" r2 ON (((r1.c1 = r2.c1 ORDER BY r1.c1 ASC NULLS LAST, r2.c1 ASC NULLS LAST
- (6 rows)
- 
- EXECUTE join_stmt;
-  c1 | c1 
- +
-  22 |   
-  24 | 24
-  26 |   
-  28 |   
-  30 | 30
-  32 |   
-  34 |   
-  36 | 36
-  38 |   
-  40 |   
- (10 rows)
- 
- -- change the session user to view_owner and execute the statement. Because of
- -- change in session user, the plan should get invalidated and created again.
- -- The join will not be pushed down since the joining relations do not have a
- -- valid user mapping.
- SET SESSION ROLE view_owner;
- EXPLAIN (COSTS OFF, VERBOSE) EXECUTE join_stmt;
- QUERY PLAN
- --
-  Limit
-Output: t1.c1, t2.c1
-->  Sort
-  Output: t1.c1, t2.c1
-  Sort Key: t1.c1, t2.c1
-  ->  Hash Left Join
-Output: t1.c1, t2.c1
-Hash Cond: (t1.c1 = t2.c1)
-->  Foreign Scan on public.ft4 t1
-  Output: t1.c1, t1.c2, t1.c3
-  Remote SQL: SELECT c1 FROM "S 1"."T 3"
-->  Hash
-  Output: t2.c1
-  ->  Foreign Scan on public.ft5 t2
-Output: t2.c1
-Remote SQL: SELECT c1 FROM "S 1"."T 4"
- (16 rows)
- 
- RESET ROLE;
- DEALLOCATE join_stmt;
- CREATE VIEW v_ft5 AS SELECT * FROM ft5;
- -- change owner of v_ft5 to view_owner so that the effective user for scan on
- -- ft5 is view_owner and not the current user.
- ALTER VIEW v_ft5 OWNER TO view_owner;
- -- create a public user mapping for loopback server
- -- drop user mapping for current_user.
- DROP USER MAPPING FOR CURRENT_USER SERVER loopback;
- CREATE USER MAPPING FOR PUBLIC SERVER loopback;
- -- different effective user for permission check, but same user mapping for the
- -- joining sides, join pushed down, no result expected.
- PREPARE join_stmt AS SELECT t1.c1, t2.c1 FROM ft5 t1 JOIN v_ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 100 LIMIT 10;
- EXPLAIN (COSTS false, VERBOSE) EXECUTE join_stmt;
-   QUERY PLAN  
- --
-  Limit
-Output: t1.c1, ft5.c1
-->  Foreign Scan
-  Output: t1.c1, ft5.c1
-  Relations: (public.ft5 t1) INNER JOIN (public.ft5)
-  Remote SQL: SELECT r1.c1, r6.c1 FROM ("S 1"."T 4" r1 INNER JOIN "S 1"."T 4" r6 ON (((r1.c1 

Re: [HACKERS] One process per session lack of sharing

[AMatveev]

Hi


> but parallel processing doesn't requires threading support - see PostgreSQL 
> 9.6 features.

To   share  dynamic  execution  code between threads much more easy(If sharing 
this code between process is possible).
There  is  many  other  interaction techniques  between threads which is
absence between process.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[AMatveev]

Hi


> If amatveev (username, unsure of full name) wants to improve
> PL/PgSQL performance and the ability of a JVM to share resources
> between backends, then it would be more productive to focus on that than on 
> threading.

Note, I've statred this post with
https://www.postgresql.org/message-id/flat/409604420.2016071532%40bitec.ru#409604420.2016071...@bitec.ru

Oracle: about 5M
MSSqlServer: about 4M
postgreSql: about 160М


It's 11K loc of pgSql.

And our code base is more than 4000k(for pgSql) lines of code.




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[Pavel Stehule]

2016-07-15 13:25 GMT+02:00 :

> Hi
>
>
> > Can be nice, if we can help to all Oracle users - but it is not
> > possible in this world :( - there is lot of barriers - threading is
> > only one, second should be different design of PL/SQL - it is based
> > on out processed, next can be libraries, JAVA integration, and lot
> > of others. I believe so lot of users can be simple migrated, NTT has
> > statistics - 60% is migrated just with using Orafce. But still there
> > will be 10% where migration is not possible without significant
> > refactoring.
>
> The most of our customers now use oracle enterprise edition.
> You can know better how important this is.
>
> But I agree with you that in other cases we can use PostgreSql.
> We  can  use  postgreSql  with some disadvantages of pgBouncer anywhare
> where  the  scalability  is not main risk.(Such customers usually don't
> buy Enterprise)
>
> >I don't believe so is cheaper to modify Postgres to
> > support threads than modify some Oracle applications.
>
> The key is Scaling.
> Some parallels processing just can not be divorced from data without
> reducing performance.
> It  very  difficult  question  would  be  it  possible  at  all to get
> comparable performance at application server for such cases.
> If we "inject" applications server to postgreSql for that scalability and
> functionality we need multithreading.
>

but parallel processing doesn't requires threading support - see PostgreSQL
9.6 features.

I am not sure, but I am thinking so PL/SQL is based on processed and not on
threads too. So maybe this discussion is little bit out, because we use
different terms.

Regards

Pavel



>
> If customization for every project is not big.
> It's may be tuned. But from some point the tuning is not profitable.
> (The database works in 24x7 and we need the ability to fix bugs on the fly)
> So If for some reason we would start to use postgresql.
> There is always a question what to choose funcionality or scalability.
> And usually our customers need both.
>
> >I don't believe so is cheaper
> For us it's may be not cheaper. It's just imposible.
>
>

Re: [HACKERS] Documentation fix for CREATE FUNCTION

[Albe Laurenz]

Tom Lane wrote:
> Albe Laurenz  writes:
>> I just noticed that the documentation for CREATE FUNCTION still mentions
>> that the temporary namespace is searched for functions even though that
>> has been removed with commit aa27977.
> 
> The example you propose to correct was introduced by that same commit,
> which should make you think twice about whether it really was invalidated
> by that commit.

Yes, I wondered about that.

> I believe the reason for forcing pg_temp to the back of the path is to
> prevent unqualified table names from being captured by pg_temp entries.
> This risk exists despite the rule against searching pg_temp for functions
> or operators.  A maliciously named temp table could at least prevent
> a security definer function from doing what it was supposed to, and
> could probably hijack control entirely via triggers or rules.
> 
> Possibly the documentation should be more explicit about why this is
> being done, but the example code is good as-is.

Maybe something like the attached would keep people like me from
misunderstanding this.

Yours,
Laurenz Albe


0001-Improve-example-in-CREATE-FUNCTION-documentation.patch
Description: 0001-Improve-example-in-CREATE-FUNCTION-documentation.patch

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[AMatveev]

Hi


> Can be nice, if we can help to all Oracle users - but it is not
> possible in this world :( - there is lot of barriers - threading is
> only one, second should be different design of PL/SQL - it is based
> on out processed, next can be libraries, JAVA integration, and lot
> of others. I believe so lot of users can be simple migrated, NTT has
> statistics - 60% is migrated just with using Orafce. But still there
> will be 10% where migration is not possible without significant
> refactoring.

The most of our customers now use oracle enterprise edition.
You can know better how important this is.

But I agree with you that in other cases we can use PostgreSql.
We  can  use  postgreSql  with some disadvantages of pgBouncer anywhare
where  the  scalability  is not main risk.(Such customers usually don't
buy Enterprise)

>I don't believe so is cheaper to modify Postgres to
> support threads than modify some Oracle applications.

The key is Scaling.
Some parallels processing just can not be divorced from data without reducing 
performance.
It  very  difficult  question  would  be  it  possible  at  all to get
comparable performance at application server for such cases.
If we "inject" applications server to postgreSql for that scalability and 
functionality we need multithreading.

If customization for every project is not big.
It's may be tuned. But from some point the tuning is not profitable.
(The database works in 24x7 and we need the ability to fix bugs on the fly)
So If for some reason we would start to use postgresql.
There is always a question what to choose funcionality or scalability.
And usually our customers need both.

>I don't believe so is cheaper
For us it's may be not cheaper. It's just imposible.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[Craig Ringer]

On 15 July 2016 at 18:05, Pavel Stehule  wrote:


> There is only few use cases - mostly related to Oracle emulation when
> multi threading is necessary - and few can be solved better - PLpgSQL to C
> compilation and similar techniques.
>
>
Right.

If amatveev (username, unsure of full name) wants to improve PL/PgSQL
performance and the ability of a JVM to share resources between backends,
then it would be more productive to focus on that than on threading.

As for "fixing" the FAQ... for the great majority of people the FAQ entry
on memory use is accurate. Sure, if you load a JVM into each backend and
load a bunch of cached data in it, you'll get bad memory use. So don't do
that. You're not measuring PostgreSQL, you're measuring
PostgreSQL-plus-my-JVM-extension. Why does it use so much memory? 'cos it
loads a whole bunch of stuff into each backend.

Now, there are other cases where individual PostgreSQL backends use lots of
memory. But that FAQ entry refers to the common misconception that each
PostgreSQL process's reported memory use is the actual system memory it
uses. That isn't the case because most systems account badly for shared
memory, and it confuses a lot of people. The FAQ entry doesn't need fixing.

Maybe the FAQ entry needs rewording to qualify it so it says that "in most
cases" it's just shared memory mis-accounting. But that's about it.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: [HACKERS] One process per session lack of sharing

[Pavel Stehule]

2016-07-15 12:20 GMT+02:00 :

> Hi
>
>
> > I disagree - there is lot of possible targets with much higher
> > benefits - columns storage, effective execution - compiled
> > execution, implementation of temporal databases, better support for
> > dynamic structures, better support for XML, JSON, integration of
> connection pooling, ...
> Off course  the  task is different so optimal configuration is different
> too.
> So the best balance between process per thread can change.
> But now he is in one extreme point.
>
>
> > There is only few use cases - mostly related to Oracle emulation
> It's few cases for one and it's most cases for others.
> > when multi threading is necessary - and few can be solved better -
> > PLpgSQL to C compilation and similar techniques.
> It's few cases for one and it's most cases for others.
> In our cases we just buy oracle and it's would be cheeper.
> Off  course  if  our customers for some reason would agree to pay  for that
> technique. We have nothing against.
>
> > The organization of work is hard, but pretty harder is doing this
> > work - and doing it without impact on current code base, current
> > users. MySQL is thread based database - is better than Postgres, or
> > there is more users migrated from Orace? Not.
>
> We want to decide our task by PostgreSql as easy as by Oracle.
> So you can say  You should buy oracle and You will be right.
>

Can be nice, if we can help to all Oracle users - but it is not possible in
this world :( - there is lot of barriers - threading is only one, second
should be different design of PL/SQL - it is based on out processed, next
can be libraries, JAVA integration, and lot of others. I believe so lot of
users can be simple migrated, NTT has statistics - 60% is migrated just
with using Orafce. But still there will be 10% where migration is not
possible without significant refactoring. I don't believe so is cheaper to
modify Postgres to support threads than modify some Oracle applications.

The threading for Postgres is not small projects - it can require hundreds
man days.



>
> I'm just interested if this is the position of the majority.
>
>
sure - it is my personal opinion.

Regards

Pavel

Re: [HACKERS] BUG #14245: Segfault on weird to_tsquery

[Teodor Sigaev]

The above-described topic is currently a PostgreSQL 9.6 open item.  Teodor,

I'm working on it now and believe that fix will be published  today.


since you committed the patch believed to have created it, you own this open
item.  If some other commit is more relevant or if this does not belong as a
9.6 open item, please let us know.  Otherwise, please observe the policy on
open item ownership[1] and send a status update within 72 hours of this
message.  Include a date for your subsequent status update.  Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping 9.6rc1.  Consequently, I will appreciate your
efforts toward speedy resolution.  Thanks.

[1] 
http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com




--
Teodor Sigaev   E-mail: teo...@sigaev.ru
   WWW: http://www.sigaev.ru/


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[AMatveev]

Hi


> I disagree - there is lot of possible targets with much higher
> benefits - columns storage, effective execution - compiled
> execution, implementation of temporal databases, better support for
> dynamic structures, better support for XML, JSON, integration of connection 
> pooling, ...
Off course  the  task is different so optimal configuration is different too.
So the best balance between process per thread can change.
But now he is in one extreme point.


> There is only few use cases - mostly related to Oracle emulation
It's few cases for one and it's most cases for others.
> when multi threading is necessary - and few can be solved better -
> PLpgSQL to C compilation and similar techniques.
It's few cases for one and it's most cases for others.
In our cases we just buy oracle and it's would be cheeper.
Off  course  if  our customers for some reason would agree to pay  for that
technique. We have nothing against.

> The organization of work is hard, but pretty harder is doing this
> work - and doing it without impact on current code base, current
> users. MySQL is thread based database - is better than Postgres, or
> there is more users migrated from Orace? Not.

We want to decide our task by PostgreSql as easy as by Oracle.
So you can say  You should buy oracle and You will be right.

I'm just interested if this is the position of the majority.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[Pavel Stehule]

2016-07-15 11:29 GMT+02:00 :

> Hi
>
>
>  Is  there  any  plan  to  implement  "session  per  thread" or "shared
>  sessions between thread"?
>
>
> > I'm personally not absolutely opposed to threading, but you'll find
> > it hard to convince anyone it's worth the huge work required to
> > ensure that everything in PostgreSQL is done thread-safely
> It's  clear  for  me, I understand that organizing that work is really very
> hard. It's work for new segment of market in long perspective.
> For   most  open  source  project this is very difficult. In some case
> it may be not possible at all.
>
> But  in the most cases there is proverb: "We make the road by walking on
> it"
>
> It's very important just to start.
>

I disagree - there is lot of possible targets with much higher benefits -
columns storage, effective execution - compiled execution, implementation
of temporal databases, better support for dynamic structures, better
support for XML, JSON, integration of connection pooling, ...

There is only few use cases - mostly related to Oracle emulation when multi
threading is necessary - and few can be solved better - PLpgSQL to C
compilation and similar techniques.

The organization of work is hard, but pretty harder is doing this work -
and doing it without impact on current code base, current users. MySQL is
thread based database - is better than Postgres, or there is more users
migrated from Orace? Not.

Regards

Pavel



>
> And may be the right start is to fix the Faq
>
> https://wiki.postgresql.org/wiki/FAQ#Why_does_PostgreSQL_use_so_much_memory.3F
> >Why does PostgreSQL use so much memory?
> >Despite appearances, this is absolutely normal
> It's not normal. It's "as is". You should use pgBouncer. See "Re:
> [HACKERS] One process per session lack of sharing"
> And it is why
> >there are workloads where it
> >fails badly - and competing database products survive a number of
> >scenarios where we just fall on our face
>
>
> > Er yeah, it really is. It's not just the mechanical changes.
> > It's verifying that everything's correct on all the supported
> > platforms. Ensuring that all the C library stuff we do is
> > thread-safe, all the SSL stuff, etc. Getting rid of all the
> > function-static variable use. Lots more.
> In the most cases the work can be done part by part.
> May be there is such parts. It's not necessary to do everything at once.
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Re: [HACKERS] One process per session lack of sharing

[AMatveev]

Hi


 Is  there  any  plan  to  implement  "session  per  thread" or "shared
 sessions between thread"?


> I'm personally not absolutely opposed to threading, but you'll find
> it hard to convince anyone it's worth the huge work required to
> ensure that everything in PostgreSQL is done thread-safely
It's  clear  for  me, I understand that organizing that work is really very
hard. It's work for new segment of market in long perspective.
For   most  open  source  project this is very difficult. In some case
it may be not possible at all.

But  in the most cases there is proverb: "We make the road by walking on it"

It's very important just to start.

And may be the right start is to fix the Faq
https://wiki.postgresql.org/wiki/FAQ#Why_does_PostgreSQL_use_so_much_memory.3F
>Why does PostgreSQL use so much memory?
>Despite appearances, this is absolutely normal
It's not normal. It's "as is". You should use pgBouncer. See "Re: [HACKERS] One 
process per session lack of sharing"
And it is why
>there are workloads where it
>fails badly - and competing database products survive a number of
>scenarios where we just fall on our face


> Er yeah, it really is. It's not just the mechanical changes.
> It's verifying that everything's correct on all the supported
> platforms. Ensuring that all the C library stuff we do is
> thread-safe, all the SSL stuff, etc. Getting rid of all the
> function-static variable use. Lots more.
In the most cases the work can be done part by part.
May be there is such parts. It's not necessary to do everything at once.




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: [HACKERS] [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

[Dmitriy Sarafannikov]

>I don't really see anything suspicious in the profile. This looks more
>like a kernel scheduler issue than a postgres bottleneck one. It seems
>that somehow using nonblocking IO (started in 9.5) causes scheduling
>issues when pgbouncer is also local.
>
>Could you do perf stat -ddd -a sleep 10 or something during both runs? I
>suspect that the context switch ratios will be quite different.

Perf show that in 9.5 case context switches occurs about 2 times less.
Perf output is attached.

Regards,
Dmitriy Sarafannikov

perf.stat
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] sslmode=require fallback

[Andreas 'ads' Scherbaum]

On 14.07.2016 23:34, Magnus Hagander wrote:



On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane > wrote:

Greg Stark > writes:
> Well what's required to "configure SSL" anyways? If you don't have
> verify-ca set or a root canal cert present then the server just needs a
> certificate -- any certificate. Can the server just cons one up on demand
> (or server startup or initdb)?

Hmm, good old "snake oil certificate" approach.  Yeah, we could probably
have initdb create a cert all the time.  I had memories of this taking
an undue amount of time, but it seems pretty fast on a modern server.


It can still take a very significant amount of time in some virtual
environments, due to lack of entropy. And virtual environments aren't
exactly uncommon these days...


What expire time would you chose for the certificate? One year? Two years?
Which tool is going to re-generate your new cert, once this one expires? 
You don't want to run initdb again ...



Regards,

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One process per session lack of sharing

[Craig Ringer]

On 14 July 2016 at 16:41,  wrote:

> Hi
>
> > On Tue, Jul 12, 2016 at 9:18 AM, Tom Lane  wrote:
> >> amatv...@bitec.ru writes:
> >>> Is  there  any  plan  to  implement  "session  per  thread" or "shared
> >>> sessions between thread"?
> >>...
> >> so
> >> there's not that much motivation to do a ton of work inside the database
> >> to solve it there.
>
> > I agree that there's not really a plan to implement this, but I don't
> > ...
>
> > So, I actually think it would be a good idea to think about this.
>
> I just want to note that converting global variables to  thread-specific
> variables.
>

I don't think anyone's considering moving from multi-processing to
multi-threading in PostgreSQL. I really, really like the protection that
the shared-nothing-by-default process model gives us, among other things.

I'm personally not absolutely opposed to threading, but you'll find it hard
to convince anyone it's worth the huge work required to ensure that
everything in PostgreSQL is done thread-safely, adapt all our logic to
handle thread IDs where we use process IDs, etc. It'd be a massive amount
of work for no practical gain for most users, and a huge reliability loss
in the short to medium term as we ironed out all the bugs.

Where I agreed with you, and where I think Robert sounded like he was
agreeing, was that our current design where we have one executor per user
sessions and can't suspend/resume sessions is problematic.


> It's large work offcourse.
> But it's not seemed to be a ton of work.
>

Er yeah, it really is. It's not just the mechanical changes. It's
verifying that everything's correct on all the supported platforms.
Ensuring that all the C library stuff we do is thread-safe, all the SSL
stuff, etc. Getting rid of all the function-static variable use. Lots more.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Re: [HACKERS] sslmode=require fallback

[Magnus Hagander]

On Fri, Jul 15, 2016 at 5:10 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:

> On 7/13/16 4:11 PM, Robert Haas wrote:
> > On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander 
> wrote:
> >> You would think so.
> >>
> >> The default mode of "prefer" is ridiculous in a lot of ways. If you are
> >> using SSL in any shape or form you should simply not use "prefer".
> That's
> >> really the only answer at this point, unfortunately.
> >
> > Suppose we changed the default to "require".  How crazy would that be?
>
> If we think that that is appropriate, should we not also change the
> default pg_hba.conf to hostssl lines?
>
> I'm not convinced either of these would go over well.
>

It would actually, IMO, make more sense to change the default pg_hba lines
and not change the client settings... But I'm not sure either of those
would go over well.



>
> The original complaint was not actually that "prefer" is a bad default,
> but that in the presence of a root certificate on the client, a
> certificate validation failure falls back to plain text.  That seems
> like a design flaw of the "prefer" mode, no matter whether it is the
> default or not.
>

The entire "prefer" mode is a design flaw, that we unfortunately picked as
default mode.

If it fails *for any reason*, it falls back to plaintext. Thus, you have to
assume it will make a plaintext connection. Thus, it gives you zero
guarantees, so it serves no actual purpose from a security perspective.

it will equally fall back on incompatible SSL configs. Or on a network
hiccup. The presence of the certificate is just one of many different
scenarios where it will fall back.

If you care about encryption, you should pick something else
(require/verify). If you don't care about encryption, you should pick
something else (allow, probably) so as not to pay unnecessary overhead.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [HACKERS] BUG #14245: Segfault on weird to_tsquery

[Noah Misch]

On Tue, Jul 12, 2016 at 05:11:32PM -0400, Tom Lane wrote:
> David Kellum  writes:
> > On Tue, Jul 12, 2016 at 12:42 PM, Tom Lane  wrote:
> >> Note that while crashing is certainly not good, the pre-9.6 behavior
> >> can hardly be called correct either.  What happened to 'a'?
> 
> > 'a' is a stopword, dropped by to_tsquery() as described here:
> 
> Ah!  OK, so it's probably necessary to have a stopword there in order
> to break it.
> 
> BTW, all these variants also crash:
> 
> select to_tsquery('!(a | !b) & c') as tsquery;
> select to_tsquery('!( !b & a) & c') as tsquery;
> select to_tsquery('!( !b | a) & c') as tsquery;

[Action required within 72 hours.  This is a generic notification.]

The above-described topic is currently a PostgreSQL 9.6 open item.  Teodor,
since you committed the patch believed to have created it, you own this open
item.  If some other commit is more relevant or if this does not belong as a
9.6 open item, please let us know.  Otherwise, please observe the policy on
open item ownership[1] and send a status update within 72 hours of this
message.  Include a date for your subsequent status update.  Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping 9.6rc1.  Consequently, I will appreciate your
efforts toward speedy resolution.  Thanks.

[1] 
http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Re: Document that vacuum can't truncate if old_snapshot_threshold >= 0

[Noah Misch]

On Wed, Jul 13, 2016 at 02:14:06PM -0700, Andres Freund wrote:
> That appears to not be mentioned in a comment, the commit message or the
> the docs. I think this definitely needs to be prominently documented.

[Action required within 72 hours.  This is a generic notification.]

The above-described topic is currently a PostgreSQL 9.6 open item.  Kevin,
since you committed the patch believed to have created it, you own this open
item.  If some other commit is more relevant or if this does not belong as a
9.6 open item, please let us know.  Otherwise, please observe the policy on
open item ownership[1] and send a status update within 72 hours of this
message.  Include a date for your subsequent status update.  Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping 9.6rc1.  Consequently, I will appreciate your
efforts toward speedy resolution.  Thanks.

[1] 
http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] dumping database privileges broken in 9.6

[Noah Misch]

On Sat, Jul 09, 2016 at 12:55:33AM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > This PostgreSQL 9.6 open item is past due for your status update.  Kindly 
> > send
> > a status update within 24 hours, and include a date for your subsequent 
> > status
> > update.  Refer to the policy on open item ownership:
> > http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com
> 
> Unfortunately, not going to make any further progress on this tonight or
> over the weekend as I'm going to be out of town.  I believe I've
> convinced myself that adding a template1 entry to pg_init_privs will be
> both sufficient and produce the correct results, along with adjusting
> the query in pg_dumpall to join through it.  Will provide an update on
> Monday.

This PostgreSQL 9.6 open item is long past due for your status update.  Kindly
send a status update within 24 hours, and include a date for your subsequent
status update.  (Your Tuesday posting lacked a date.)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers