В Fri, 23 Oct 2015 16:02:33 -0400
Korry Douglas пишет:
d> > Now support for service files is implemented and multiple host
> > statements in the service file are allowed.
>
> A couple of minor nits:
>
> When you call pg_is_in_recovery(), you should schema-qualify the
> function name, just in c
В Fri, 23 Oct 2015 22:14:56 +0100
Thom Brown пишет:
c> >
> > pg_basebackup -v -x -D standby1 \
> > -d "host=localhost port=5532 user=rep_user readonly=1"
>
> Yes, this works:
>
> $ pg_basebackup -v -x -D standby1 -d "host=localhost port=5532
> user=rep_user readonly=1"
> transaction log start
On 10/23/15 11:10 PM, Noah Misch wrote:
> On RHEL 5 and some other "active adult" systems, "localhost" does not reach a
> listen_addresses='::' server. IPv6 is available, but "localhost" resolves to
> 127.0.0.1 only.
>
> The latest systems resolve "localhost" to both 127.0.0.1 and ::1, in which
>
On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes wrote:
> On Fri, Oct 23, 2015 at 3:06 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Jeff Janes wrote:
> >>> When I use psql with wrapped format with expanded output, I get the
> >>> period that is supposed to be at the end of the line being at t
On Thu, Oct 22, 2015 at 07:59:27PM -0700, Tom Lane wrote:
> Noah Misch writes:
> > pg_ctl reads the address from postmaster.pid, which in turn derives from
> > listen_addresses:
>
> > $ grep -E '(unix|listen)' postgresql.conf
> > listen_addresses = '0.0.0.0'
> > unix_socket_directories = ''
>
>
Unfortunately it doesn't work (no debug trace).
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> This should work better
>
> https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/9.4-120
On Mon, Oct 5, 2015 at 9:53 PM, Masahiko Sawada
wrote:
>
> On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao
wrote:
> > On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada
wrote:
> >>> +#define Anum_pg_class_relallfrozen12
> >>> Why is pg_class.relallfrozen necessary? ISTM that there is no user o
This should work better
https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/9.4-1204-jdbc41-SNAPSHOT/
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
On 23 October 2015 at 21:32, Dave Cramer wrote:
> No, I need to provide you with a 41 version.
>
> I just
On Thu, Oct 22, 2015 at 11:59:58PM -0400, Robert Haas wrote:
> On Thu, Oct 15, 2015 at 8:23 PM, Noah Misch wrote:
> > Agreed. More specifically, I had in mind for copyParamList() to check the
> > mask while e.g. ExecEvalParamExtern() would either check nothing or merely
> > assert that any mask i
No, I need to provide you with a 41 version.
I just happened to have java 1.8 on my machine.
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
On 23 October 2015 at 21:31, Tatsuo Ishii wrote:
> Dave,
>
> Thanks for the quick response. Unfortunately now I'm getting error
> with the JDBC
Dave,
Thanks for the quick response. Unfortunately now I'm getting error
with the JDBC driver.
warning:
/usr/local/pgsql/share/postgresql-9.4-1204-jdbc42-20151023.230759-1.jar(org/postgresql/Driver.class):
major version 52 is newer than 51, the highest major version supported by this
compiler.
On Fri, Oct 23, 2015 at 5:45 PM, Robert Haas wrote:
>
> On Fri, Oct 23, 2015 at 3:35 AM, Amit Kapila
wrote:
> > Considering parallelism at RelOptInfo level in the way as done in patch,
> > won't consider the RelOptInfo's for child relations in case of Append
node.
> > Refer build_simple_rel().
>
On Thu, Oct 22, 2015 at 2:49 PM, Robert Haas wrote:
> You probably would, but sometimes that might not be possible; for
> example, the tlist might contain a parallel-restricted function (which
> therefore has to run in the leader).
Oh, also: pushing down the tlist is actually sorta non-trivial at
On Fri, Oct 23, 2015 at 3:06 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Jeff Janes wrote:
>>> When I use psql with wrapped format with expanded output, I get the
>>> period that is supposed to be at the end of the line being at the
>>> beginning of the next line.
>>>
>>> Can anyone else veri
Tatsuo,
Can you confirm it is fixed in this snapshot
https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/9.4-1204-jdbc42-SNAPSHOT/
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
On 23 October 2015 at 19:00, Dave Cramer wrote:
> Tatsuo,
>
> posting to jdb
Tatsuo,
posting to jdbc list
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
On 23 October 2015 at 18:28, Tatsuo Ishii wrote:
> It seems
> org.postgresql.Driver.setLogLevel(org.postgresql.Driver.DEBUG) does
> not work anymore in the newer JDBC driver.
>
> As far as I know, postgresql-
It seems
org.postgresql.Driver.setLogLevel(org.postgresql.Driver.DEBUG) does
not work anymore in the newer JDBC driver.
As far as I know, postgresql-9.2-1003.jdbc4.jar or
postgresql-9.3-1104.jdbc41.jar work fine and produce following output
for example:
16:36:36.459 (1) PostgreSQL 9.3 JDBC4.1 (bu
Alvaro Herrera writes:
> Jeff Janes wrote:
>> When I use psql with wrapped format with expanded output, I get the
>> period that is supposed to be at the end of the line being at the
>> beginning of the next line.
>>
>> Can anyone else verify this? I want to verify it is not some local
>> issue
Jeff Janes wrote:
> When I use psql with wrapped format with expanded output, I get the
> period that is supposed to be at the end of the line being at the
> beginning of the next line.
>
> Can anyone else verify this? I want to verify it is not some local
> issue before looking into it too far.
On 23 October 2015 at 12:52, Victor Wagner wrote:
> On Thu, 22 Oct 2015 14:33:11 +0100
> Thom Brown wrote:
>
>> On 21 October 2015 at 10:07, Victor Wagner wrote:
>> > On 2015.10.14 at 13:41:51 +0300, Victor Wagner wrote:
>> >
>> >>
>> >> Attached patch which implements client library failover an
When I use psql with wrapped format with expanded output, I get the
period that is supposed to be at the end of the line being at the
beginning of the next line.
Can anyone else verify this? I want to verify it is not some local
issue before looking into it too far.
I've made the screen absurdly
On 2015.10.14 at 13:41:51 +0300, Victor Wagner wrote:
Attached patch which implements client library failover and
loadbalancing as was described in the proposal
<20150818041850.ga5...@wagner.pp.ru>.
I'm sending imporoved verison of patch. As Olexander Shulgin noted,
previous version of pat
On Thu, Oct 22, 2015 at 10:36 PM, Tom Lane wrote:
> What I would like is to find a way to auto-generate basically this entire
> file from gram.y. That would imply going over to something at least
> somewhat parser-based, instead of the current way that is more or less
> totally ad-hoc. That woul
On Sat, Oct 24, 2015 at 6:19 AM, Jeff Janes wrote:
> On Sun, Oct 18, 2015 at 9:12 PM, Thomas Munro
> wrote:
>> Thanks for taking a look at this! The word count returned by
>> get_previous_words was incorrect. Here is a corrected version.
>
> I haven't looked at v6 yet, but in v5:
>
> "set work_
On Sat, Jul 25, 2015 at 11:13 PM, Kouhei Kaigai wrote:
> I'm recently working/investigating on ParallelAppend feature
> towards the next commit fest. Below is my design proposal.
>
> 1. Concept
> --
> Its concept is quite simple anybody might consider more than once.
> ParallelAppend node
Jeff Janes wrote:
> For the bigger picture, I don't think we should not apply this patch simply
> because there is something even better we might theoretically do at some
> point in the future.
Agreed.
> Having used it a little bit, I do agree with Robert
> that it is not a gigantic improvement
On Sun, Oct 18, 2015 at 9:12 PM, Thomas Munro wrote:
>
> Thanks for taking a look at this! The word count returned by
> get_previous_words was incorrect. Here is a corrected version.
>
I haven't looked at v6 yet, but in v5:
"set work_mem TO" completes to "NULL" not to "DEFAULT"
line 2665 of
David Fetter writes:
> Is it really on us as a community to go long distances out of our way
> to assuage the baseless[1] paranoia of people who are by and large not
> part of our community?
While I personally don't care that much about the proprietary-psql-variant
scenario, I do care whether peo
On Fri, Oct 23, 2015 at 12:15:01PM -0400, Robert Haas wrote:
> On Fri, Oct 23, 2015 at 11:16 AM, David Fetter wrote:
> > Proprietary, secret changes to the back end, sure, but the client?
> > The most recent example I recall of that is Netezza, and I suspect
> > that they just couldn't be bothered
On 10/23/15 11:02 AM, Heikki Linnakangas wrote:
On 10/23/2015 02:59 PM, Michael Paquier wrote:
On Fri, Oct 23, 2015 at 7:46 PM, Heikki Linnakangas wrote:
On 10/23/2015 01:33 PM, Sandro Santilli wrote:
In short, I don't think just setting extensions_path is enough or
desirable,
but I would welco
On Fri, Oct 23, 2015 at 11:16 AM, David Fetter wrote:
> Proprietary, secret changes to the back end, sure, but the client?
> The most recent example I recall of that is Netezza, and I suspect
> that they just couldn't be bothered to publish the changes they made.
> At that time, the community psql
On 10/23/2015 02:59 PM, Michael Paquier wrote:
On Fri, Oct 23, 2015 at 7:46 PM, Heikki Linnakangas wrote:
On 10/23/2015 01:33 PM, Sandro Santilli wrote:
In short, I don't think just setting extensions_path is enough or desirable,
but I would welcome a patch that makes "make check" work for exten
On Fri, Oct 23, 2015 at 02:09:43AM +0200, Andres Freund wrote:
> On 2015-10-22 16:26:10 -0700, David Fetter wrote:
> > To be affective negatively by libreadline's viral license, an entity
> > would need to fork the psql client in proprietary ways that they did
> > not wish not to make available to
On Fri, Oct 23, 2015 at 7:20 AM, Alvaro Herrera
wrote:
> Andres Freund wrote:
>
>> FWIW, adding an <> operator for xid seems like a perfectly good idea.
+1. I have wanted that more than once, but avoided it all the time
with some casts.
> +1 (two of them actually --
See for example the attached
On Fri, Aug 28, 2015 at 4:33 AM, Kyotaro HORIGUCHI
wrote:
> Hi, this is a spin-off patch from Fabien COELHO's
> backslash-continuations.
>
> The major concept of this patch is making usage of psql's scanner
> to get rid of home-grown scanner of pgbench to make
> multi-statement feature available f
On Fri, Oct 23, 2015 at 3:35 AM, Amit Kapila wrote:
> Considering parallelism at RelOptInfo level in the way as done in patch,
> won't consider the RelOptInfo's for child relations in case of Append node.
> Refer build_simple_rel().
Hmm, true, but what can go wrong there? The same quals apply to
On Fri, Oct 23, 2015 at 7:46 PM, Heikki Linnakangas wrote:
> On 10/23/2015 01:33 PM, Sandro Santilli wrote:
> In short, I don't think just setting extensions_path is enough or desirable,
> but I would welcome a patch that makes "make check" work for extensions, by
> creating a temporary installatio
On Thu, 22 Oct 2015 14:33:11 +0100
Thom Brown wrote:
> On 21 October 2015 at 10:07, Victor Wagner wrote:
> > On 2015.10.14 at 13:41:51 +0300, Victor Wagner wrote:
> >
> >>
> >> Attached patch which implements client library failover and
> >> loadbalancing as was described in the proposal
> >> <2
On Fri, Oct 23, 2015 at 10:33 AM, Robert Haas wrote:
>
> + /*
> +* We can't finish transaction commit or abort until all
of the
> +* workers are dead. This means, in particular, that
> we can't respond
> +* to interrupts at this stage.
23.10.2015, 13:33, Sandro Santilli kirjoitti:
One problem we have with PostGIS is you cannot test an extension
unless you have access to the system extension dir.
The following patch tries to address that by allowing to specify
a per-cluster extension path via an "extensions_path" GUC.
It is mo
On 10/23/2015 01:33 PM, Sandro Santilli wrote:
One problem we have with PostGIS is you cannot test an extension
unless you have access to the system extension dir.
The following patch tries to address that by allowing to specify
a per-cluster extension path via an "extensions_path" GUC.
It is m
One problem we have with PostGIS is you cannot test an extension
unless you have access to the system extension dir.
The following patch tries to address that by allowing to specify
a per-cluster extension path via an "extensions_path" GUC.
It is more a request-for-comments rather than a ready pa
On Friday 23 October 2015 12:41:50 you wrote:
> Requirement of python with pycparser as build dependency is a
> serious cataclysm. For instance, how many buildfarms will survive it?
> This is why Tom and Robert are looking for ways to evade it.
I agree. But it is also a fact that Perl less suited
On 2015/10/23 18:51, Etsuro Fujita wrote:
> On 2015/10/23 6:06, Robert Haas wrote:
>> Good catch. Committed and back-patched to 9.5.
>
> Thanks, Amit and Robert!
>
> This is really really nitpicking, but I noticed that there is an implicit
> rule concerning the message format in ATWrongRelkindEr
On 2015/10/23 6:06, Robert Haas wrote:
On Wed, Oct 21, 2015 at 1:51 AM, Amit Langote
wrote:
This may just be nitpicking but I noticed that ATWrongRelkindError() could
emit a better message in case of such errors during ALTER COLUMN DEFAULT
and ALTER COLUMN SET STORAGE than "%s is of the wrong
On Fri, Oct 23, 2015 at 12:31 PM, YUriy Zhuravlev <
u.zhurav...@postgrespro.ru> wrote:
> On Thursday 22 October 2015 09:26:46 David Fetter wrote:
> > On Thu, Oct 22, 2015 at 07:15:35PM +0300, YUriy Zhuravlev wrote:
> > > Hello.
> > > Currently using nodeToString and stringToNode you can not pass a
On Thursday 22 October 2015 09:26:46 David Fetter wrote:
> On Thu, Oct 22, 2015 at 07:15:35PM +0300, YUriy Zhuravlev wrote:
> > Hello.
> > Currently using nodeToString and stringToNode you can not pass a
> > full plan. In this regard, what is the plan to fix it? Or in the
> > under task parallel qu
> I thought that's what you were proposing. Process the struct
> definitions and emit .c files.
We have 2 ways. The first is always to generate the * .c files from the * .h
files. Another way is to generate once from * .h file a XML/JSON and after
generate from it to * .c files (parsing xml/json
On Fri, Oct 23, 2015 at 5:14 AM, Robert Haas wrote:
>
> On Tue, Oct 13, 2015 at 5:59 PM, Robert Haas
wrote:
> > - Although the changes in parallelpaths.c are in a good direction, I'm
> > pretty sure this is not yet up to scratch. I am less sure exactly
> > what needs to be fixed, so I'll have to
49 matches
Mail list logo
