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 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
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 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
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
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
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
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
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
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-
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
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)
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
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/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 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 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 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/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
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 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
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
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 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
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
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
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
> "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
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
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 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
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 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
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 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
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 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
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 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
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
>
> \else
> \if :somevar > 1 and SERVER_NUM >= 10
>
should be
\if :somevar > 1 and :SERVER_NUM >= 10
> ...
> \end
>
>
101 - 141 of 141 matches
Mail list logo
