Kohei KaiGai wrote:
2012/8/25 Robert Haas robertmh...@gmail.com:
On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai kai...@kaigai.gr.jp
wrote:
It is a responsibility of FDW extension (and DBA) to ensure each
foreign-row has a unique identifier that has 48-bits width integer
data type in maximum.
Kaigai-san,
On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The patched portion at contrib/file_fdw.c does not make sense
actually. It just prints messages for each invocation.
It is just a proof-of-concept to show possibility of implementation
based on real RDBMS.
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;hb=master#l4940
The missing_ok property should be true. Just something I noticed
when browsing the code. It appears to be a new language feature, so
it probably hasn't been noticed by the general public yet.
Hi,
I'm back to PostgreSQL development concerns after some distraction here.
First, thanks for pushing the patch to commit!
I've been reviewing your changes and here's a very small patch with some
details I would have spelled out differently. See what you think, I
mostly needed to edit some code
Peter Eisentraut pete...@gmx.net writes:
This might be useful for some people. Here is an emacs configuration
for perl-mode that is compatible with the new perltidy settings. Note
that the default perl-mode settings produce indentation that will be
completely shredded by the new perltidy
On 27.08.2012 15:18, Amit kapila wrote:
I have implemented the WAL Reduction Patch for the case of HOT Update as
pointed out by Simon and Robert. In this patch it only goes for Optimized WAL
in case of HOT Update with other restrictions same as in previous patch.
The performance numbers for
On 24.08.2012 18:51, Heikki Linnakangas wrote:
On 20.08.2012 00:31, Alexander Korotkov wrote:
New version of patch.
* Collect new stakind STATISTIC_KIND_BOUNDS_HISTOGRAM, which is lower and
upper bounds histograms combined into single ranges array, instead
of STATISTIC_KIND_HISTOGRAM.
One
On Fri, Jan 27, 2012 at 01:45:28PM -0500, Robert Haas wrote:
On Sat, Jan 7, 2012 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I feel like this is a trick question, but I'll ask anyway: Can't we
just ignore ANALYZE?
AFAICS, no. ANALYZE will run user-defined code: not only user-supplied
From: Heikki Linnakangas [mailto:heikki.linnakan...@enterprisedb.com]
Sent: Monday, August 27, 2012 5:58 PM
To: Amit kapila
On 27.08.2012 15:18, Amit kapila wrote:
I have implemented the WAL Reduction Patch for the case of HOT Update as
pointed out by Simon and Robert. In this patch it only goes
On Mon, Jan 9, 2012 at 11:31:02AM -0600, Kevin Grittner wrote:
I found that I needed to adjust the command given in the README file
for pgindent. Trivial patch attached.
The one other issue I ran into in following the latest pgindent
instructions was that I had to add #include stdlib.h to
Where are we on this?
---
On Mon, Jan 16, 2012 at 01:52:35AM +, Simon Riggs wrote:
On Fri, Dec 16, 2011 at 3:01 PM, Simon Riggs si...@2ndquadrant.com wrote:
archive_command and restore_command describe how to ship
Where are we on this?
---
On Mon, Jan 16, 2012 at 07:06:45PM +0200, Marti Raudsepp wrote:
Hi list,
Here's v6 of my expression caching patch. The only change in v6 is
added expression cost estimation in costsize.c. I'm
Hi,
we have issues with compound words in tsearch2 using the german (ispell)
dictionary. This has been discussed before but there is no real solution
using the recommended german dictionary at
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2 (convert old
openoffice dict file to ispell
On Mon, Aug 27, 2012 at 5:00 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 24.08.2012 18:51, Heikki Linnakangas wrote:
On 20.08.2012 00:31, Alexander Korotkov wrote:
New version of patch.
* Collect new stakind STATISTIC_KIND_BOUNDS_**HISTOGRAM, which is lower
and
On Mon, Aug 27, 2012 at 4:50 PM, Bruce Momjian br...@momjian.us wrote:
Where are we on this?
TL;DR: Got a review, requires substantial work, current github branch
is slightly broken, will get back to this soon.
Tom Lane sent a thorough review of the patch here:
2012/8/23 Tom Lane t...@sss.pgh.pa.us:
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Aug 22, 2012 at 12:59 AM, Kasahara Tatsuhito
kasahara.tatsuh...@gmail.com wrote:
The latest document (doc/src/sgml/ddl.sgml) says
===
2974itemizedlist
2975
On Mon, Aug 27, 2012 at 05:44:32PM +0300, Marti Raudsepp wrote:
On Mon, Aug 27, 2012 at 4:50 PM, Bruce Momjian br...@momjian.us wrote:
Where are we on this?
TL;DR: Got a review, requires substantial work, current github branch
is slightly broken, will get back to this soon.
Tom Lane sent
On Wed, Jan 25, 2012 at 11:30:49AM -0500, Tom Lane wrote:
hubert depesz lubaczewski dep...@depesz.com writes:
anyway - the point is that in \df date_part(, timestamp) says it's
immutable, while it is not.
Hmm, you're right. I thought we'd fixed that way back when, but
obviously not. Or
Brendan Byrd p...@resonatorsoft.org writes:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/parser/gram.y;hb=master#l4940
The missing_ok property should be true.
[ rolls eyes ] Apparently that patch wasn't ever, you know, tested?
Will fix, thanks for spotting it!
On Thu, Feb 2, 2012 at 10:33:24AM +0300, Dmitriy Igrishin wrote:
Hey all,
Could you tell me please an objective reason why PQunescapeBytea()
returns unsigned char* rather than just char* ?
I am asking because a bit confused. How this intermixes with LO's API,
which based on signed chars
On Sat, Aug 25, 2012 at 10:48 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Aug 20, 2012 at 03:11:51PM -0400, Robert Haas wrote:
On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian br...@momjian.us wrote:
FYI, I am planning to go ahead and package this tool in /contrib for PG
9.3.
Isn't
Bruce Momjian br...@momjian.us writes:
On Thu, Feb 2, 2012 at 10:33:24AM +0300, Dmitriy Igrishin wrote:
Could you tell me please an objective reason why PQunescapeBytea()
returns unsigned char* rather than just char* ?
I am asking because a bit confused. How this intermixes with LO's API,
Hi,
After pg_trgm extracts the trigrams as GIN index keys, generate_trgm()
removes duplicate index keys, to avoid generating redundant index entries.
Also ginExtractEntries() which is the caller of pg_trgm does the same thing.
Why do we need to remove GIN index entries twice? I think that we can
The sixth edition of the Italian PostgreSQL Day (PGDay.IT 2012) will be
held on November 23 in Prato, Tuscany.
The International Call for Papers is now open. Talks and presentations
in English are accepted.
Information in English for papers submission is available at:
On Mon, Aug 27, 2012 at 12:40:37PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Feb 2, 2012 at 10:33:24AM +0300, Dmitriy Igrishin wrote:
Could you tell me please an objective reason why PQunescapeBytea()
returns unsigned char* rather than just char* ?
I am asking
On Mon, Aug 27, 2012 at 12:39:02PM -0400, Robert Haas wrote:
On Sat, Aug 25, 2012 at 10:48 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Aug 20, 2012 at 03:11:51PM -0400, Robert Haas wrote:
On Thu, Aug 16, 2012 at 10:28 PM, Bruce Momjian br...@momjian.us wrote:
FYI, I am planning to go
On Sun, Aug 26, 2012 at 9:45 AM, Bruce Momjian br...@momjian.us wrote:
On Thu, Dec 29, 2011 at 11:37:22AM +0900, Manabu Ori wrote:
a configure test only proves whether the build machine can deal
with the flag, not whether the machine the executables will
ultimately run on knows what the
On Mon, Aug 27, 2012 at 01:18:51PM -0400, Bruce Momjian wrote:
This should make the output clearer to eyeball for problems --- a good
timing has a high percentage on the first line, rather than on the last
line.
I guess I'm not sure the output format is an improvement. I wouldn't
On Sat, Aug 25, 2012 at 1:30 PM, David Johnston pol...@yahoo.com wrote:
My internals knowledge is basically zero but it would seem that If you
simply wanted the end-of-transaction result you could just record nothing
during the transaction and then copy whatever values are present at commit
to
Well, the point is that I think many people have requirements that are
(1) different from each other and (2) more complicated than the
simplest case we can come up with. Some people will want to log the
application user (or some other piece of extra data); others won't.
Some people will
Any status on this?
---
On Mon, Feb 13, 2012 at 04:34:51PM +0100, Vik Reykja wrote:
On Mon, Feb 13, 2012 at 15:25, Robert Haas robertmh...@gmail.com wrote:
On Sat, Feb 11, 2012 at 9:06 PM, Vik Reykja
Excerpts from Alvaro Herrera's message of vie ago 24 11:44:33 -0400 2012:
Actually it seems better to just get rid of the extra varargs function
and just have a single exec_prog. The extra NULL argument is not
troublesome enough, it seems. Updated version attached.
Applied (with some very
On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote:
Here's yet another case where the current rules are thoroughly disagreeable.
rhaas=# create or replace function z(smallint) returns smallint as
$$select $1+1$$ language sql;
ERROR: return type mismatch in function declared to
On Sun, Feb 19, 2012 at 10:25:55AM -0500, Andrew Dunstan wrote:
On 02/19/2012 08:02 AM, Robert Haas wrote:
On Sun, Feb 19, 2012 at 1:18 AM, Erik Rijkerse...@xs4all.nl wrote:
On Sun, February 19, 2012 06:27, Robert Haas wrote:
On Sat, Feb 18, 2012 at 11:58 AM, Erik Rijkerse...@xs4all.nl
On 27 August 2012 19:09, Bruce Momjian br...@momjian.us wrote:
Any status on this?
Tom took care of it in the last commitfest -
http://archives.postgresql.org/pgsql-hackers/2012-06/msg01075.php
I think that todo item can now be marked as done.
Regards,
Dean
--
Sent via pgsql-hackers
Fujii Masao masao.fu...@gmail.com writes:
After pg_trgm extracts the trigrams as GIN index keys, generate_trgm()
removes duplicate index keys, to avoid generating redundant index entries.
Also ginExtractEntries() which is the caller of pg_trgm does the same thing.
Why do we need to remove GIN
Added to TODO:
Allow reporting of stalls due to wal_buffer wrap-around
http://archives.postgresql.org/pgsql-hackers/2012-02/msg00826.php
---
On Sun, Feb 19, 2012 at 12:24:12AM -0500, Robert
On Mon, Aug 27, 2012 at 08:35:00PM +0100, Dean Rasheed wrote:
On 27 August 2012 19:09, Bruce Momjian br...@momjian.us wrote:
Any status on this?
Tom took care of it in the last commitfest -
http://archives.postgresql.org/pgsql-hackers/2012-06/msg01075.php
I think that todo item can
Bruce Momjian br...@momjian.us writes:
On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote:
Come on, really? Note that the above example works without casts if
you use int *or* bigint *or* numeric, but not smallint. That could be
fixed by causing sufficiently-small integers to lex as
On 27 August 2012 20:42, Bruce Momjian br...@momjian.us wrote:
On Mon, Aug 27, 2012 at 08:35:00PM +0100, Dean Rasheed wrote:
On 27 August 2012 19:09, Bruce Momjian br...@momjian.us wrote:
Any status on this?
Tom took care of it in the last commitfest -
On Mon, Aug 27, 2012 at 04:03:05PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote:
Come on, really? Note that the above example works without casts if
you use int *or* bigint *or* numeric, but not smallint. That
On Mon, Aug 27, 2012 at 09:10:35PM +0100, Dean Rasheed wrote:
On 27 August 2012 20:42, Bruce Momjian br...@momjian.us wrote:
On Mon, Aug 27, 2012 at 08:35:00PM +0100, Dean Rasheed wrote:
On 27 August 2012 19:09, Bruce Momjian br...@momjian.us wrote:
Any status on this?
Tom took
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report a zero-length file, as you
suggested.
DIRECTORY_LOCK_FILE is entirely incorrect there.
Taking a step back, I don't think this message is much better than the
existing behavior of reporting bogus data. Either
On Mon, Aug 27, 2012 at 9:18 AM, Bruce Momjian br...@momjian.us wrote:
Was this addressed?
See commit d6d5f67b5b98b1685f9158e9d00a726afb2ae789.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
Bruce Momjian br...@momjian.us writes:
On Mon, Aug 27, 2012 at 09:10:35PM +0100, Dean Rasheed wrote:
It's listed under https://wiki.postgresql.org/wiki/Todo#Referential_Integrity
I think the main points mentioned there have now all been taken care of.
Ah, got it. Marked as done.
IMO the
On Mon, Aug 27, 2012 at 04:37:25PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, Aug 27, 2012 at 09:10:35PM +0100, Dean Rasheed wrote:
It's listed under
https://wiki.postgresql.org/wiki/Todo#Referential_Integrity
I think the main points mentioned there have now
Bruce Momjian br...@momjian.us writes:
On Wed, Jan 25, 2012 at 11:30:49AM -0500, Tom Lane wrote:
hubert depesz lubaczewski dep...@depesz.com writes:
anyway - the point is that in \df date_part(, timestamp) says it's
immutable, while it is not.
Hmm, you're right. I thought we'd fixed that
On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian br...@momjian.us wrote:
He wrote it that way to allow for simpler C code --- he could just start
from 31 and keeping skipping entries until he hit a non-zero.
My format makes it easy to see which line should have the majority of
the entries, e.g.
Hi,
This year Ecuador's PGDay will be held at Quito city on November 17th.
We are currently accepting talks/workshops.
These could go from basic to advanced. We do not require academic-like papers.
If you are doing something interesting with PostgreSQL, please send a
proposal. It's not
On Mon, Aug 27, 2012 at 9:48 AM, Bruce Momjian br...@momjian.us wrote:
Where are we on this?
It didn't make it into 9.2, and the patch hasn't been resubmitted for
9.3. It's still not really 100% clear to me what problem it lets us
solve that we can't solve otherwise. Maybe that is just a
On Mon, Aug 27, 2012 at 4:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Fri, Feb 17, 2012 at 02:52:20PM -0500, Robert Haas wrote:
Come on, really? Note that the above example works without casts if
you use int *or* bigint *or* numeric, but not smallint.
Hello all,
the EDB one-click installer has a slightly annoying bug in its
pg_env.bat script:
@SET PATH=C:\Program Files\PostgreSQL\9.1\bin;%PATH%
PATH entries should not be quoted. As it is, every time a program is
started from this path, I get a message along the lines of
could
On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report a zero-length file, as you
suggested.
DIRECTORY_LOCK_FILE is entirely incorrect there.
Taking a step back, I don't think this message is
On Mon, Aug 27, 2012 at 1:50 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I can't agree - why we need a some simple solution based on tools,
that are available now? I don't think we have to be hurry in support
own proprietary solutions - when isn't difficult do it just with
available tools
Excerpts from Robert Haas's message of lun ago 27 18:02:06 -0400 2012:
On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report a zero-length file, as you
suggested.
DIRECTORY_LOCK_FILE is
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane replied:
Come on, really? Note that the above example works without casts if
you use int *or* bigint *or* numeric, but not smallint. That could be
fixed by causing sufficiently-small integers to lex as smallints,
Is there any
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian br...@momjian.us wrote:
He wrote it that way to allow for simpler C code --- he could just start
from 31 and keeping skipping entries until he hit a non-zero.
My format makes it
I need someone to review this patch for 9.3. We have already missed
fixing this for 9.2.
---
On Thu, Jun 21, 2012 at 10:53:43PM +0400, Alexander Korotkov wrote:
On Wed, Feb 22, 2012 at 5:56 PM, Alexander Korotkov
Robert Haas robertmh...@gmail.com writes:
I agree that redefining the lexer behavior is a can of worms. What I
don't understand is why f(2+2) can't call f(smallint) when that's the
only extant f. It seems to me that we could do that without breaking
anything that works today: if you look for
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps something like:
FATAL: lock file foo is empty
HINT: This may mean that another postmaster was starting at the
same time. If not, remove the lock file and try again.
The
Alvaro Herrera alvhe...@2ndquadrant.com writes:
How about having it sleep for a short while, then try again?
I could get behind that, but I don't think the delay should be more than
100ms or so. It's important for the postmaster to acquire the lock (or
not) pretty quickly, or pg_ctl is going to
Bruce Momjian br...@momjian.us writes:
I need someone to review this patch for 9.3. We have already missed
fixing this for 9.2.
So put it in the next commitfest.
FWIW, I looked at this last week, and concluded I didn't have enough
confidence in it to push it into 9.2 at the last minute.
Bruce Momjian br...@momjian.us writes:
On Mon, Aug 27, 2012 at 04:37:25PM -0400, Tom Lane wrote:
IMO the second point is done but the first is not: there's still a
question of whether we could remove the trigger-time checks for equality
now that there's an upstream filter. Possibly break the
Hi All,
I was recently struggling with getting a large crosstab (
http://www.postgresql.org/docs/current/static/tablefunc.html) query to work
and noticed the error messages were not super helpful: return and sql
tuple descriptions are incompatible.
I had to manually take the query into pieces
On Mon, Aug 27, 2012 at 07:39:35PM -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
How about having it sleep for a short while, then try again?
I could get behind that, but I don't think the delay should be more than
100ms or so. It's important for the postmaster to
Bruce Momjian br...@momjian.us writes:
On Mon, Aug 27, 2012 at 07:39:35PM -0400, Tom Lane wrote:
I could get behind that, but I don't think the delay should be more than
100ms or so.
I took Alvaro's approach of a sleep. The file test was already in a
loop that went 100 times. Basically, if
Hello,
I reviewed this v5 of patch:
- https://commitfest.postgresql.org/action/patch_view?id=907
The patch is small and implements a new syntax to CREATE SCHEMA
that allow the creation of a schema be skipped when IF NOT EXISTS is
used.
It was applied to 483c2c1071c45e275782d33d646c3018f02f9f94
On Mon, Aug 27, 2012 at 09:59:10PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, Aug 27, 2012 at 07:39:35PM -0400, Tom Lane wrote:
I could get behind that, but I don't think the delay should be more than
100ms or so.
I took Alvaro's approach of a sleep. The file
On Mon, Aug 27, 2012 at 07:43:49PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I need someone to review this patch for 9.3. We have already missed
fixing this for 9.2.
So put it in the next commitfest.
FWIW, I looked at this last week, and concluded I didn't have
On Mon, Aug 27, 2012 at 07:43:49PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I need someone to review this patch for 9.3. We have already missed
fixing this for 9.2.
So put it in the next commitfest.
Done. I have linked to your comment below too.
On Fri, Mar 9, 2012 at 04:36:08PM -0800, David E. Wheeler wrote:
Hackers,
The documentation for pg_locks says that, for BIGINT advisory locks:
A bigint key is displayed with its high-order half in the classid column,
its low-order half in the objid column
I was in need of knowing
On 08/27/2012 06:20 PM, Bruce Momjian wrote:
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
I don't see why it's better for the first line to have a big number
than the last line. What difference does it make?
When you are looking at that output, the1 usec is where you want to
On Mon, Aug 27, 2012 at 11:13:00PM -0400, Greg Smith wrote:
On 08/27/2012 06:20 PM, Bruce Momjian wrote:
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
I don't see why it's better for the first line to have a big number
than the last line. What difference does it make?
When
I noticed a couple comments that look wrong to me. Patch attached.
Regards,
Jeff Davis
*** a/src/backend/commands/tablecmds.c
--- b/src/backend/commands/tablecmds.c
***
*** 8784,8792 copy_relation_data(SMgrRelation src, SMgrRelation dst,
pfree(buf);
/*
! * If
Bruce Momjian br...@momjian.us writes:
On Fri, Mar 9, 2012 at 04:36:08PM -0800, David E. Wheeler wrote:
A typebigint/type key is displayed with its
high-order half in the structfieldclassid/ column, its low-order
half
in the structfieldobjid/ column, and structfieldobjsubid/
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Bruce Momjian
Added to TODO:
Allow reporting of stalls due to wal_buffer wrap-around
http://archives.postgresql.org/pgsql-hackers/2012-02/msg00826.php
Isn't this indicates that
On Thu, Jul 12, 2012 at 6:35 AM, Peter Eisentraut pete...@gmx.net wrote:
This might be useful for some people. Here is an emacs configuration
for perl-mode that is compatible with the new perltidy settings. Note
that the default perl-mode settings produce indentation that will be
completely
77 matches
Mail list logo
