On 4 January 2016 at 21:49, David Rowley
wrote:
> I've not tested the patch yet. I will send another email soon with the
> results of that.
>
Hi,
As promised I've done some testing on this, and I've found something which
is not quite right:
create table ab (a int,b int);
insert into ab select
On Mon, Jan 04, 2016 at 12:55:16PM -0500, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote:
> I'm approaching this largely from a 3rd-party application perspective.
> There are two examples off-hand which I'm consideri
On Wed, Jan 6, 2016 at 8:14 AM, Haribabu Kommi wrote:
> Following are my observations on the latest patch.
Thanks for your review.
> + If no WAL receiver is present on the server queried,
> + a single tuple filled with NULL values is returned instead.
> +
>
> The above documentation change i
On 1/5/16 9:16 PM, Tom Lane wrote:
Jim Nasby writes:
FWIW, I suspect very few people know about the verbosity setting (I
didn't until a few months ago...) Maybe psql should hint about it the
first time an error is reported in a session.
Actually, what'd be really handy IMO is something to reg
Jim Nasby writes:
> FWIW, I suspect very few people know about the verbosity setting (I
> didn't until a few months ago...) Maybe psql should hint about it the
> first time an error is reported in a session.
Actually, what'd be really handy IMO is something to regurgitate the
most recent error
On Tue, Jan 5, 2016 at 7:24 PM, Jesper Pedersen
wrote:
>
> On 01/05/2016 08:04 AM, Amit Kapila wrote:
>>
>> I am not aware of such cases, however the reason I have kept it was for
>> backward-compatability, but now I have removed it in the attached patch.
>>
>> Apart from that, I have updated the
On 1/5/16 8:41 PM, Tom Lane wrote:
Jim Nasby writes:
>does psql do anything with those fields? ISTM the biggest use for this
>info is someone sitting at psql or pgAdmin.
Sure, if you turn up the error verbosity.
FWIW, I suspect very few people know about the verbosity setting (I
didn't unti
On 2016/01/06 10:17, Haribabu Kommi wrote:
> On Mon, Jan 4, 2016 at 10:43 PM, Haribabu Kommi
>>
>> Thanks for the test. Yes, the issue happens at backend startup itself.
>> I will give a try by separating the initialization of security
>> policies after init phase 3.
>
> Here I attached updated pa
On 01/05/2016 06:30 PM, Jim Nasby wrote:
On 1/5/16 8:19 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
Which doesn't help anyone, because neither of those provide a list
of "hey, here's stuff you could do to contribute". The closest we
come to that is the TODO, which isn
Jim Nasby writes:
> does psql do anything with those fields? ISTM the biggest use for this
> info is someone sitting at psql or pgAdmin.
Sure, if you turn up the error verbosity.
regression=# create table foo (f1 int primary key);
CREATE TABLE
regression=# create table bar (f1 int references fo
On 1/5/16 7:21 PM, Tom Lane wrote:
What seems more likely to be useful and to not break anything is to push
forward on adding PG_DIAG_SCHEMA_NAME and similar auxiliary fields to more
error messages (see errtable() and siblings). That would allow
applications to extract this information automatic
Joshua D. Drake wrote:
> On 01/05/2016 04:53 PM, Michael Paquier wrote:
> >On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake
> >wrote:
> >>linuxhiker: git interface! Bug tracker for this anywhere?
> >
> >Potential answer: Yes. As of now, pgsql-docs for doc issues, and
> >pgsql-bugs for actual
On 1/5/16 8:19 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
Which doesn't help anyone, because neither of those provide a list
of "hey, here's stuff you could do to contribute". The closest we
come to that is the TODO, which isn't well known and has almost no
items for
On Wed, Jan 6, 2016 at 7:47 AM, Michael Paquier
wrote:
> By the way, it is definitely wiser to wait for after the release of
> 9.5.0 to push that or something similar...
And I have added an entry in the CF app, let's not lose track of this item:
https://commitfest.postgresql.org/9/473/
--
Michae
Jim, all,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> Which doesn't help anyone, because neither of those provide a list
> of "hey, here's stuff you could do to contribute". The closest we
> come to that is the TODO, which isn't well known and has almost no
> items for newbies (and the newbie
On 01/05/2016 04:53 PM, Michael Paquier wrote:
On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake wrote:
Hello,
So I was on #postgresql today. I convinced a newer user that they could
easily contribute to PostgreSQL even if it was just doc patches. I described
the basic workflow and the individua
On 1/5/16 6:53 PM, Michael Paquier wrote:
On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake wrote:
So I was on #postgresql today. I convinced a newer user that they could
easily contribute to PostgreSQL even if it was just doc patches. I described
the basic workflow and the individual was excited
Petr Korobeinikov writes:
> At the moment schemas used as single-level namespaces.
> It's quite convenient in large databases.
> But error messages doesnât contain schema names.
> I have done a little patch with schema-qualified relation names in error
> messages that produced by foreign key c
I wrote:
> I still think however that search-path-based lookup of default encoding
> conversions is a Bad Idea, and that we only ought to allow one default
> conversion to exist for any pair of encodings.
> I realized that we could implement that without too much trouble by
> redefining pg_convers
Hackers,
At the moment schemas used as single-level namespaces.
It's quite convenient in large databases.
But error messages doesn’t contain schema names.
I have done a little patch with schema-qualified relation names in error
messages that produced by foreign key constraints and triggers.
Pat
On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake wrote:
> Hello,
>
> So I was on #postgresql today. I convinced a newer user that they could
> easily contribute to PostgreSQL even if it was just doc patches. I described
> the basic workflow and the individual was excited.
>
> His first question?
>
On Wed, Jan 6, 2016 at 2:03 AM, Tom Lane wrote:
> I wrote:
>> Michael Paquier writes:
>>> So, here are the commands that still remain with TailMatches to cover
>>> this case, per gram.y:
>>> - CREATE TABLE
>>> - CREATE INDEX
>>> - CREATE VIEW
>>> - GRANT
>>> - CREATE TRIGGER
>>> - CREATE SEQUENCE
On Wed, Jan 6, 2016 at 12:08 AM, Tom Lane wrote:
> konstantin knizhnik writes:
> > 1. The cost compared in grouping_planner doesn't take in account price
> of get_authorized_users - it is not changed when I am altering function
> cost. Is it correct behavior?
>
> The general problem of accountin
On Tue, Jan 5, 2016 at 10:24 PM, Michael Paquier
wrote:
> On Tue, Jan 5, 2016 at 7:49 PM, Haribabu Kommi
> wrote:
>> On Sat, Dec 19, 2015 at 12:54 AM, Michael Paquier
>> wrote:
>>> On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas wrote:
On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier
w
On Tue, Jan 5, 2016 at 2:50 PM, Michael Paquier
wrote:
> On Tue, Jan 5, 2016 at 2:27 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> The patch would put the buildfarm in red as it is incomplete anyway,
>>> with MSVC what is used instead of dynloader.h is
>>> port/dynloader/win32.h. Instead of
On Tue, Jan 5, 2016 at 11:24 PM, Chapman Flack wrote:
> On 01/05/2016 09:18 AM, Chapman Flack wrote:
>> On 01/05/2016 12:53 AM, Michael Paquier wrote:
>>
>>> That's not a mandatory fix, but I think we had better do it. As long
>>> as dynloader.h is copied in include/, there is no need to keep the
Hello,
So I was on #postgresql today. I convinced a newer user that they could
easily contribute to PostgreSQL even if it was just doc patches. I
described the basic workflow and the individual was excited.
His first question?
linuxhiker: git interface! Bug tracker for this anywhere?
J
Pavel Stehule wrote:
> Hi
>
> 2015-11-19 3:27 GMT+01:00 Marko Tiikkaja :
>
> > Hi,
> >
> > As suggested in 5643125e.1030...@joh.to, here's a patch for extracting
> > the scale out of a numeric.
> >
> > This is 2016-01 CF material, but if someone wants to bas^H^H^Hsay nice
> > things in the meanwh
I wrote:
> What is the point of pg_conversion.condefault (the flag that says whether
> a conversion is "default")? AFAICS, there is absolutely no way to invoke
> a conversion that is not default, which means we might as well eliminate
> the concept.
> I do not see a lot of point in the namespacin
konstantin knizhnik writes:
> 1. The cost compared in grouping_planner doesn't take in account price of
> get_authorized_users - it is not changed when I am altering function cost. Is
> it correct behavior?
The general problem of accounting for tlist eval cost is not handled very
well now, but
Christoph Berg writes:
> Nod. Attached is a patch that covers all relevant $(wildcard)
> occurrences in Makefiles for devel.
Applied back to 9.3, which is as far as any of these cases exist.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Michael Paquier wrote:
> On Mon, Dec 7, 2015 at 11:37 PM, Fujii Masao wrote:
>
> > The latest patch has another problem; pg_receivexlog trying to connect to
> > the PostgreSQL >= 9.4 always reports the following message unexpectedly.
> >
> > could not identify system: got 1 rows and 4 fields, exp
Petr Korobeinikov writes:
> 2016-01-05 21:04 GMT+03:00 Tom Lane :
>> (I did make some small adjustments --- in this usage, PG_GETARG_TEXT_PP
>> is good enough and likely a bit more efficient than PG_GETARG_TEXT_P.)
> Also I forgot to bump catalog version up. My mishit.
No, submitted patches gene
2016-01-05 21:04 GMT+03:00 Tom Lane :
> (I did make some small adjustments --- in this usage, PG_GETARG_TEXT_PP
> is good enough and likely a bit more efficient than PG_GETARG_TEXT_P.)
>
Also I forgot to bump catalog version up. My mishit.
What is the point of pg_conversion.condefault (the flag that says whether
a conversion is "default")? AFAICS, there is absolutely no way to invoke
a conversion that is not default, which means we might as well eliminate
the concept.
I do not see a lot of point in the namespacing of encoding conve
Petr Korobeinikov writes:
>> - Modify the functions in regproc.c. Take a look at how other text input
>> functions work to see what needs to happen here (you'll want to use
>> text_to_cstring() as part of that.)
>>
>> - Modify the appropriate entries in src/include/catalog/pg_proc.h
> Let me try
Alvaro Herrera wrote:
> I'm gonna push this to master only, which means you won't be able to
> rely on pg_shseclabel until 9.6.
Pushed, with one cosmetic change (update comment on formrdesc). I also
bumped the catversion, but didn't verify whether this is critical.
--
Álvaro Herrera
I wrote:
> Michael Paquier writes:
>> So, here are the commands that still remain with TailMatches to cover
>> this case, per gram.y:
>> - CREATE TABLE
>> - CREATE INDEX
>> - CREATE VIEW
>> - GRANT
>> - CREATE TRIGGER
>> - CREATE SEQUENCE
>> New patches are attached.
> I've reviewed and committed
On Tue, Jan 5, 2016 at 04:53:26PM +0100, Andres Freund wrote:
> On 2016-01-05 10:48:43 -0500, Bruce Momjian wrote:
> > On Tue, Jan 5, 2016 at 04:42:24PM +0100, Andres Freund wrote:
> > > On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> > > > On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Fr
On Tue, Jan 5, 2016 at 04:42:24PM +0100, Andres Freund wrote:
> On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> > On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> > > On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> > > Yes? But it's ok sizewise on the common platforms?
>
On 2016-01-05 10:48:43 -0500, Bruce Momjian wrote:
> On Tue, Jan 5, 2016 at 04:42:24PM +0100, Andres Freund wrote:
> > On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> > > On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> > > > On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
On Sun, Jan 3, 2016 at 11:25 AM, Erik Rijkers wrote:
> On 2016-01-03 10:06, Magnus Hagander wrote:
>
>> On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers wrote:
>>
>>> an erroneous ''. It should be ''.
>>>
>>
> Is there a particular thing you're trying to parse the data out for? As in
>> is there som
On 2016-01-05 10:40:13 -0500, Bruce Momjian wrote:
> On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> > On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> > Yes? But it's ok sizewise on the common platforms?
>
> What is the uncommon part? I guess I missed that.
http://archives.
On Tue, Jan 5, 2016 at 04:31:15PM +0100, Andres Freund wrote:
> On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> > On Sun, Dec 13, 2015 at 12:35:34PM +0100, Andres Freund wrote:
> > > > > One thing to call out is that an "oversized" s_lock can now make
> > > > > BufferDesc exceed 64 bytes, rig
On 2016-01-05 10:28:25 -0500, Bruce Momjian wrote:
> On Sun, Dec 13, 2015 at 12:35:34PM +0100, Andres Freund wrote:
> > > > One thing to call out is that an "oversized" s_lock can now make
> > > > BufferDesc exceed 64 bytes, right now that's just the case when it's
> > > > larger than 4 bytes. I'm
On Sun, Dec 13, 2015 at 12:35:34PM +0100, Andres Freund wrote:
> > > One thing to call out is that an "oversized" s_lock can now make
> > > BufferDesc exceed 64 bytes, right now that's just the case when it's
> > > larger than 4 bytes. I'm not sure if that's cause for real concern,
> > > given tha
Christoph Berg writes:
> Re: Alvaro Herrera 2016-01-04 <20160104175623.GA170910@alvherre.pgsql>
>> I don't see any other $(wildcard) used to build executables; it's used
>> for tests and flags in many places, but that shouldn't matter.
> Nod. Attached is a patch that covers all relevant $(wildcar
On Tue, Jan 5, 2016 at 8:54 AM, Jesper Pedersen
wrote:
> LWLock *
> GetLWLockAddinTranche(const char *tranche_name)
>
> would be nicer to work with for extensions IMHO. Not likely worth the
> trouble though.
That change would be easy to make, but would tend to make performance
worse for anyone wh
Hi hackers,
I want to ask two questions about PostgreSQL optimizer.
I have the following query:
SELECT o.id as id,s.id as sid,o.owner,o.creator,o.parent_id as
dir_id,s.mime_id,m.c_type,s.p_file,s.mtime,o.ctime,o.name,o.title,o.size,o.deleted,la.otime,la.etime,uo.login
as owner_login,uc.login a
On 01/05/2016 12:53 AM, Michael Paquier wrote:
> That's not a mandatory fix, but I think we had better do it. As long
> as dynloader.h is copied in include/, there is no need to keep the
> tweak of dfmgr.c to include the definitions those routines.
Looking at what you changed, all becomes clear.
On 01/05/2016 09:18 AM, Chapman Flack wrote:
> On 01/05/2016 12:53 AM, Michael Paquier wrote:
>
>> That's not a mandatory fix, but I think we had better do it. As long
>> as dynloader.h is copied in include/, there is no need to keep the
>> tweak of dfmgr.c to include the definitions those routine
On 01/05/2016 08:04 AM, Amit Kapila wrote:
I am not aware of such cases, however the reason I have kept it was for
backward-compatability, but now I have removed it in the attached patch.
Apart from that, I have updated the docs to reflect the changes related
to new API's.
xfunc.sgml:
+
On Mon, Jan 4, 2016 at 8:28 PM, Robert Haas wrote:
>
> On Mon, Jan 4, 2016 at 1:20 AM, Amit Kapila
wrote:
> > On Mon, Jan 4, 2016 at 4:49 AM, Robert Haas
wrote:
> >> On Thu, Dec 31, 2015 at 3:36 AM, Amit Kapila
> >> wrote:
> >> > LWLock *LWLockAssignFromTranche(const char *tranche_name) will
>
On Wed, Dec 16, 2015 at 11:41 PM, Tom Lane wrote:
> Robert Haas writes:
> > I like option #2. I don't really have a strong reason for that, but
> > it feels intuitive to me that we err on the side of using remote
> > estimates when in doubt.
>
> If we believe that, why isn't the default value o
It seems there is a redundant word "function" in
doc/ref/create_tranform.sgml. Patch attached.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
diff --git a/doc/src/sgml/ref/create_transform.sgml b/doc/src/sgml/ref/cre
On Tue, Jan 5, 2016 at 7:49 PM, Haribabu Kommi wrote:
> On Sat, Dec 19, 2015 at 12:54 AM, Michael Paquier
> wrote:
>> On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas wrote:
>>> On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier
>>> wrote:
On Tue, Dec 15, 2015 at 5:27 AM, Gurjeet Singh wrote:
>>
On Sat, Dec 19, 2015 at 12:54 AM, Michael Paquier
wrote:
> On Fri, Dec 18, 2015 at 8:39 AM, Robert Haas wrote:
>> On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier
>> wrote:
>>> On Tue, Dec 15, 2015 at 5:27 AM, Gurjeet Singh wrote:
The function, maybe. But emitting an all-nulls row from a vi
On Tue, Jan 5, 2016 at 10:39 AM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
> Hackers,
>
> It looks like there's an inconsistency in error handling during
> START_REPLICATION command of replication protocol:
>
> $ psql postgres://localhost/psycopg2test?replication=database
> psql (9
Re: Alvaro Herrera 2016-01-04 <20160104175623.GA170910@alvherre.pgsql>
> > https://reproducible.debian.net/dbd/unstable/armhf/postgresql-9.4_9.4.5-2.diffoscope.html
9.5 was already tested as well, I just couldn't find the link
yesterday:
https://reproducible.debian.net/rb-pkg/experimental/armhf/p
Hackers,
It looks like there's an inconsistency in error handling during
START_REPLICATION command of replication protocol:
$ psql postgres://localhost/psycopg2test?replication=database
psql (9.6devel)
Type "help" for help.
psycopg2test=# IDENTIFY_SYSTEM;
systemid | timeline | xlogp
Hi,
On 12/23/2015 09:33 PM, Jeff Janes wrote:
On Mon, Dec 21, 2015 at 11:51 AM, Tomas Vondra
wrote:
On 12/21/2015 07:41 PM, Jeff Janes wrote:
On Sat, Dec 19, 2015 at 3:19 PM, Tomas Vondra
wrote:
...
So both patches seem to do the trick, but (2) is faster. Not sure
if this is expected
On 1/4/16, Alvaro Herrera wrote:
> Vitaly Burovoy wrote:
>
>> Majority of the votes for NULL for "other things" except epoch.
>> Nobody answers about differences between monotonic and oscillating
>> values.
>>
>> I suppose behavior of monotonic values (julian, century, decade,
>> isoyear, millenni
62 matches
Mail list logo
