>
> \else
> \if :somevar > 1 and SERVER_NUM >= 10
>
should be
\if :somevar > 1 and :SERVER_NUM >= 10
> ...
> \end
>
>
Hello Pavel,
I think so some local expression evaluation could be - but it should not be
placed in \if statement
Why?
\expr issupported :VERSION_NUM >= 1
Hmmm. Although I do not buy this, it could work as a replacement for \set
which it seems cannot be upgraded because some people ma
On 04/10/2017 11:03 PM, Álvaro Hernández Tortosa wrote:
Channel binding needs to specify actually three things:
- The mechanism, which is indeed suffixed "-PLUS".
- The channel binding name, which is described here:
https://tools.ietf.org/html/rfc5056. Types are also IANA-registered (see
htt
2017-04-11 8:17 GMT+02:00 Fabien COELHO :
>
> Hello Greg,
>
> SELECT some-boolean-expression AS okay \gset
>>> \if :okay
>>>
>>
>> Am I the only one who thinks that even if \if got the ability to
>> evaluate arbitrary SQL queries I would probably still always write
>> things as above?
>>
>
> I
On Tue, Apr 11, 2017 at 5:45 AM, Kevin Grittner wrote:
> 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.
Thanks Tom and Kevin.
After this commit hyrax ran the
Hello Greg,
SELECT some-boolean-expression AS okay \gset
\if :okay
Am I the only one who thinks that even if \if got the ability to
evaluate arbitrary SQL queries I would probably still always write
things as above?
I think putting arbitrary SQL expressions (let alone queries) would mak
On Tue, Apr 11, 2017 at 12:14 AM, Peter Eisentraut
wrote:
> Why $subject?
>
> Does it just need to be wired into the makefiles a bit better?
Looks like an oversight to me. I would suggest changing the Makefile like that:
diff --git a/contrib/bloom/Makefile b/contrib/bloom/Makefile
index 13bd397b7
On Mon, Apr 10, 2017 at 5:11 PM, Heikki Linnakangas wrote:
> Here are some characters that seem plausible to be misinterpreted and
> ignored by SASLprep:
> EUC-JP and EUC-JISX0213:
>
> U+00AD (C2 AD): 足 (meaning "foot", per Unihan database)
> U+FE00-FE0F (EF B8 8X): 鏝 (meaning "trowel", per Unihan
On 04/11/2017 04:52 AM, Peter Eisentraut wrote:
On 4/10/17 04:27, Heikki Linnakangas wrote:
One thing to consider is that we just made the decision that "md5"
actually means "md5 or scram-sha-256". Extrapolating from that, I think
we'll want "scram-sha-256" to mean "scram-sha-256 or scram-sha-25
Hi,
I tried to use the bytea type with ecpg, but the corresponding host variable
was not described in the manual.
https://www.postgresql.org/docs/devel/static/ecpg-variables.html#ecpg-variables-type-mapping
According to the test code, the bytea type seems to correspond to char *.
src/interfa
On Fri, Apr 07, 2017 at 09:58:07AM -0700, Jeff Janes wrote:
> --progress-timestamp is supposed to make -P report a Unix Epoch time stamp,
> for easy correlation with the entries in other log files (like the postgres
> server log file using %n).
>
> But that broke in this commit:
>
> commit 1d63f7
On Tue, Apr 11, 2017 at 4:41 AM, Heikki Linnakangas wrote:
> On 04/10/2017 09:33 PM, Álvaro Hernández Tortosa wrote:
>> - If the username used is the one sent in the startup message, rather
>> than leaving it empty in the client-first-message, I would force it to
>> be the same as the used in the
On Fri, Apr 07, 2017 at 11:58:10AM +, Heikki Linnakangas wrote:
> No documentation changes included, because there is no details on the
> SCRAM mechanism in the docs anyway. An overview on that in the protocol
> specification would probably be good, even though SCRAM is documented in
> detail i
> "Tom" == Tom Lane writes:
>> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
>> ...
>> I plan to fix this one properly, unless anyone has any objections.
Tom> Just to clarify, what do you think is "properly"?
I would say, that any time an intarray function returns an
Andrew Gierth writes:
> The distinction between the standard representation of '{}' as an array
> with zero dimensions and nonstandard representations as a 1-dimensional
> array with zero elements has come up in a couple of contexts on the IRC
> channel recently.
> First is contrib/intarray, _AGA
Hi,
I am trying to use the raster2pgsql tool to import raster images in MrSID
format to PostGIS database on a Windows system. However, I get an error
indicating that the format is not supported which I could confirm by
running:
raster2pgsql -G
Please, could someone help with the basic steps to fo
Noah Misch writes:
> On Mon, Apr 10, 2017 at 09:36:59PM -0400, Peter Eisentraut wrote:
>> If history had been different, we could have implemented, say,
>> autovacuum or walreceiver on the background worker framework. I think
>> unifying some of that might actually be a future project. Would it
On 4/8/17 12:50, Robert Haas wrote:
> On Sat, Apr 8, 2017 at 6:39 AM, Bruce Momjian wrote:
>> What other problems do we have with pgweb that I can work on?
>
> Well, the 10devel documentation doesn't believe in orange. Compare:
>
> https://www.postgresql.org/docs/devel/static/sql-createtable.ht
Hi All,
I created an out-db raster using the following syntax:
raster2pgsql -s {srid} -c -R -I -C -F -t auto {absolute_file_path}
public.{table} | psql -h {host} -p {port} -d {database} -U {user}
The table was created successfully. I wanted to confirm that the actual
file is being read from the
On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane wrote:
> 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 patc
On Mon, Apr 10, 2017 at 09:36:59PM -0400, Peter Eisentraut wrote:
> On 4/9/17 22:40, Noah Misch wrote:
> > Agreed. There are times when starting up degraded beats failing to start,
> > particularly when the failing component has complicated dependencies. In
> > this
> > case, as detailed upthrea
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 4/10/17 20:55, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >> Problem 1: pg_subscription.subconninfo can only be read by superuser.
> >> So non-superusers cannot dump subscriptions.
On 4/10/17 04:27, Heikki Linnakangas wrote:
> One thing to consider is that we just made the decision that "md5"
> actually means "md5 or scram-sha-256". Extrapolating from that, I think
> we'll want "scram-sha-256" to mean "scram-sha-256 or scram-sha-256-plus"
> (i.e. the channel-bonding varian
On Mon, Apr 10, 2017 at 5:57 PM, Andrew Gierth
wrote:
> Second is aclitem[], past bug #8395 which was not really resolved; empty
> ACLs are actually 1-dim arrays of length 0, and all the ACL functions
> insist on that, which means that you can't call aclexplode('{}') for
> example:
>
> https://ww
On 4/9/17 19:19, Noah Misch wrote:
> These are the two chief approaches I'm seeing:
>
> 1. scram-sha-256, scram-sha-256-plus, and successors will be their own
>pg_hba.conf authentication methods. Until and unless someone implements an
>ability to name multiple methods per HBA line, you mu
On 4/10/17 11:55, Ildar Musin wrote:
> 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.
That looks like something worth pursu
On 4/9/17 22:40, Noah Misch wrote:
> Agreed. There are times when starting up degraded beats failing to start,
> particularly when the failing component has complicated dependencies. In this
> case, as detailed upthread, this can only fail in response to basic
> misconfiguration. It's not the ki
On Mon, Apr 10, 2017 at 5:47 PM, Magnus Hagander wrote:
> Based on that we seem to agree here, should we add this as an open item?
> Clearly if we want to change this, we should do so before 10.
This really is a new feature, so as the focus is to stabilize things I
think that we should not make t
On 4/10/17 20:55, Stephen Frost wrote:
> Peter,
>
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> Problem 1: pg_subscription.subconninfo can only be read by superuser.
>> So non-superusers cannot dump subscriptions.
>
> I'm not particularly happy with this.
Why? How? Alternat
The distinction between the standard representation of '{}' as an array
with zero dimensions and nonstandard representations as a 1-dimensional
array with zero elements has come up in a couple of contexts on the IRC
channel recently.
First is contrib/intarray, _AGAIN_ (see past bugs such as #7730)
Hello, thank you for looking this.
At Fri, 07 Apr 2017 20:38:35 -0400, Tom Lane wrote in
<27309.1491611...@sss.pgh.pa.us>
> Alvaro Herrera writes:
> > Interesting. I wonder if it's possible that a relcache invalidation
> > would cause these values to get lost for some reason, because that woul
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> Problem 1: pg_subscription.subconninfo can only be read by superuser.
> So non-superusers cannot dump subscriptions.
I'm not particularly happy with this.
> Precedent is pg_user_mapping. In that case, we just omit the
> user-
On 2017/04/08 1:49, Tom Lane wrote:
> Amit Langote writes:
>> Should ExecPrepareExprList also switch to estate->es_query_cxt?
>
> Good point; I'm surprised we haven't noted any failures from that.
> We surely want the entire result data structure to be in the same
> memory context. There are not
On Tue, Apr 11, 2017 at 4:02 AM, Robert Haas wrote:
> 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 propo
I wrote:
> (BTW, I've not yet looked to see if this needs to be back-ported.)
postgres_fdw will definitely include RestrictInfos in its fdw_private
list in 9.6. However, I've been unable to provoke a visible failure.
After some rooting around, the reason seems to be that:
1. postgres_fdw doesn't
Tomas Vondra wrote:
> On 04/10/2017 12:12 PM, David Rowley wrote:
> > 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
Hi,
On 2017-04-08 23:36:13 +0530, Pavan Deolasee wrote:
> On Wed, Apr 5, 2017 at 11:57 PM, Andres Freund wrote:
>
> > On 2017-04-05 09:36:47 -0400, Robert Haas wrote:
> > > By the way, the "Converting WARM chains back to HOT chains" section of
> > > README.WARM seems to be out of date. Any cha
On 04/10/2017 12:12 PM, David Rowley wrote:
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 th
On Sat, Apr 8, 2017 at 11:36:13PM +0530, Pavan Deolasee wrote:
> Thank you all for the reviews, feedback, tests, criticism. And apologies for
> keep pushing it till the last minute even though it was clear to me quite some
> time back the patch is not going to make it. But if I'd given up, it wou
On 04/10/2017 01:39 PM, Kuntal Ghosh wrote:
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
qu
I wrote:
> Apparently, postgres_fdw is trying to store RestrictInfos in the
> fdw_private field of a ForeignScan node. That won't do; those aren't
> supposed to be present in a finished plan tree, so there's no readfuncs.c
> support for them (and we're not adding it).
> Don't know if this is a ne
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
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 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 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 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 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
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 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
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
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 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
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 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...
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 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...
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 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 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 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.
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
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
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
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,
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
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.
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
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
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_
> 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
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 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
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 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 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 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 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
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 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
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 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
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 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.)
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
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 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 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
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
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
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 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
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
[ 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
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
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
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
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
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
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
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
> >
1 - 100 of 141 matches
Mail list logo
