On 27 August 2012 20:26, Dean Rasheed wrote:
> Here's an updated WIP patch which I'll add to the next commitfest.
Re-sending gzipped (apparently the mail system corrupted it last time).
Regards,
Dean
auto-update-views.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers ma
On Thu, Jul 12, 2012 at 6:35 AM, Peter Eisentraut 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 shredded by
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
Bruce Momjian writes:
> On Fri, Mar 9, 2012 at 04:36:08PM -0800, David E. Wheeler wrote:
>> A bigint key is displayed with its
>> high-order half in the classid column, its low-order
>> half
>> in the objid column, and objsubid equal
>> !to 1. The original bigint value can be
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 th
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?
>
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, the<1 usec is where you want to
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 k
On Mon, Aug 27, 2012 at 07:43:49PM -0400, Tom Lane wrote:
> Bruce Momjian 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 Mon, Aug 27, 2012 at 07:43:49PM -0400, Tom Lane wrote:
> Bruce Momjian 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
> con
On Mon, Aug 27, 2012 at 09:59:10PM -0400, Tom Lane wrote:
> Bruce Momjian 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
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
Bruce Momjian 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 the lock
On Mon, Aug 27, 2012 at 07:39:35PM -0400, Tom Lane wrote:
> Alvaro Herrera 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 (o
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 a
Bruce Momjian 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 TODO entry
Bruce Momjian 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.
There's also the bi
Alvaro Herrera 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 get confused. If we ke
Robert Haas writes:
> On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane 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 problem with this is that i
Robert Haas 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 candidates and do
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
> wrote
On Mon, Aug 27, 2012 at 04:42:34PM -0400, Robert Haas wrote:
> On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian 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
-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 th
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 wrote:
> > Bruce Momjian writes:
> >> I have developed the attached patch to report a zero-length file, as you
> >> suggested.
> >
> > DIRECTORY_LOCK_FILE is entirely incorrect there
On Mon, Aug 27, 2012 at 1:50 PM, Pavel Stehule 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 now.
Who said anyt
On Mon, Aug 27, 2012 at 4:29 PM, Tom Lane wrote:
> Bruce Momjian 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
> exis
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:03 PM, Tom Lane wrote:
> Bruce Momjian 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
On Mon, Aug 27, 2012 at 9:48 AM, Bruce Momjian 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 question of
adding do
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 necessary
On Mon, Aug 27, 2012 at 1:18 PM, Bruce Momjian 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. first line
Bruce Momjian writes:
> On Wed, Jan 25, 2012 at 11:30:49AM -0500, Tom Lane wrote:
>> hubert depesz lubaczewski 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
>> obvi
On Mon, Aug 27, 2012 at 04:37:25PM -0400, Tom Lane wrote:
> Bruce Momjian 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 a
Bruce Momjian 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 second poi
On Mon, Aug 27, 2012 at 9:18 AM, Bruce Momjian wrote:
> Was this addressed?
See commit d6d5f67b5b98b1685f9158e9d00a726afb2ae789.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Bruce Momjian 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 way, it's not
On Mon, Aug 27, 2012 at 09:10:35PM +0100, Dean Rasheed wrote:
> On 27 August 2012 20:42, Bruce Momjian wrote:
> > On Mon, Aug 27, 2012 at 08:35:00PM +0100, Dean Rasheed wrote:
> >> On 27 August 2012 19:09, Bruce Momjian wrote:
> >> >
> >> > Any status on this?
> >> >
> >>
> >> Tom took care of it
On Mon, Aug 27, 2012 at 04:03:05PM -0400, Tom Lane wrote:
> Bruce Momjian 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
>
On 27 August 2012 20:42, Bruce Momjian wrote:
> On Mon, Aug 27, 2012 at 08:35:00PM +0100, Dean Rasheed wrote:
>> On 27 August 2012 19:09, Bruce Momjian wrote:
>> >
>> > Any status on this?
>> >
>>
>> Tom took care of it in the last commitfest -
>> http://archives.postgresql.org/pgsql-hackers/2012
Bruce Momjian 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 smallints
On Mon, Aug 27, 2012 at 08:35:00PM +0100, Dean Rasheed wrote:
> On 27 August 2012 19:09, Bruce Momjian 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
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 Haa
Fujii Masao 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 index entries twic
On 27 August 2012 19:09, Bruce Momjian 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 mailing list (pgsql
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 Rijkers wrote:
> >>On Sun, February 19, 2012 06:27, Robert Haas wrote:
> >>>On Sat, Feb 18, 2012 at 11:58 AM, Erik Rijkers wrote:
> pg_re
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
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
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 wrote:
>
> On Sat, Feb 11, 2012 at 9:06 PM, Vik Reykja wrote:
> > I decided to take
>
> 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 wil
On Sat, Aug 25, 2012 at 1:30 PM, David Johnston 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 whatever log
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
On Sun, Aug 26, 2012 at 9:45 AM, Bruce Momjian 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 flag
On Mon, Aug 27, 2012 at 12:39:02PM -0400, Robert Haas wrote:
> On Sat, Aug 25, 2012 at 10:48 PM, Bruce Momjian 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 wrote:
> >> > FYI, I am planning to go ahead and package this
On Mon, Aug 27, 2012 at 12:40:37PM -0400, Tom Lane wrote:
> Bruce Momjian 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 beca
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:
http://2012.pgday.it/ca
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
g
Bruce Momjian 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,
>> which base
On Sat, Aug 25, 2012 at 10:48 PM, Bruce Momjian 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 wrote:
>> > FYI, I am planning to go ahead and package this tool in /contrib for PG
>> > 9.3.
>>
>> Isn't this exactly what we a
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 cha
Brendan Byrd 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 Wed, Jan 25, 2012 at 11:30:49AM -0500, Tom Lane wrote:
> hubert depesz lubaczewski 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 maybe the
On Mon, Aug 27, 2012 at 05:44:32PM +0300, Marti Raudsepp wrote:
> On Mon, Aug 27, 2012 at 4:50 PM, Bruce Momjian 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 thorou
2012/8/23 Tom Lane :
> Fujii Masao writes:
>> On Wed, Aug 22, 2012 at 12:59 AM, Kasahara Tatsuhito
>> wrote:
>>> The latest document (doc/src/sgml/ddl.sgml) says
>>> ===
>>> 2974
>>> 2975
>>> 2976
>>> 2977 Constraint exclusion only works wh
On Mon, Aug 27, 2012 at 4:50 PM, Bruce Momjian 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:
http://archives.postgresql.org/pgsql-hackers/2012
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
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 s
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
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 wrote:
> > archive_command and restore_command describe how to ship WAL files
> > to/from
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 to the
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 goe
On Fri, Jan 27, 2012 at 01:45:28PM -0500, Robert Haas wrote:
> On Sat, Jan 7, 2012 at 12:30 PM, Tom Lane 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
> > sta
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 worr
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 th
Peter Eisentraut 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 settings.
Than
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
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.
Kaigai-san,
On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai 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.
Attached is a tar
Kohei KaiGai wrote:
> 2012/8/25 Robert Haas :
>> On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai
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.
>> It strikes me as incredibl
78 matches
Mail list logo