On Thu, Apr 6, 2017 at 6:37 AM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 2:42 AM, Ashutosh Bapat
> wrote:
>> Only inner join conditions have equivalence classes associated with
>> those. Outer join conditions create single element equivalence
>> classes. So, we can not associate equivalence cl
On 8 April 2017 at 04:42, Tom Lane wrote:
> I'd be happier with something along the line of
>
> RangeTblEntry *rte;
> ListCell *lc;
>
> /* Should only be applied to base relations that are subqueries */
> Assert(rel->relid > 0);
> rte = planner_rt_fetch(re
... and of course the other functions matching *wal*location*
My thoughts here are that we're already breaking backward
compatibility of these functions for PG10, so thought we might want to
use this as an opportunity to fix the naming a bit more.
I feel that the "location" word not the best choi
On 04/06/2017 07:59 PM, Heikki Linnakangas wrote:
Another thing I'd like some more eyes on, is how this will work with
encodings other than UTF-8. We will now try to normalize the password as
if it was in UTF-8, even if it isn't. That's OK as long as we're
consistent about it, but there is one wo
On Mon, Apr 10, 2017 at 4:02 AM, Bruce Momjian wrote:
> On Sun, Apr 9, 2017 at 07:00:38PM +0200, Magnus Hagander wrote:
> >
> >
> > On Sun, Apr 9, 2017 at 2:32 AM, Bruce Momjian wrote:
> >
> > On Sat, Apr 8, 2017 at 12:50:19PM -0400, Robert Haas wrote:
> > > On Sat, Apr 8, 2017 at 6:39
On 04/10/2017 02:19 AM, Noah Misch wrote:
On Fri, Apr 07, 2017 at 10:28:59AM +0300, Heikki Linnakangas wrote:
On 04/07/2017 08:21 AM, Noah Misch wrote:
Michael shared[1] better pg_hba.conf syntax on 2016-11-05. I agreed[2] with
his framing of the problem and provided two syntax alternatives, o
Right now, VACUUM FULL are not reported in pgstat. That seems bad:ish. I
can see two reasonable ways to proceed:
1. Start reporting VACUUM FULL as regular vacuums, so they count up
vacuum_count and last_vacuum in pg_stat_*_tables.
2. Create a new set of counters for CLUSTER and VACUUM FULL (which
On Wed, Apr 5, 2017 at 6:22 PM, Robert Haas wrote:
> On Thu, Mar 23, 2017 at 4:50 AM, Magnus Hagander
> wrote:
> > One thing we might want to consider around this -- in 10 we have
> > target_session_attrs=read-write (since
> > 721f7bd3cbccaf8c07cad2707826b83f84694832), which will issue a SHOW
>
Hi Yorick,
> should do so on any standby servers first, before applying the changes to
What you actually meant probably was "do so on ALL standby servers
first", right?
--
Best regards,
Aleksander Alekseev
signature.asc
Description: PGP signature
On Sun, Apr 9, 2017 at 6:25 PM, Masahiko Sawada wrote:
> On Sat, Apr 8, 2017 at 8:13 AM, Peter Eisentraut
> wrote:
>> On 4/7/17 01:10, Masahiko Sawada wrote:
>>> It's not critical but it could be problem. So I thought we should fix
>>> it before the PostgreSQL 10 release. If it's not appropriate
On Fri, Apr 7, 2017 at 4:03 PM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> On 04/07/2017 09:58 AM, Tom Lane wrote:
> >> This seems be the same as the 2nd error that was reported back in 2013:
> >> https://www.postgresql.org/message-id/CAJ2%3DPVQcW8UGNnSy%3DOw%
> 3DvUK2zpjowTkzUS
Hi!
There's some ongoing discussion about SCRAM (like this thread
https://www.postgresql.org/message-id/243d8c11-6149-a4bb-0909-136992f74b23%40iki.fi)
but I wanted to open a new thread that covers these topics and other,
more general ones. Here are some thoughts based on my perspectiv
Hi!
There's some ongoing discussion about SCRAM (like this thread
https://www.postgresql.org/message-id/243d8c11-6149-a4bb-0909-136992f74b23%40iki.fi)
but I wanted to open a new thread that covers these topics and other,
more general ones. Here are some thoughts based on my perspectiv
While reviewing extended stats I noticed that it was possible to
create extended stats on many object types, including sequences. I
mentioned that this should be disallowed. Statistics were then changed
to be only allowed on plain tables and materialized views.
This should be relaxed again to allo
> On 10 Apr 2017, at 05:20, Noah Misch wrote:
>
> On Wed, Apr 05, 2017 at 05:02:18PM +0300, Stas Kelvich wrote:
>>> On 27 Mar 2017, at 18:59, Robert Haas wrote:
>>> On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao wrote:
Logical replication worker should call pgstat_report_stat()?
Curre
During my review and time spent working on the functional dependencies
part of extended statistics I wondered what was the use for the
pg_stats_ext view. I was unsure why the length of the serialised
dependencies was useful.
Perhaps we could improve the view, but I'm not all that sure what
value i
This isn't exactly about this particular thread. But I noticed, that
after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
number of conditions to include this relkind. We missed some places in
initial commits and fixed those later. I am wondering whether we
should creates macros c
On 4 April 2017 at 17:10, Maksim Milyutin wrote:
>
> 3. As I noticed early pg_depend table is used for cascade deleting indexes
> on partitioned table and its children. I also use pg_depend to determine
> relationship between parent and child indexes when reindex executes
> recursively on child in
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
- I think channel binding support should be added. SCRAM brings security
improvements over md5 and other simpler digest algorithms. But where it
really shines is together with channel binding. This is the only method
to prevent MITM attacks.
On 2 April 2017 at 07:53, Fabien COELHO wrote:
> Note that this is already available indirectly, as show in the
> documentation.
>
> SELECT some-boolean-expression AS okay \gset
> \if :okay
> \echo boolean expression was true
> \else
> \echo boolean expression was false
> \endif
On Tue, Apr 4, 2017 at 12:10 PM, Maksim Milyutin
wrote:
> 1. I have added a new relkind for local indexes named RELKIND_LOCAL_INDEX
> (literal 'l').
Seems like it should maybe be RELKIND_PARTITIONED_INDEX. There's
nothing particularly "local" about it. I suppose what you're going
for is that it
On 10.04.2017 13:46, Greg Stark wrote:
On 4 April 2017 at 17:10, Maksim Milyutin wrote:
3. As I noticed early pg_depend table is used for cascade deleting indexes
on partitioned table and its children. I also use pg_depend to determine
relationship between parent and child indexes when reindex
Andrew Gierth writes:
> In the discussion with Andres the same point came up for palloc, for
> which I suggested we add something along the lines of:
> #define palloc_object(_type_) (_type_ *) palloc(sizeof(_type_))
> #define palloc_array(_type_, n) (_type_ *) palloc((n) * sizeof(_type_))
I'm fa
Magnus Hagander writes:
> Are these votes for getting rid of both win32.mak and bcc32.mak?
I'm for it.
> If so, count me in for the same :) Want me to do the honors, as it's my
> fault they're in there in the first place?
Sure.
regards, tom lane
--
Sent via pgsql-hac
On Thu, Apr 6, 2017 at 6:50 AM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 8:17 PM, Neha Khatri wrote:
>> The problem here seem to be the change in the max_parallel_workers value
>> while the parallel workers are still under execution. So this poses two
>> questions:
>>
>> 1. From usecase point
Hello, hackers!
==Spatial joins==
Scientific papers from the dawn of R-trees and multidimensional
indexes feature a lot of algorithms for spatial joins.
I.e. you have two sets of geometries s1 and s2, you need to produce
all colliding pairs (p1,p2) where p1 in s1 and p2 in s2. For 2 R-trees
of equ
David Rowley writes:
> On 8 April 2017 at 04:42, Tom Lane wrote:
>> BTW, is it really true that only these two places produce such warnings
>> on MSVC? I see about three dozen uses of PG_USED_FOR_ASSERTS_ONLY in our
>> tree, and I'd have expected all of those places to be causing warnings on
>>
On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Are these votes for getting rid of both win32.mak and bcc32.mak?
>
> I'm for it.
+1.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On 10/04/17 11:02, Masahiko Sawada wrote:
> On Sun, Apr 9, 2017 at 6:25 PM, Masahiko Sawada wrote:
>> On Sat, Apr 8, 2017 at 8:13 AM, Peter Eisentraut
>> wrote:
>>> On 4/7/17 01:10, Masahiko Sawada wrote:
It's not critical but it could be problem. So I thought we should fix
it before th
On Fri, Mar 31, 2017 at 7:43 AM, Amit Langote
wrote:
> Hi,
>
> Last message regarding this was by Robert on the original partitioning thread:
>
> https://www.postgresql.org/message-id/CA%2BTgmoZjGzSM5WwnyapFaw3GxnDLWh7pm8Xiz8_QWQnUQy%3DSCA%40mail.gmail.com
>
> Summary is: We decided in f1b4c771ea7
On 10/04/17 05:20, Michael Paquier wrote:
> On Mon, Apr 10, 2017 at 11:41 AM, Noah Misch wrote:
>> On Thu, Apr 06, 2017 at 02:21:29AM +0900, Fujii Masao wrote:
>>> Both launcher and worker don't handle SIGHUP signal and cannot
>>> reload the configuration. I think that this is a bug. Will add this
On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote:
> I wonder if we shouldn't just do
>
> RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY;
> ListCell *lc;
>
> /* Should only be applied to base relations that are subqueries */
> Assert(rel->relid > 0);
> -#ifdef USE_ASSE
On 10/04/17 07:16, Masahiko Sawada wrote:
> Hi all,
>
> Attached a patch for $subject.
>
> I added this parameter into "Asynchronous Behavior" section of
> "RESOURCE" section. But GUC parameter for subscriber now is written in
> this section, in spite of there is "REPLICATION" section. I think th
Petr Jelinek writes:
> Looks good to me. Just as a note, we'll have to handle this newly
> supported config rereads in the async commit patch where we override
> synchronous_commit GUC, but the config reread will change it back.
Umm ... you're doing what?
There are mechanisms for making local ch
On Mon, Apr 10, 2017 at 9:32 PM, Petr Jelinek
wrote:
> On 10/04/17 07:16, Masahiko Sawada wrote:
>> Hi all,
>>
>> Attached a patch for $subject.
>>
>> I added this parameter into "Asynchronous Behavior" section of
>> "RESOURCE" section. But GUC parameter for subscriber now is written in
>> this se
On 10/04/17 14:40, Tom Lane wrote:
> Petr Jelinek writes:
>> Looks good to me. Just as a note, we'll have to handle this newly
>> supported config rereads in the async commit patch where we override
>> synchronous_commit GUC, but the config reread will change it back.
>
> Umm ... you're doing wha
On 04/07/2017 01:13 AM, Michael Paquier wrote:
On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa
wrote:
I don't see it. The message AuthenticationSASL.String could contain a
CSV of the SCRAM protocols supported. This is specially important to support
channel binding (which is just a
On 04/10/2017 12:43 AM, Michael Paquier wrote:
> On Mon, Apr 10, 2017 at 1:01 PM, Noah Misch wrote:
>> This PostgreSQL 10 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 poli
On Mon, Apr 10, 2017 at 2:07 PM, Michael Paquier
wrote:
> On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> Are these votes for getting rid of both win32.mak and bcc32.mak?
> >
> > I'm for it.
>
> +1.
>
PFA a patch that does this. Did I miss something? :)
--
On Mon, Apr 10, 2017 at 10:17:26AM +0200, Magnus Hagander wrote:
> didn't that that happened in the old docs, but I can use an href filter
> to do it only for docs of versions starting with '1' or saying 'devel'.
>
> That said, doing something like this would probably be cleaner. However,
Petr Jelinek writes:
> On 10/04/17 14:40, Tom Lane wrote:
>> Umm ... you're doing what?
> We are doing:
> + SetConfigOption("synchronous_commit",
> + MySubscription->synccommit ?
> "local" : "off",
> + PGC_BACKEND,
Tom, Robert,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > I would appreciate help from other contributors and committers on this
> > open item; pg_dump is not my strong point. In the absence of such
> > help, I will do my best with it. I will set aside time this week to
> >
Thomas Munro writes:
> Here's a pair of draft patches for review:
Pushed with cosmetic improvements.
I notice that the safe-snapshot code path is not paying attention to
parallel-query cases, unlike the lock code path. I'm not sure how
big a deal that is...
regards, tom
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> While I admit that I've not been paying close attention to the whole
>> table partitioning business, I wonder whether we have any clearly written
>> down specification about (a) how much partition member tables are allowed
>> to dev
Hi Rahila,
With your latest patch:
Consider a case when a table is partitioned on a boolean key.
Even when there are existing separate partitions for 'true' and
'false', still default partition can be created.
I think this should not be allowed.
Consider following case:
postgres=# CREATE
Hi Rahila,
I tried to review the code, and here are some of my early comments:
1.
When I configure using "-Werror", I see unused variable in function
DefineRelation:
tablecmds.c: In function ‘DefineRelation’:
tablecmds.c:761:17: error: unused variable ‘partdesc’
[-Werror=unused-variable]
Part
The release of GCC 7 is approaching [0], and the number of warnings in
PostgreSQL has gone up since we last looked [1]. Output attached. (My
version is 7.0.1 20170408.)
Most of the issues have to do with concatenating two or more strings of
potential size MAXPGPATH into another buffer of size MA
Why $subject?
Does it just need to be wired into the makefiles a bit better?
--
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
[ Adding Julien, whose patch this was. ]
On Thu, Apr 6, 2017 at 5:34 AM, Kuntal Ghosh wrote:
> While performing StartupDatabase, both master and standby server
> behave in similar way till postmaster spawns startup process.
> In master, startup process completes its job and dies. As a result,
> r
On 03/28/2017 06:46 AM, I wrote in pgsql-general:
>
> I use Postgres on Windows 64 bit (8.1,10,WS2012R2,WS2016) for quite a while.
> I always install and upgrade from the ZIP binary distribution from
> enterpriseDB which works like a charm.
>
> In a recent fresh install I noticed that PostgreSQL 9
On Sun, Apr 9, 2017 at 10:10 PM, Tom Lane wrote:
> While I admit that I've not been paying close attention to the whole
> table partitioning business, I wonder whether we have any clearly written
> down specification about (a) how much partition member tables are allowed
> to deviate schema-wise f
After you've run pg_upgrade, you have to loop through all your databases
and do an "ALTER EXTENSION abc UPDATE" once for each extension.
Is there a reason we shouldn't have pg_upgrade emit a script that does
this, similar to how it emits a script to run ANALYZE?
--
Magnus Hagander
Me: https://
On Mon, Apr 10, 2017 at 11:21 AM, Hans Buschmann wrote:
> On 03/28/2017 06:46 AM, I wrote in pgsql-general:
>> I use Postgres on Windows 64 bit (8.1,10,WS2012R2,WS2016) for quite a
>> while.
>> I always install and upgrade from the ZIP binary distribution from
>> enterpriseDB which works like a ch
On Mon, Apr 10, 2017 at 7:53 AM, Andrew Borodin wrote:
> I think this idea is somewhat related to this patch [2], but as for
> now cannot describe how exactly GiST merge and Range Merge features
> relate.
It also seems somewhat related to Peter Moser's work on ALIGN and
NORMALIZE. It would be ni
Hi Peter,
> c) Expand the target buffer sizes until the warning goes away. (Sample
> patch attached.)
I personally think it's a great patch. Unfortunately I don't have GCC
7.0 right now but at least it doesn't break anything on 6.3.1. Since
there is no rush I would suggest to add an entry to the
Hi Alexander!
I've missed your reply, since proposal submission deadline have passed last
Monday and I didn't check hackers mailing list too frequently.
(1) It seems that starting new subtransaction at step 4 is not necessary.
We can just gather all error lines in one pass and at the end of input
Hi all,
I was looking through the RI triggers code recently and noticed a few
almost identical functions, e.g. ri_restrict_upd() and
ri_restrict_del(). The following patch is an attempt to reduce some of
repetitive code. Yet there is still room for improvement.
Thanks,
--
Ildar Musin
i.mu...
Hi,
On 2017-04-10 11:03:23 -0400, Peter Eisentraut wrote:
> The release of GCC 7 is approaching [0], and the number of warnings in
> PostgreSQL has gone up since we last looked [1]. Output attached. (My
> version is 7.0.1 20170408.)
>
> Most of the issues have to do with concatenating two or mo
On 2017-04-10 09:10:07 -0700, Andres Freund wrote:
> Hi,
>
> On 2017-04-10 11:03:23 -0400, Peter Eisentraut wrote:
> > The release of GCC 7 is approaching [0], and the number of warnings in
> > PostgreSQL has gone up since we last looked [1]. Output attached. (My
> > version is 7.0.1 20170408.)
I wrote:
> Andrew Gierth writes:
>> In a discussion with Andres on the hash grouping sets review thread, I
>> proposed that we should have something of the form
>> #define lfirst_node(_type_, l) (castNode(_type_,lfirst(l)))
> That seems like a fairly good idea. A significant fraction of the
> e
On 2017-04-10 12:20:16 -0400, Tom Lane wrote:
> Barring objections, I'll push this shortly.
+1, to just about all of it
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut writes:
> Possible fixes:
> a) Ignore, hoping GCC will change before final release. (unlikely at
> this point)
> b) Add compiler option to disable this particular warning, worry about
> it later. (Might be an option for backpatching.)
> c) Expand the target buffer sizes until
On Mon, Apr 10, 2017 at 9:39 PM, Masahiko Sawada wrote:
> On Mon, Apr 10, 2017 at 9:32 PM, Petr Jelinek
> wrote:
>> On 10/04/17 07:16, Masahiko Sawada wrote:
>>> Hi all,
>>>
>>> Attached a patch for $subject.
>>>
>>> I added this parameter into "Asynchronous Behavior" section of
>>> "RESOURCE" se
Magnus Hagander writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
> PFA a patch that does this. Did I miss something? :)
Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by
"#ifdef
On Mon, Apr 10, 2017 at 8:14 AM, Ashutosh Bapat
wrote:
> On Fri, Mar 31, 2017 at 7:43 AM, Amit Langote
> wrote:
>> Summary is: We decided in f1b4c771ea7 [1] that passing the original slot
>> (one containing the tuple formatted per root partitioned table's tupdesc)
>> to ExecConstraints(), but tha
On Mon, Apr 10, 2017 at 8:30 AM, Michael Paquier
wrote:
> On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote:
>> I wonder if we shouldn't just do
>>
>> RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY;
>> ListCell *lc;
>>
>> /* Should only be applied to base relations that are s
On 4/10/17 05:49, Stas Kelvich wrote:
> Here is small patch to call statistics in logical worker. Originally i
> thought that stat
> collection during logical replication should manually account amounts of
> changed tuples,
> but seems that it is already smoothly handled on relation level. So cal
On 4/9/17 22:20, Noah Misch wrote:
> The above-described topic is currently a PostgreSQL 10 open item. Peter,
> 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
> v10 open item, please let us
On Mon, Apr 10, 2017 at 11:30 AM, Magnus Hagander wrote:
> After you've run pg_upgrade, you have to loop through all your databases and
> do an "ALTER EXTENSION abc UPDATE" once for each extension.
>
> Is there a reason we shouldn't have pg_upgrade emit a script that does this,
> similar to how it
On Mon, Apr 10, 2017 at 11:39 AM, Alex K wrote:
> (1) It seems that starting new subtransaction at step 4 is not necessary. We
> can just gather all error lines in one pass and at the end of input start
> the only one additional subtransaction with all safe-lines at once: [1, ...,
> k1 - 1, k1 + 1
Magnus Hagander writes:
> After you've run pg_upgrade, you have to loop through all your databases
> and do an "ALTER EXTENSION abc UPDATE" once for each extension.
> Is there a reason we shouldn't have pg_upgrade emit a script that does
> this, similar to how it emits a script to run ANALYZE?
+
> On 10 Apr 2017, at 19:50, Peter Eisentraut
> wrote:
>
> On 4/10/17 05:49, Stas Kelvich wrote:
>> Here is small patch to call statistics in logical worker. Originally i
>> thought that stat
>> collection during logical replication should manually account amounts of
>> changed tuples,
>> but
Tom Lane writes:
> I wonder if we shouldn't just do
>
> RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY;
> ListCell *lc;
>
> /* Should only be applied to base relations that are subqueries */
> Assert(rel->relid > 0);
> -#ifdef USE_ASSERT_CHECKING
> rte = planner_rt_
Hi,
src/backend/replication/logical/launcher.c
* Worker started and attached to our shmem. This check is safe
* because only launcher ever starts the workers, so nobody can steal
* the worker slot.
The tablesync patch enabled even worker to start another worker
On 4/9/17 23:20, Michael Paquier wrote:
> After more review, I think that got_SIGTERM should be of type volatile
> sig_atomic_t in launcher.c or that's not signal-safe. I think as well
> that for correctness errno should be saved as SetLatch() is called and
> restored afterwards. Please find attach
On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote:
> Thomas Munro writes:
>> Here's a pair of draft patches for review:
Thanks.
> Pushed with cosmetic improvements.
Thanks.
> I notice that the safe-snapshot code path is not paying attention to
> parallel-query cases, unlike the lock code path.
2017-04-10 13:07 GMT+02:00 Greg Stark :
> On 2 April 2017 at 07:53, Fabien COELHO wrote:
> > Note that this is already available indirectly, as show in the
> > documentation.
> >
> > SELECT some-boolean-expression AS okay \gset
> > \if :okay
> > \echo boolean expression was true
> > \el
OK, we need to come to a conclusion here. To summarize:
Problem 1: pg_subscription.subconninfo can only be read by superuser.
So non-superusers cannot dump subscriptions.
Precedent is pg_user_mapping. In that case, we just omit the
user-mapping options if we're not a superuser. Pretty dubious,
Robert Haas writes:
> On Mon, Apr 10, 2017 at 8:30 AM, Michael Paquier
> wrote:
>> On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote:
>>> I wonder if we shouldn't just do
>>> ...
>>> and eat the "useless" calculation of rte.
> -1 from me. I'm not a big fan of useless calculation just because it
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Why bother with the 'rte' variable at all if it's only used for the
> Assert()ing the rtekind?
That was proposed a few messages back. I don't like it because it makes
these functions look different from the other scan-cost-es
Kevin Grittner writes:
> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote:
>> I notice that the safe-snapshot code path is not paying attention to
>> parallel-query cases, unlike the lock code path. I'm not sure how
>> big a deal that is...
> Parallel workers in serializable transactions should
On 10/04/17 13:02, Heikki Linnakangas wrote:
On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
- I think channel binding support should be added. SCRAM brings security
improvements over md5 and other simpler digest algorithms. But where it
really shines is together with channel binding.
On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:
>
>
> On 10/04/17 13:02, Heikki Linnakangas wrote:
> > On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:
> > > - I think channel binding support should be added. SCRAM brings security
> > > improvements over md5 and other simpler
On Tue, Apr 11, 2017 at 1:16 AM, Robert Haas wrote:
>
> 1. Forget BGW_NEVER_RESTART workers in
> ResetBackgroundWorkerCrashTimes() rather than leaving them around to
> be cleaned up after the conclusion of the restart, so that they go
> away before rather than after shared memory is reset.
Now
On 10/04/17 14:57, Heikki Linnakangas wrote:
On 04/07/2017 01:13 AM, Michael Paquier wrote:
On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa
wrote:
I don't see it. The message AuthenticationSASL.String could
contain a
CSV of the SCRAM protocols supported. This is specially import
On Mon, Apr 10, 2017 at 1:17 PM, Tom Lane wrote:
> Kevin Grittner writes:
>> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote:
>>> I notice that the safe-snapshot code path is not paying attention to
>>> parallel-query cases, unlike the lock code path. I'm not sure how
>>> big a deal that is...
Yes, sure, I don't doubt it. The question was around step 4 in the following
possible algorithm:
1. Suppose we have to insert N records
2. Start subtransaction with these N records
3. Error is raised on k-th line
4. Then, we know that we can safely insert all lines from the 1st till (k - 1)
5. Re
On Tue, Apr 11, 2017 at 6:17 AM, Tom Lane wrote:
> Kevin Grittner writes:
>> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote:
>>> I notice that the safe-snapshot code path is not paying attention to
>>> parallel-query cases, unlike the lock code path. I'm not sure how
>>> big a deal that is...
On Mon, Apr 10, 2017 at 2:09 PM, Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> Why bother with the 'rte' variable at all if it's only used for the
>> Assert()ing the rtekind?
>
> That was proposed a few messages back. I don't like it because it makes
>
On 2017-04-08 14:46:04 +1200, Thomas Munro wrote:
> Fix attached.
Thanks. Pushed!
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thomas Munro writes:
> On Tue, Apr 11, 2017 at 6:17 AM, Tom Lane wrote:
>> Maybe it's impossible for a parallel worker to acquire its own
>> snapshot at all, in which case this is moot. But I'm nervous.
> Parallel workers can't acquire snapshots, and SERIALIZABLE disables
> all parallel query p
On 3/31/17 20:25, Petr Jelinek wrote:
> On 01/04/17 01:57, Petr Jelinek wrote:
>> That being said, looking at use-cases for SetSubscriptionRelState that's
>> basically CREATE SUBSCRIPTION, ALTER SUBSCRIPTION REFRESH and tablesync
>> worker. So the DDL thing applies to first ones as well and tablesy
On 2017-04-09 19:20:27 -0400, Tom Lane wrote:
> Andres Freund writes:
> > For a while I've been getting warnings like
> > /home/andres/src/postgresql/src/backend/utils/adt/inet_cidr_ntop.c: In
> > function ‘inet_cidr_ntop_ipv6’:
> > /home/andres/src/postgresql/src/backend/utils/adt/inet_cidr_ntop
Andres Freund writes:
> On 2017-04-09 19:20:27 -0400, Tom Lane wrote:
>> As I read that, it's only "undefined" if overflow would occur (ie
>> the sign bit would change). Your compiler is being a useless annoying
>> nanny, but that seems to be the in thing for compiler authors these
>> days.
> "T
On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
Thanks for posting the patched HTML. In my opinion, all looks good
except that:
- I will add an extra String (a CSV) to AuthenticationSASL message for
channel binding names, so that message format can remain without changes
when channe
On 10/04/17 21:41, Heikki Linnakangas wrote:
On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
Thanks for posting the patched HTML. In my opinion, all looks good
except that:
- I will add an extra String (a CSV) to AuthenticationSASL message for
channel binding names, so that messa
On 2017-04-10 15:25:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-04-09 19:20:27 -0400, Tom Lane wrote:
> >> As I read that, it's only "undefined" if overflow would occur (ie
> >> the sign bit would change). Your compiler is being a useless annoying
> >> nanny, but that seems to b
On Mon, Apr 10, 2017 at 2:32 PM, Neha Khatri wrote:
> On Tue, Apr 11, 2017 at 1:16 AM, Robert Haas wrote:
>> 1. Forget BGW_NEVER_RESTART workers in
>> ResetBackgroundWorkerCrashTimes() rather than leaving them around to
>> be cleaned up after the conclusion of the restart, so that they go
>> away
On Mon, Apr 10, 2017 at 2:32 PM, Andres Freund wrote:
> That can equally be said about about a lot of features. If we don't
> stop at some point... Also, we're not late in the CF cycle, the CF cycle
> for v10 is over. It's not like the non-existance of channel binding
> removes previously existi
On 10/04/17 22:19, Andres Freund wrote:
> I guess the motivation is that it's not entirely clear what happens with
> the sign bit, when shifting.
Indeed, certain one's complement CPUs even "outlived" C99 by a small
margin, as it were:
http://mainframe.typepad.com/blog/2012/10/sad-day-unisys-abando
1 - 100 of 141 matches
Mail list logo
