The following bug has been logged on the website:
Bug reference: 8524
Logged by: Peter Reijnders
Email address: peter.reijnd...@verpeteren.nl
PostgreSQL version: 9.1.9
Operating system: Debian Wheezy
Description:
Hai
I am implementing a postgresql database
On Thu, 2013-10-10 at 19:14 -0400, Bruce Momjian wrote:
> > The changes shown below are incorrect, I think.
> >
> >
> > On 10/2/13 12:00 PM, Bruce Momjian wrote:
> > > *** gen_salt(type text [, iter_count integer
> > > *** 353,359
> > > 12 years
> > >
> > >
The changes shown below are incorrect, I think.
On 10/2/13 12:00 PM, Bruce Momjian wrote:
> *** gen_salt(type text [, iter_count integer
> *** 353,359
> 12 years
>
>
> !md5
> 2345086
> 1 day
> 3 years
> --- 358,364 ---
On Sun, 2013-08-25 at 12:01 -0700, Nick Carenza wrote:
> on os x 10.8.4
>
> installing with homebrew
This is not a problem. Homebrew has the appropriate patches.
There is more discussion about this issue in the mailing list archives.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgre
not directly
issued by the client here.
If this is the behavior we want for SQL functions, that is something
that ought to be highlighted as a special case.
--
Peter Geoghegan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
006ffca9 in BackendStartup (port=0x239e2b0) at postmaster.c:3304
#68 0x006fcacb in ServerLoop () at postmaster.c:1367
#69 0x006fc3c2 in PostmasterMain (argc=2, argv=0x23792a0) at
postmaster.c:1127
#70 0x006676ba in main (argc=2, argv=0x23792a0) at main.c:199
These pg_stat_st
On Mon, 2013-07-01 at 19:27 -0400, Tom Lane wrote:
> I think probably we'd have just not compiled the dependent code, and
> would have found out about it only when somebody complained that peer
> auth didn't work on OpenBSD. Not sure that's really a more attractive
> behavior :-(
That might be t
On 7/1/13 9:19 AM, Tom Lane wrote:
> AFAICT, the result in this case would be that the script comes to the
> wrong conclusion about whether ucred.h is available. Wouldn't that
> result in a build failure, or at least missing features? IOW, don't
> we need to fix this test anyway?
The test needs
On 6/30/13 11:26 AM, Andres Freund wrote:
> If we would treat that warning as an error unconditionally - and I am
> not sure how easy that is given the way it's emitted - users
> encountering them, which usually will be on less common platforms, will
> have to patch configure.in to make things work
On 5/9/13 5:40 PM, Dave Page wrote:
> Whilst working on a build issue with pl/python, I noticed an
> inconsistency in the way the server reacts to attempts to use PLs for
> which the interpreter doesn't exist. Not sure how feasible it would be
> to fix this, but the Python case doesn't seem ideal:
On 5/21/13 6:25 PM, pol...@yahoo.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8174
> Logged by: David Johnston
> Email address: pol...@yahoo.com
> PostgreSQL version: 9.0.13
> Operating system: Ubuntu Linux 10.04
> Description:
>
>
On 5/21/13 3:41 AM, tudorbara...@yahoo.com wrote:
> In pg_hba.conf I have the following setup:
> hostall all laptop md5
>
> Although the hostname gets resolved by the system (LAN DNS server) I still
> get the no pg_hba.conf entry error.
Check that the following works:
$ host
On 5/21/13 2:54 AM, Andrzej Cedro wrote:
> I use PostgeSQL 9.1 32-bit on Windows 7 Professional with Active Directory as
> LDAP.
> I have following configration in pg_hba.conf:
>
> host all all all ldapldapserver=192.168.155.157
> ldapbinddn="CN=aa,OU=b,DC=,DC=" l
Are you using persistent connections from your application? This would hold
the connection to the database. So I think you have 2 choices:
1. Disable persistent connections
2. Increaes MAX_CONNECTIONS in postgresql.conf
From: Bakyaraj K mailto:bakya...@railsfactory.org>>
Date: Friday, May 24
On Tue, May 14, 2013 at 2:47 PM, John R Pierce wrote:
> on a typical unix system, with one user connection active, I see 8 processes
> active at present...
To be fair, you need to use process explorer or something to see
equivalent information on Windows. Most people never will.
--
On 30 March 2013 14:01, wrote:
> env CFLAGS='-O3 -march=native' ./configure --with-segsize=128
Why did you build with a segment size of 128GB? Postgres binaries
built with a non-standard segment size are not widely used.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-bugs
ink you're safe.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Just to let everyone know that I haven't forgotten this. I just don't have
any time to spend on it.
The problem still occurs.
2013/2/20 Peter Kroon
> I've migrated everything to Linux and I'm able to continue my work.
> I'll get back on this next week.
>
>
On Sun, 2013-03-03 at 10:42 -0500, Tom Lane wrote:
> I think the use of str_toupper() is appropriate when processing the
> locale-specific string for a TMDAY specification; but plain DAY is not
> supposed to be locale-dependent, so we probably should use an
> ASCII-only upcasing rule in the non-TM
On Sun, 2013-02-17 at 15:51 +0100, Christian Hammers wrote:
> The postmaster command does not list "--config-file" in its help
It is included under
--NAME=VALUE set run-time parameter
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
On 2/25/13 7:59 PM, adam.tomj...@zuerchertech.com wrote:
> I have a database that uses a user-defined datatype. If the .so file
> implementing that type is missing, pg_dump will fail when dumping a table
> which uses that type, but it will still exit with status 0. The dump file
> will be truncat
On 26 February 2013 21:45, Peter Eisentraut wrote:
> Have each user create their custom domain?
That's likely to be the most effective solution, yes. I'd take the
fact that people haven't been complaining about contrib/isn more as
suggestive of people figuring this out f
On 2/23/13 2:10 PM, Peter Geoghegan wrote:
> But then, contrib/isn also sanitises both ISBN
> ranges and EAN country codes using its own internal database, which
> ought to be kept in lockstep with an external database whose
> maintenance is highly decentralised - regional auth
is correct using SQL, using this simple method:
https://en.wikipedia.org/wiki/EAN-13#Calculation_of_checksum_digit
We actually discussed changing the formatting of isn along the lines
you've discussed, and it was shot down. I'd just like to see it go.
--
Regards,
Peter Geoghegan
--
Sent via pgs
I've migrated everything to Linux and I'm able to continue my work.
I'll get back on this next week.
2013/2/19 Lou Picciano
> Sorry, Peter - I think I'd suggest something different. Start at the
> beginning; do this testing directly from the CLI (psql) on each of t
>you can test your queries from pgAdmin SQL executor
I have already done so.
I'll look into the logs.
2013/2/19 Pavel Stehule
> 2013/2/19 Peter Kroon :
> >>try to use pgAdminIII
> >
> > Could you be more specific?
>
> you can test your queries from pgAd
>try to use pgAdminIII
Could you be more specific?
2013/2/19 Pavel Stehule
> 2013/2/19 Peter Kroon :
> > Where can I check and/or alter this?
>
> try to use pgAdminIII
>
> Regards
>
> Pavel
>
> >
> >
> > 2013/2/19 Lou Picciano
> >>
Where can I check and/or alter this?
2013/2/19 Lou Picciano
> I wonder if there's a difference in the implementation(s) of readline
> buffering?
>
>
> - Original Message -
> From: Peter Kroon
> To: Lou Picciano
> Cc: Michael Paquier , pgsql-bugs@postg
Exceeding length 4679 is a problem. Query results(length) equal or below
this number succeed.
2013/2/19 Peter Kroon
> When there are more then 88 rows in the table like 595 I can run the query
> with success when using: WHERE id BETWEEN 1 AND 88;
> Using LIMIT 88 fails -> ret
When there are more then 88 rows in the table like 595 I can run the query
with success when using: WHERE id BETWEEN 1 AND 88;
Using LIMIT 88 fails -> returns nothing
Selecting all fails as well.
2013/2/19 Peter Kroon
> When there are in __table_to_table more than 88 rows nothin
When there are in __table_to_table more than 88 rows nothing gets returned,
otherwise the query rolls out fine.
2013/2/19 Peter Kroon
> It appears to be a Windows issue only.
> I'll try to post some code.
>
>
> 2013/2/19 Lou Picciano
>
>> Seems your testing fro
of course, I certainly don't know enough to know that the different
> versions of libpq don't present xmlagg output differently!
>
> The experts here will weigh in.
>
> Lou Picciano
>
>
> - Original Message -
> From: Peter Kroon
> Sent: Tue, 19 Feb 2
n I get
no results.
Not sure what to think of this...
2013/2/19 Peter Kroon
> >Don't you have for example problems with the client application you use?
>
> Yes, with 1 table only. I'm not getting any results.
> When I'm on the sql machine via localhost or 192.168
>Don't you have for example problems with the client application you use?
Yes, with 1 table only. I'm not getting any results.
When I'm on the sql machine via localhost or 192.168.1.100 I'm getting
results.
2013/2/19 Michael Paquier
>
>
> On Tue, Feb 19, 201
Also no result with FROM __my_table LIMIT 1;
2013/2/19 Peter Kroon
> Mm..
> The problem only occurs on a specific table in my DB.
>
> --__my_table has 512 rows
>
> SELECT * FROM __my_table; --gives me result
>
> SELECT
> --xmlagg(
> xmlelement(name el_name,
>
like:
"1"
"2"
"3"
etc
2013/2/19 Peter Kroon
> Hi Michael,
>
> This should have been the expected result on both machines:
> ---
>
> (1 row)
>
> I've just rebooted &
t" and I'm getting the
expected result.
Thanks for helping.
Best,
Peter Kroon
2013/2/19 Michael Paquier
> Hi,
>
> With your query and such tables:
> create table __table (id int);
> insert into __table values (1),(2);
> create table __table_to_table (id int, table_i
Query:
SELECT
xmlelement(name s_a,
xmlagg(
xmlelement(name s_b,
xmlattributes(
sq.id AS i
),
(SELECT
xmlagg(
xmlelement(name s_c,
xmlattributes(
su.id AS i
)
)
ORDER BY table_id,id
)
FROM __table_to_table AS su WHERE su.table_id=sq.id
)
)
)
)
FROM __table AS sq
No result given in: "PostgreSQL 9.2
On 1/6/13 11:17 PM, funnybon...@yahoo.com wrote:
> Hello, my engish is not so good, but i try to describe what seems not to
> work. Could it be, that the LC_MESSANGES for months and days like
>
> Months
> --
> Janary=Januar
> February=Februar
>
> Days
>
> monday=Montag
> Thursdat=Dienst
On 1/25/13 1:35 AM, Kevin Grittner wrote:
> Peter, do you have a version that works with 9.3?
I don't, but it shouldn't be hard for someone more up to date with the
internal WAL addressing changes.
> Given that we're past the start of the last CF, do we still want to
> c
Am 22.01.2013 14:47, schrieb Marc Balmer:
> no. Your syntax is wrong.
Well - it's not exactly 'my' syntax - see:
uuid-ossp--1.0.sql
uuid-ossp--unpackaged--1.0.sql
>> I had to replace the hyphen in file names and in the scripts to make the
>> module work.
>>
> That is the wrong "fix". The hyphe
The following bug has been logged on the website:
Bug reference: 7820
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 9.1.7
Operating system: Windows 7 64-bit
Description:
The statement:
'CREATE EXTENSION uuid-ossp&#
ur may be astonishing, but that
doesn't make it a POLA violation. I don't have time to check now, but
I'm pretty sure that doing something else would break a whole bunch of
other common cases.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
Ignore, wrong list...
My apologies..
Best,
Peter
2012/11/23 Peter Kroon
> Is pgsql faster on linux?
> Currently I've made an installation on W7 and the converted queries are
> about 3 times slower then on mssql.
> There's still some optimization to do tho...but the
Is pgsql faster on linux?
Currently I've made an installation on W7 and the converted queries are
about 3 times slower then on mssql.
There's still some optimization to do tho...but the current results don't
look to good.
x-like
systems follow LLP64 (or LLP32) in practice. sizeof(int) is 4 on
Windows (though, in contrast to LLP64, sizeof(long) is 4 too on 64-bit
windows).
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailin
will work rather than fail.
Right. sizeof(int) is very probably 4 on all platforms that we
support. I see no problem with the proposal.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pgsql-b
seems to think can cause this error
with poll(), so this seems like a slight variant of the problem
reported by Sean Chittenden (kernel resource exhaustion causes pipe
creation to fail, with unnecessarily bad consequences for Postgres).
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL
dtyje6wtuy4tgdjuq6eutjjp0ctfladp9qwp8got...@mail.gmail.com
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 9/20/12 11:06 AM, Tom Lane wrote:
> Well, I would have no objection to changing pg_ctl so that it redirects
> the postmaster's stdout/stderr when a -l switch is given (actually,
> I thought it did that already...). I do object to changing the logger's
> behavior as you suggest, because that wil
On Mon, 2012-09-17 at 16:53 +, m...@suse.de wrote:
> It looks like the attempt to remove pg_upgrade's dependency on pg_config
> (http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2815574) was
> incomplete, since contrib/pg_upgrade/exec.c still contains the line
>
> validate_exec(c
On 9/4/12 2:22 PM, Murray Cumming wrote:
> On Tue, 2012-09-04 at 10:31 -0400, Tom Lane wrote:
>> murr...@murrayc.com writes:
>>> At some point, probably in 9.1.5, the -k option to Postgres ("Unix-domain
>>> socket location" in --help), stopped accepting paths that contain spaces.
>>
>>> For instanc
q version that actually has commit
4e816286533dd34c10b368487d4079595a3e1418, can you produce a GDB back
trace of the php process, by doing the same thing as the complainant
that posted to the php bug tracker? The process is documented here:
https://bugs.php.net/bugs-generating-backtrace.php
--
Pe
you don't think that it is. Are you
sure that you're using the libpq distributed with 9.1.5? I don't know
much about php, but for Python, you'd do something like:
[peter@peterlaptop psycopg2]$ ldd _psycopg.so
linux-vdso.so.1 => (0x7fffbd5ff000)
libpyth
On Thu, 2012-08-09 at 16:26 -0500, Merlin Moncure wrote:
> Follow up on this. It is pl/sh and it is a newline issue: one of the
> developers is using a tool (I think pgadmin?) that is sticking \r
> characters at the end of every line which is throwing off pl/sh's
> shebang parsing. The issuing qu
On ons, 2012-07-25 at 10:08 +, jez.w...@bull.net wrote:
> When faced with a flag it doesn't recognize, xlc prints the man page.
> Thus the --version, -v, -V tests result in a particularly large
> config.log file
And is this an actual problem?
The code you are referring to is automatically ge
On tor, 2012-07-12 at 15:25 +, ch...@chrullrich.net wrote:
> The PostgreSQL configure script indiscriminately enables the --as-needed
> option to the linker if the linker supports it, which GNU ld 2.17.50 in
> FreeBSD 9 does. It does not, however, use it in its own library checks. The
> configu
On ons, 2012-07-11 at 11:32 +0200, Christian Ullrich wrote:
> 61 #: pg_basebackup.c:127
>62 #, c-format
>63 msgid " -F, --format=p|t output format (plain, tar)\n"
>64 msgstr " -F, --format=c|t|p Ausgabeformat (plain, tar)\n"
>
> pg_basebackup does not support "c" format
The following bug has been logged on the website:
Bug reference: 6722
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 9.1.4
Operating system: Windows 7 Enterprise (64-bit)
Description:
Hello,
it seems that the debugger
change to PostgreSQL 9.1.x?
-Original Message-
From: Dave Page [mailto:dp...@pgadmin.org]
Sent: Freitag, 6. Juli 2012 10:38
To: Peter Arnold
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #6721: installation of PostgreSQL prevented WebServer
Start
On Fri, Jul 6, 2012 at 9:29 AM
The following bug has been logged on the website:
Bug reference: 6721
Logged by: Peter Arnold
Email address: peter.arn...@jd-ag.com
PostgreSQL version: 9.0.8
Operating system: MAC OSX
Description:
Hi,
after i install PostgreSQL 9.0.8 on my MAC with OSX 10.7.4 the
On fre, 2012-06-01 at 21:26 -0700, Josh Kupershmidt wrote:
> It's too bad the clang
> doesn't understand our ereport(ERROR, ...) calls don't return to the
> caller, as those seem to account for a fair bit of the spurious
> warnings. I haven't seen anything which I'd call an outright bug,
> though t
de may have contained errors, even though it was
evident to me that they actually did not. That said, it probably
wouldn't hurt to give it another try sometime soon.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sen
On ons, 2012-05-30 at 23:43 +0200, Tomas Vondra wrote:
> On 30.5.2012 23:19, Tom Lane wrote:
> > I suspect it depends on how you install the new version of the library,
> > too. I would somewhat expect it to work as you're thinking if the
> > install consists of "rename old file out of the way, co
On ons, 2012-05-16 at 19:55 -0500, Tulio J Carrasco wrote:
> "León", "leon", "leOn" has identical order values: none of them
> weights more for Spanish collation and PG is not working according it
> if PG makes a "second pass" that ignores collation and reorders by its
> character value.
PostgreSQ
On fre, 2012-05-18 at 19:57 +, erlko...@talisman.org wrote:
> The macaddr type does not allow for MACs of greater length (or less than)
> than six bytes, only capturing a particular variety of ethernet address
> (Xerox's original version) instead of the broader use of MACs where
> addresses of
On tis, 2012-05-08 at 11:33 -0400, Clay McClure wrote:
> "The gist of it is to grab python-config --prefix and store it in a
> variable, say py_prefix. If the file $py_prefix/Python exists, you are
> dealing with a Framework build and -framework Python is the
> appropriate method of linking. Otherw
On tor, 2012-04-19 at 15:00 -0400, Tom Lane wrote:
> i+pgb...@avdd.tk writes:
> > A concurrent psql session will overwrite the history of the first. This
> > does not look good: a database tool causing me to lose my data!
>
> Works okay for me. I suspect you need to take this up with whoever
> p
On lör, 2012-04-14 at 08:23 -0400, Robert Haas wrote:
> On Sat, Apr 14, 2012 at 3:27 AM, Pavel Stehule
> wrote:
> >> It has a lot of sense. Without it, it's very difficult to do logical
> >> replication on a table with no primary key.
> >>
> >> (Whether or not people should create such tables in
On ons, 2012-02-22 at 22:37 +0400, Sergey Burladyan wrote:
> eshkin...@gmail.com writes:
>
> > The following bug has been logged on the website:
> >
> > Bug reference: 6480
> > Logged by: Sergey Burladyan
> > Email address: eshkin...@gmail.com
> > PostgreSQL version: 9.1.2
> > O
On fre, 2012-02-17 at 12:01 -0500, Tom Lane wrote:
> lenka.piy...@gmail.com writes:
> > when i restore a particular table using pg_restore (using option "-t") it
> > doesn't restore my primary key...
>
> This is not a bug. -t selects the table only, not associated indexes.
But from a user's per
On 29 January 2012 23:47, Josh Berkus wrote:
> This is *so* not a discussion to have on the pgsql-bugs list. Please
> take it to -hackers.
I suppose you're right, since the first discussion occurred there and
didn't really go anywhere.
--
Peter Geoghegan http://www
line with this
stuff. Should I continue to report trivialities like these as bugs? I
would think that in the case of documentation the answer is "yes", but
I can't help but feel slightly silly about reporting cases like this.
--
Peter Geoghegan http://www.2ndQuadrant.com/
Postg
On 29 January 2012 21:19, Peter Geoghegan wrote:
> Is it really that much of a problem to create a new severity level for
> this stuff?
I should probably have quoted this refinement, which was part of the
discussion that I originally quoted Robert from:
On 24 November 2011 16:55, Alvaro H
the log
> to enable the DBA to figure out that the first error message is likely
> nothing more serious than an integrity constraint doing its bit to
> preserve data integrity, while the second is likely a sign of
> impending disaster.
Is it really that much of a problem to creat
ntain that we should have a new severity level for this
>> sort of thing.
>
> Huh? I don't follow you at all Peter.
I mean that we should change code like this:
elog(ERROR, "could not find plan for CTE \"%s\"", rte->ctename)
to this:
elog(INTERNAL_ERROR
like an integrity constraint violation. I
continue to maintain that we should have a new severity level for this
sort of thing.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@post
here:
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chan
I noticed the following in the auto_explain documentation:
"This can have extremely negative impact on performance."
Surely it should say:
"This can have an extremely negative impact on performance."
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Devel
On 20 January 2012 02:53, Robert Haas wrote:
> OK, done.
Thanks
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
h
On 17 January 2012 01:37, Robert Haas wrote:
>> It's a fairly inconsequential bug, but it is worth fixing...
>
> Fixed.
Thanks.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing
On 9 January 2012 18:47, Robert Haas wrote:
> On Sat, Dec 31, 2011 at 8:54 PM, Peter Geoghegan
> wrote:
>> ISTM that the following reference, at config.sgml line 1345, ought to
>> be adjusted due to the introduction of the new checkpointer process:
>>
>>
ISTM that the following reference, at config.sgml line 1345, ought to
be adjusted due to the introduction of the new checkpointer process:
Setting this to zero disables
background writing (except for checkpoint activity).
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL
On fre, 2011-12-30 at 12:02 -0300, Alvaro Herrera wrote:
> Excerpts from thangalin's message of vie dic 30 11:30:47 -0300 2011:
> > The following bug has been logged on the website:
> >
> > Bug reference: 6368
> > Logged by: D J
> > Email address: thanga...@gmail.com
> > Postgre
On 20 December 2011 18:11, Tom Lane wrote:
> Simon Riggs writes:
>> On Tue, Dec 20, 2011 at 5:50 PM, Peter Geoghegan
>> wrote:
>>> In fact, that macro is defined in access/htup.h...should it be?
>
>> IMHO comment is wrong, code is in the right place.
>
>
Line 834 of heapam.c has the following comment:
/*
* This is formatted so oddly so that the correspondence to the macro
* definition in access/heapam.h is maintained.
*/
In fact, that macro is defined in access/htup.h...should it be?
--
Peter Geoghegan http://www.2ndQuadrant.com
On 11 December 2011 17:53, Cihan ŞENGÜL wrote:
> Hi
> Libpqwce are published. Gösterilemiyor.Bana reference to VB NET 2003. NET
> 2003, I can reference the DLL required for VB
I don't understand.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Sup
inCE libpq port very successfully. I built it
from source too, as there were binary compatibility problems with some
of the ARM devices that had custom WinCE kernels (not uncommon - WinCE
is available under a "shared source" agreement), but not others that
didn't.
What'
On ons, 2011-11-23 at 12:07 +0100, Marco Bernasocchi wrote:
> Hi all, porting QGIS to android I ported libpq as well, I had to modify
> two files to successfully compile it without-readline. I attach the two
> needed minor patches. further informations can be found at android.qgis.org.
The Postg
On tor, 2011-11-24 at 11:14 -0500, Robert Haas wrote:
> So I would propose to steer clear of the word "internal", because the
> really scary errors typically are not internal to PostgreSQL at all.
> What I think we want to distinguish between is things that are
> PEBKAC/GIGO, and everything else.
ot;severe error".
>
> +1
+1
On reflection, that's better than what I proposed.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
INTERNAL_ERROR),
464:(errcode(ERRCODE_INTERNAL_ERROR),
526:(errcode(ERRCODE_INTERNAL_ERROR),
A new severity level is called for. In addition, if we had a new
severity level, the footprint wouldn't be too bad on all those legacy
elog() calls as compa
On tor, 2011-11-10 at 19:30 -0500, Tom Lane wrote:
> I think psql only pays attention to its locale when stdout is a tty.
> Now *why* it acts like that, I'll leave for Peter to defend.
We would have to review the original discussion about that. I can see
arguments for doing it that
The following bug has been logged online:
Bug reference: 6274
Logged by: Jan-Peter Seifert
Email address: jan-peter.seif...@gmx.de
PostgreSQL version: 9.1
Operating system: any
Description:documentation on pg_attribute.atttypmod
Details:
Hello,
it looks like that
On ons, 2011-10-26 at 04:08 +, Shannon wrote:
> The following bug has been logged online:
>
> Bug reference: 6271
> Logged by: Shannon
> Email address: shan...@arc.net.au
> PostgreSQL version: 8.4.9
> Operating system: Gentoo Linux 64bit
> Description:psql -f repor
I noticed this typo in a comment in the file nbtsort.c:
/*
* We need to log index creation in WAL iff WAL archiving/streaming is
* enabled UNLESS the index isn't WAL-logged anyway.
*/
I suggest an s/iff/if/
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development,
On 29 September 2011 23:15, Tom Lane wrote:
> Peter Geoghegan writes:
>> I've built Postgres from master, and found that the following fairly
>> simple query breaks:
>
>> select count(*)
>> from
>> (
>> select
>> schemaname
>&g
On 29 September 2011 21:59, Merlin Moncure wrote:
> hm -- works for me (9.1.0)
It works for me on REL9_1_STABLE too, unsurprisingly, as I would think
it highly unlikely that such a glaring bug would slip into a stable
release.
--
Peter Geoghegan http://www.2ndQuadrant.com/
Postgre
e "no relation entry for relid
1". Why is that?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On ons, 2011-09-28 at 22:42 -0400, Tom Lane wrote:
> "Pierre Ducroquet" writes:
> > [ the "hstore ? text" operator no longer matches an hstore GIST index ]
>
> Hmm ... this doesn't seem to be specific to either hstore or GIST; it's
> a collation problem. The index is marked as having no collatio
1 - 100 of 900 matches
Mail list logo
