On 2015/10/09 15:04, Kyotaro HORIGUCHI wrote:
At Fri, 9 Oct 2015 12:00:30 +0900, Etsuro Fujita wrote
in <56172dce.7080...@lab.ntt.co.jp>
On 2015/10/08 19:55, Etsuro Fujita wrote:
I noticed that the approach using a column to populate the foreign
scan's slot directly wouldn't work well in some
On 2015/09/11 6:30, Robert Haas wrote:
On Wed, Sep 9, 2015 at 2:30 AM, Etsuro Fujita
wrote:
But that path might have already been discarded on the basis of cost.
I think Tom's idea is better: let the FDW consult some state cached
for this purpose in the RelOptInfo
Do you have an idea of what
I’ve started PostgreSQL server on Windows and then I kill client
backend’s process by taskkill the service was stopped:
postgres=# select pg_backend_pid();
pg_backend_pid
1976
postgres=# \! taskkill /pid 1976 /f
SUCCESS: The process with PID 1976 has been terminated.
On 2015/09/12 1:38, Robert Haas wrote:
On Thu, Sep 10, 2015 at 11:36 PM, Etsuro Fujita
wrote:
I've proposed the following API changes:
* I modified create_foreignscan_path, which is called from
postgresGetForeignJoinPaths/postgresGetForeignPaths, so that a path,
subpath, is passed as the eight
Hello Dmitry
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Dmitry Vasilyev
> Sent: Freitag, 9. Oktober 2015 11:52
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Postgres service stops when I kill client
This code stoped server too:
postgres=# do $$ unpack p,1x8 $$ language plperlu;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
On Fri, Oct 9, 2015 at 8:25 AM, Michael Paquier
wrote:
> On Thu, Oct 8, 2015 at 11:28 PM, Amir Rohan wrote:
>> Wouldn't this work?
>> 1) start timer
>> 2) Grab pg_stat_replication.sent_location from master
>> 3) pg_switch_xlog() # I /think/ we want this, could be wrong
>
> For a warm standby, you
On 10/09/2015 02:12 PM, Michael Paquier wrote:
> On Fri, Oct 9, 2015 at 8:25 AM, Michael Paquier
> wrote:
>> On Thu, Oct 8, 2015 at 11:28 PM, Amir Rohan wrote:
>>> Wouldn't this work?
>>> 1) start timer
>>> 2) Grab pg_stat_replication.sent_location from master
>>> 3) pg_switch_xlog() # I /think/ w
On Fri, Oct 9, 2015 at 8:47 PM, Amir Rohan wrote:
> Ok, I've put myself down as reviewer in cfapp. I don't think I can
> provide any more useful feedback that would actually result in changes
> at this point, but I'll read through the entire discussion once last
> time and write down final comments
We were some of the issues associated with the behavior of arrays.
1. We would like to implement arrays negative indices (from the end) like in
Python or Ruby: arr[-2] or arr[1: -1]
but as an array can be indexed in the negative area so it probably can not be
done.
2. We would like to add the a
On 10/08/2015 11:04 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> We've got one reloption for views already - security_barrier. Maybe
>> we could have another one that effectively changes a particular view
>> from "security definer" as it is today to "security invoker"
On Fri, Oct 9, 2015 at 3:35 PM, Etsuro Fujita
wrote:
Hi,
Just to have hands on, I started looking into this issue and trying to
grasp it as this is totally new code for me. And later I want to review
this code changes.
I have noticed that, this thread started saying we are getting a crash
with
On 10/8/15 6:11 AM, Pavel Stehule wrote:
> We cannot to raise PostgreSQL exception with setting all possible
> fields.
Such as? If there are fields missing, let's add them.
> I propose new function
>
> plpy.ereport(level, [ message [, detail [, hint [, sqlstate, ... )
That's not how Python
Any news on this item from 2013, worked on again 2014?
---
On Wed, Aug 6, 2014 at 12:55:59PM -0400, Bruce Momjian wrote:
> On Fri, Nov 29, 2013 at 02:04:10AM +, Greg Stark wrote:
> > Attached is what I have so far. I ha
Hello,
On 10/09/2015 02:59 AM, Kyotaro HORIGUCHI wrote:
The cause of this seeming mismatch would be the place to hold
indexrinfos. It is determined only by baserestrictinfo and
indpred. Any other components are not involved. So IndexClauseSet
is found not to be the best place after all, I suppos
* Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> On Fri, Oct 9, 2015 at 3:50 AM, Dean Rasheed wrote:
> > On 8 October 2015 at 15:05, Dean Rasheed wrote:
> >> Attached is a simple patch that appears to work, but it needs more
> >> testing (and some regression tests).
> >>
> >
> > Here's an upd
* Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> On Fri, Oct 9, 2015 at 2:04 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> We've got one reloption for views already - security_barrier. Maybe
> >> we could have another one that effectively changes a particular
08.10.2015 19:31, Thom Brown пишет:
On 8 October 2015 at 16:18, Anastasia Lubennikova
wrote:
Hi hackers,
I'm working on a patch that allows to combine covering and unique
functionality for btree indexes.
Previous discussion was here:
1) Proposal thread
2) Message with proposal clarification
On 10/09/2015 08:02 AM, YUriy Zhuravlev wrote:
We were some of the issues associated with the behavior of arrays.
1. We would like to implement arrays negative indices (from the end) like in
Python or Ruby: arr[-2] or arr[1: -1]
but as an array can be indexed in the negative area so it probabl
Michael Paquier wrote:
> > That would be WaitForSingleObject(handle, ms_timeout) ==
> > WAIT_OBJECT_0, no? The handle should be picked up from
> > CreateRestrictedProcess, and I think that CloseHandle should not be
> > called on pi.hProcess if we are going to wait for it afterwards.
> > Reference:
2015-10-09 15:22 GMT+02:00 Peter Eisentraut :
> On 10/8/15 6:11 AM, Pavel Stehule wrote:
> > We cannot to raise PostgreSQL exception with setting all possible
> > fields.
>
> Such as? If there are fields missing, let's add them.
>
> > I propose new function
> >
> > plpy.ereport(level, [ message [
Andres Freund writes:
> Hi,
Hi, thanks for the review; I really appreciate your time in going
through this. I have questions about some of your comments, so I'll
wait a bit before sending a v3. (By the way, there is a v2 of this I've
already posted, though you seem to have replied to the v1.
Michael Paquier writes:
> On Sun, Oct 4, 2015 at 1:18 AM, Andres Freund wrote:
>> Hi,
>>
>> I quickly read through the patch, trying to understand what exactly is
>> happening here. To me the way the patch is split doesn't make much sense
>> - I don't mind incremental patches, but right now the
On 10/5/15 10:50 AM, Tom Lane wrote:
Alvaro Herrera writes:
Andrew Dunstan wrote:
FWIW, (a) and (b) but not (c) is probably the right description for my
client who has been seeing problems here.
I think the fact that long IN lists are fingerprinted differently
according to the number of ele
On Thu, Oct 8, 2015 at 8:20 PM, Peter Geoghegan wrote:
> I should point out that I did not call the macro DatumToBigEndian(),
> because it's actually the other way around. I called it
> DatumToLittleEndian(), since the unsigned integer comparator would
> work correctly on big-endian systems withou
On Thu, Oct 8, 2015 at 7:36 AM, Андрей Асякин wrote:
> Hi!
> This is my first post to this list.
> (Sorry for my bad english)
>
> I decided to start small, but as it is in the TODO, then why not.
>
> In TODO:
>> Process pg_hba.conf keywords as case-insensitive
>>http://archives.postgresql.org/pgsq
On Fri, Oct 9, 2015 at 11:44 AM, Robert Haas wrote:
> Hmm. But then this doesn't seem to make much sense:
>
> + * Rearrange the bytes of a Datum into little-endian order from big-endian
> + * order. On big-endian machines, this does nothing at all.
>
> Rearranging bytes into little-endian order
On Thu, Oct 8, 2015 at 7:07 AM, Amir Rohan wrote:
> In addition to a simple syntax check, there's a bunch of "config wisdom"
> tidbits I've encountering, which is scattered through talks, commit
> messages, and mailing list discussion, and documentation notes
> (chapter 17, paragraph 12). These co
On Thu, Oct 8, 2015 at 9:06 AM, Amir Rohan wrote:
> On 10/08/2015 02:38 PM, Tom Lane wrote:
>> Amir Rohan writes:
>>> Comments?
>>
>> ISTM that all of the "functional" parts of this are superseded by
>> pg_file_settings;
>
> To use the new pg_file_settings view you need:
> 1( 9.5+
> 2( a running
On Fri, Oct 9, 2015 at 2:48 PM, Peter Geoghegan wrote:
> On Fri, Oct 9, 2015 at 11:44 AM, Robert Haas wrote:
>> Hmm. But then this doesn't seem to make much sense:
>>
>> + * Rearrange the bytes of a Datum into little-endian order from big-endian
>> + * order. On big-endian machines, this does n
On Thu, Oct 8, 2015 at 11:26 PM, Noah Misch wrote:
>> In particular, magically
>> substituting 127.0.0.1 for 0.0.0.0 seems utterly without principle.
>
> Binding a listening socket to "0.0.0.0" listens on every local IPv4 address,
> and 127.0.0.1 is one of those addresses. That's the principle.
On Thu, Oct 8, 2015 at 12:43 PM, David Christensen wrote:
> I’m happy to move it around, but If everything is in order, how will this
> affect things at all? If we’re in a good state this condition should never
> trigger.
Right, but I think it ought to be Catalog.pm's job to parse the config
f
On Thu, Oct 8, 2015 at 1:52 PM, Andres Freund wrote:
> I don't see the problem? I mean catversion will reliably tell you which
> format the vm is in?
Totally agreed.
> We could additionally use the opportunity to as a metapage, but that seems
> like an independent thing.
I agree with that, to
On Fri, Oct 9, 2015 at 12:11 PM, Robert Haas wrote:
> OK, committed that way.
Thank you.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 9, 2015 at 12:00 AM, Amit Kapila wrote:
> Sounds like both the approaches have some pros and cons, also there are
> some people who prefer mini-language and others who prefer JSON. I think
> one thing that might help, is to check how other databases support this
> feature or somewhat
On Fri, Oct 9, 2015 at 6:27 PM, Andrew Dunstan wrote:
> On 10/09/2015 08:02 AM, YUriy Zhuravlev wrote:
>
>> We were some of the issues associated with the behavior of arrays.
>> 1. We would like to implement arrays negative indices (from the end) like
>> in
>> Python or Ruby: arr[-2] or arr[1: -
> On Oct 9, 2015, at 2:17 PM, Robert Haas wrote:
>
> On Thu, Oct 8, 2015 at 12:43 PM, David Christensen wrote:
>> I’m happy to move it around, but If everything is in order, how will this
>> affect things at all? If we’re in a good state this condition should never
>> trigger.
>
> Right, bu
I fat-fingered a view create and ended up with this:
...
, schemaname, relname -- other
now
, d_now, ...
I was about to report this as a bug until Marko Tiikkaja pointed out on
IRC that now was being treated as an alias for relname.
I'm not sure if this is required by the sp
On 2015-10-09 10:31 PM, Jim Nasby wrote:
I was about to report this as a bug until Marko Tiikkaja pointed out on
IRC that now was being treated as an alias for relname.
I'm not sure if this is required by the spec, but can we at least emit a
WARNING if not reject this case outright? I think it'd
On 10/09/2015 09:55 PM, Robert Haas wrote:
> On Thu, Oct 8, 2015 at 9:06 AM, Amir Rohan wrote:
>> On 10/08/2015 02:38 PM, Tom Lane wrote:
>>> Amir Rohan writes:
Comments?
>>>
>>> ISTM that all of the "functional" parts of this are superseded by
>>> pg_file_settings;
>>
>> To use the new pg_f
Nathan,
If you're going further with this, one thing that we'll need is a bug
triage interface. This is something which is better done by web; that
is, a way for volunteers to go through bugs by status, and quickly
update their status and/or post follow-up questions, and then go to the
next one i
Jim Nasby writes:
> I fat-fingered a view create and ended up with this:
> ...
>, schemaname, relname -- other
>now
>, d_now, ...
> I was about to report this as a bug until Marko Tiikkaja pointed out on
> IRC that now was being treated as an alias for relname.
> I'm not
On Fri, Oct 9, 2015 at 12:11 PM, Robert Haas wrote:
> OK, committed that way.
Just for the record, with the same "cities" table as my original post
to this thread, this query:
select count(distinct(city)) from cities;
Goes from taking about 296ms (once it stabilizes), to about 265ms
(once it st
Alvaro Herrera writes:
> I wonder if you are interested in rewriting this whole thing to not use
> cmd.exe at all, which as I understand is just about output redirection.
FWIW, I have little interest in going there, because I'm afraid that
getting it to be bug-compatible with the existing behavio
On 10/9/15 4:16 PM, Tom Lane wrote:
Jim Nasby writes:
I fat-fingered a view create and ended up with this:
...
, schemaname, relname -- other
now
, d_now, ...
I was about to report this as a bug until Marko Tiikkaja pointed out on
IRC that now was being treated as an ali
On Fri, Oct 9, 2015 at 3:33 PM, Peter Geoghegan wrote:
> On Fri, Oct 9, 2015 at 12:11 PM, Robert Haas wrote:
>> OK, committed that way.
>
> Thank you.
You're welcome. After some study and experimentation, I've committed
the other part also.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
On Fri, Oct 9, 2015 at 5:41 AM, Etsuro Fujita
wrote:
> Do you have any plan about the hook?
No. I think if you and Tom think it should be moved, one of you
should propose a patch. Ideally accompanied by a demo of how
postgres_fdw would be expected to use the revised hook.
--
Robert Haas
Enter
On Fri, Oct 9, 2015 at 5:52 AM, Dmitry Vasilyev
wrote:
> I’ve started PostgreSQL server on Windows and then I kill client
> backend’s process by taskkill the service was stopped:
>
> postgres=# select pg_backend_pid();
> pg_backend_pid
>
>1976
>
> postgres=# \! taskki
On Fri, Oct 9, 2015 at 4:39 PM, Robert Haas wrote:
> You're welcome. After some study and experimentation, I've committed
> the other part also.
Fantastic. I guess the precedent of the 9.5 text equality fast path
made this discussion way smoother than last time, since essentially
the same princi
On Fri, Oct 9, 2015 at 7:49 PM, Peter Geoghegan wrote:
> On Fri, Oct 9, 2015 at 4:39 PM, Robert Haas wrote:
>> You're welcome. After some study and experimentation, I've committed
>> the other part also.
>
> Fantastic. I guess the precedent of the 9.5 text equality fast path
> made this discussi
On Thu, Oct 8, 2015 at 11:00 PM, Etsuro Fujita
wrote:
>> The best plan is presumably something like this as you said before:
>>
>> LockRows
>> -> Nested Loop
>> -> Seq Scan on verysmall v
>> -> Foreign Scan on bigft1 and bigft2
>> Remote SQL: SELECT * FROM bigft1 JOIN bigft2 ON bi
On Fri, Oct 09, 2015 at 03:14:26PM -0400, Robert Haas wrote:
> On Thu, Oct 8, 2015 at 11:26 PM, Noah Misch wrote:
> >> In particular, magically
> >> substituting 127.0.0.1 for 0.0.0.0 seems utterly without principle.
> >
> > Binding a listening socket to "0.0.0.0" listens on every local IPv4 addre
On 2015/10/03 6:18, Peter Geoghegan wrote:
On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu wrote:
I know this still needs to be discussed, but I would like to submit
a patch for further discussion at the next CF, 2015-11.
I think I already expressed this in my explanation of the current
beha
53 matches
Mail list logo
