know if you can see something wrong.
A quick eyeball check looks ok; I'll see about reproducing the
original scenario with this patch applied.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged on the website:
Bug reference: 8453
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.3.0
Operating system: any
Description:
The first snprintf in writeTimeLineHistoryFile in receivelog.c
What compiler are you using? If it helps, some time ago I built PG
v9.2.2 using the IBM xlc compiler at version 12 successfully. From my
notes I used the following compiler configuration:-
./configure CC=xlc LIBS="-lssl -lcrypto -lz -lreadline -lcurses -lld
-lmass -lm" CFLAGS="-qlanglvl=extc89
;: "b\"c"}'::json::text;
IOW, this isn't a bug in my view.
What we should possibly provide is a function to de-escape JSON scalar
strings explicitly. It would be a simple extension to write,
particularly for 9.3 where the JSON parser is hookable. (Or it could
easily be a
sum_orig_raw_pktcount'',sum_orig_raw_pktcount),
-- XXX THIS IS IT, does not work even when ... + 100 XXX
(doing \set VERBOSITY terse in psql is a good idea for this case to
avoid excessive CONTEXT output)
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
k-ism, not realizing that there were order
dependencies on some platforms.
It looks to me like you didn't reorder anything, you added a test for
sys/ucred.h.
I haven't seen the proposed patch, though.
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql
't
we need to fix this test anyway?
The test needs to be fixed, but with a newer Autoconf version we would
(probably) have been alerted about that by a build failure rather than
someone scanning build logs.
I take it you mean a configure failure would occur with a later Autoconf.
chee
The following bug has been logged on the website:
Bug reference: 8274
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.1.9
Operating system: any
Description:
The guy on IRC who ran into this one was using 9.1.9, but it seems
On 06/30/2013 11:07 AM, Andres Freund wrote:
On 2013-06-30 10:17:50 -0400, Andrew Dunstan wrote:
On 06/30/2013 09:49 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
Andrew: Could we perhaps check for the "Report this to" bit in the
On 06/30/2013 09:49 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?
I'm not sure what you're asking here.
I think he's wishing that if config
On 06/30/2013 09:20 AM, Andres Freund wrote:
On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?
FWIW: I checked that there are no other reports on HEAD atm.
I'm not sure what you're asking he
The following bug has been logged on the website:
Bug reference: 7881
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.2.3
Operating system: any
Description:
The range type code accepts SQL functions for subtype_diff, but
ces? Sorry for vague details, win
machines are not a core competency.
Andrew
ertainly be a lot more invasive.
These aren't mutually exclusive, though, are they? It seems reasonable
to do the minimal fix for the stable branches (looks like it's just a
matter of moving the call up a couple of lines in plperl.c) and make the
nicer fix just for the development
The following bug has been logged on the website:
Bug reference: 7622
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.2.1
Operating system: n/a
Description:
Tested on git-master, 9.2.1, various older versions.
select (select
Apologies for delay in progressing this, but I only have access to an
AIX7.1 system periodically.
Just to confirm that source build of 9.2.1 release now builds clean
against AIXv7.1 with xlc v12.1 compiler.
Thanks,
Andrew
On 31/08/12 20:20, Tom Lane wrote:
Andrew Hastie writes:
On 31
Apologies for delay in progressing this, but I only have access to an
AIX7.1 system periodically.
Just to confirm that source build of 9.2.1 release now builds clean
against AIXv7.1 with xlc v12.1 compiler.
Thanks,
Andrew
On 31/08/12 20:20, Tom Lane wrote:
Andrew Hastie writes:
On 31
On 31/08/12 15:59, Tom Lane wrote:
Andrew Hastie writes:
Thanks for the pointers. Hopefully some of the following may shed some
light on the issue.
Thanks for the results. It seems difficult to come to any conclusion
other than that AIX has got wcstombs_l but not mbstowcs_l ... which is
On 29/08/12 18:16, Tom Lane wrote:
Andrew Hastie writes:
I'm currently working on a project where I need to get PGv9.1 up and
running on an IBM AIXv7.1 server, so I do have access to a suitable
machine for a period of time if I can provide any further diags to help
resolve the issue.
this in order to participate in the build farm, but it may not be
possible "politically" where I work.
I'm more a Java/JDBC type person and can't confess to being a C guru, so
please make any follow-up requests for extra diags as simple as possible
please ;-)
Andrew
On 05/21/2012 02:59 PM, Andrew Dunstan wrote:
On 05/16/2012 10:23 AM, Andrew Dunstan wrote:
On Wed, May 16, 2012 at 9:08 AM, Tom Lane <mailto:t...@sss.pgh.pa.us>> wrote:
Martin Pitt mailto:mp...@debian.org>> writes:
> while packaging 9.2 beta 1 for Debian/Ubu
On 05/16/2012 10:23 AM, Andrew Dunstan wrote:
On Wed, May 16, 2012 at 9:08 AM, Tom Lane <mailto:t...@sss.pgh.pa.us>> wrote:
Martin Pitt mailto:mp...@debian.org>> writes:
> while packaging 9.2 beta 1 for Debian/Ubuntu the postgresql-common
> test suite not
e order that entries appear in the archive ...
>
>
>
Darn, will investigate.
cheers
andrew
query optimizer rearranges the order according to its
logic. Now it appears that sometimes it may be important.
Regards,
Andrew
On Wed, Feb 1, 2012 at 11:48 PM, Tom Lane wrote:
> Andrew Schetinin writes:
> > In my specific case, what I've seen from the query execution plans, is
>
where.
Regards,
Andrew
On Wed, Feb 1, 2012 at 9:42 PM, Alex Lai wrote:
> Hi Andrew,
> I posted for another post, its may give you a workaround.
> I still not fully understand how PG choose execute plan that slow down so
> much.
>
> I had the same situation in one of my query.
es manual intervention to data processing.
On Wednesday, January 11, 2012, 9:26:48 PM you wrote:
KG> Andrew Alcheyev wrote:
KG>
>> Well, it does good and the backend hasn't crashed yet, but the
>> client is still experiencing query problems at some point (not
>> far,
nsaction" in postgresql.conf?
And how can I calculate desired value?
With the best regards, Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ault_transaction_isolation", then the
situation vanishes.
So why does this thing happen? Is there a bug in Postgresql or FreeBSD?
I'd be glad to produce any other meaning information.
With the best regards, Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
That's great.
Thanks for doing this and getting back to us.
Andrew Milne
On 18/12/11 17:50, Michael Meskes wrote:
On Fri, Nov 25, 2011 at 12:51:51PM +0000, Andrew Milne wrote:
The ECPG pre-processor seems to be incorrectly reporting an error when
parsing "EXEC SQL AT :cnx
The following bug has been logged online:
Bug reference: 6309
Logged by: Andrew Milne
Email address: andrew.mi...@iongeo.com
PostgreSQL version: 8.4.9
Operating system: Red Hat Enterprise Linux Workstation release 6.1
(Santiago)
Description:ECPG pre-processor issue
The following bug has been logged online:
Bug reference: 6254
Logged by: Andrew Kerr
Email address: andrew.k...@unrulymedia.com
PostgreSQL version: 9.0.5
Operating system: CentOS 5.4
Description:COPY ... TO .. CSV sometimes doesn't escape strings
Details:
Que
to say yes, but mainly because it's just old cruft. I don't
expect to be able,say, to load a pre-7.3 dump into a modern Postgres.
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ngs, just leveraging existing functionality a little differently.
--
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 5907
Logged by: Andrew Considine
Email address: andrew.consid...@sncorp.com
PostgreSQL version: 9.0.1-1
Operating system: Windows XP
Description:ODBC % bug
Details:
Using a password that contains a "%&qu
On 20 October 2010 06:15, Tom Lane wrote:
> "Andrew Tipton" writes:
> > Attempting to execute an UPDATE that joins to another table where the
> join
> > condition is comparing a composite type fails with the (presumably
> internal)
> > error message "ps
The following bug has been logged online:
Bug reference: 5716
Logged by: Andrew Tipton
Email address: and...@adioso.com
PostgreSQL version: 9.0.1
Operating system: Ubuntu 10.04
Description:Regression joining tables in UPDATE with composite types
Details:
Attempting
The following bug has been logged online:
Bug reference: 5677
Logged by: Andrew Geery
Email address: andrew.ge...@gmail.com
PostgreSQL version: 9.0
Operating system: Ubuntu 10.10
Description:missing libuuid.so.16 library
Details:
In 8.4, the one-click installer for
the generate_series should do this. I
tested this on Windows Vista using PG 9.0 and also on Linux (RHES4)
using 8.4.4 (both packaged by EnterpriseDB) and it crashed both
servers.
Thanks
Andrew
create or replace function get_fts_config_name() returns regconfig as $$
select setting::regconfig
ight do the wrong thing. I
didn't realize it could have such drastic results... Is it still
worth getting a stack trace or is this just a don't-ever-do-that
thing?
Thanks
Andrew
On Tue, Sep 21, 2010 at 5:50 PM, Alvaro Herrera
wrote:
> Excerpts from Andrew Geery's message of mar sep
Running the server in debug mode, I see the following before the
server crashes -- it looks like something goes wrong with
autovac_balance_cost when trying to analyze the collection table (that
was the table the inserts were being done into).
Thanks
Andrew
2010-09-21 16:27:40 EDTDEBUG
MPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT collection_app_uid_key UNIQUE (app_uid)
)
WITH (
OIDS=FALSE
);
Thanks
Andrew
On Tue, Sep 21, 2010 at 3:00 PM, Heikki Linnakangas
wrote:
> On 21/09/10 21:57, Andrew Geery wrote:
>>
>> The following bug has been
Thanks, Dave. I must have missed the restriction on the download page.
Andrew
On Tue, Sep 21, 2010 at 3:03 PM, Dave Page wrote:
> On Tue, Sep 21, 2010 at 8:00 PM, Andrew Geery wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5670
&g
The following bug has been logged online:
Bug reference: 5670
Logged by: Andrew Geery
Email address: andrew.ge...@gmail.com
PostgreSQL version: 9.0
Operating system: Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Description:installer crashes
Details:
For
The following bug has been logged online:
Bug reference: 5669
Logged by: Andrew Geery
Email address: andrew.ge...@gmail.com
PostgreSQL version: 9.0
Operating system: Windows Vista
Description:server process was terminated by exception 0xC005
Details:
My PG 9.0
keys were toastable. It looks a whole lot like several of Oleg
and Teodor's other GiST modules (e.g. ltree, pg_trgm - I suspect that
the pg_trgm one is just as useless, though I haven't read enough of that
code to be sure.)
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ecause if any platform does exist where the check fails, you'd
just get corrupt results in a non-asserts build. I figured it was
better to produce an actual error instead.
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
;t an hstore. This didn't matter
before the format upgrade code was put in, and it didn't show up in
tests because you need to index a very large number of hstores before
any problem shows up.
--
Andrew (irc:RhodiumToad)
Index: contrib/hstore/
ve the original message out to stderr, which it's doing already.
I thought we agreed back in November to stop the bleating. Maybe you
thought I'd remove it and I thought you would ;-).
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs
Or anyone else :-)
The reason why I was initially skeptical of adding a YAML output
format is that JSON is a subset of YAML. Therefore, the JSON output
format ought to be perfectly sufficient for anyone using a YAML
parser.
There is some debate on this point, IIRC.
cheers
andrew
--
Sent
The following bug has been logged online:
Bug reference: 5296
Logged by: andrew neill
Email address: andrew.nei...@bbc.co.uk
PostgreSQL version: 1.10
Operating system: windows xp
Description:crash when two 'add column' diagrams are open
Details:
if yo
>>>>> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> I don't think it's particularly closely related to #4907.
Tom> Yeah.
BTW, did #4907 ever get fixed in the back branches?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs m
he function as volatile fixes the
David> issue. Possibly related to BUG #4907.
I don't think it's particularly closely related to #4907.
I've confirmed this bug still exists in both 8.4.2 and HEAD; it's
clearly a problem that affects only inlined SQL functions (making the
do something like this: before deparsing,
walk the query looking for offending USING clauses, and make a list of
renamings to apply to column names.
I haven't tried actually implementing this, but I believe it is
possible.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> What are the definitions of your instr() and ad_parent_tree()
Andrew> functions?
Well, there's so much wrong with that ad_parent_tree function - it's
always going to recurse infinitely (with a new subxact
Oleg> The most interesting thing is that this function makes segmentation
Oleg> fault also on FreeBSD 7.2 with Postgresql-8.3.7.
What are the definitions of your instr() and ad_parent_tree() functions?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgres
everything else inherits that. All
setrlimit calls for RLIMIT_STACK are explicitly clamped to MAXSSIZ, so
there's no way to set that value higher than the kernel limit, and no
way for getrlimit to report a value higher than the real limit.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs
The following bug has been logged online:
Bug reference: 5200
Logged by: Andrew Masterton
Email address: a.j.master...@open.ac.uk
PostgreSQL version: 8.3.8
Operating system: RedHat Enterprise 5.4
Description:Use of min suffix in autovacuum_naptime ignored
Details
te or replace function foo2(r foo2) returns foo2 language plpgsql
as $f$ declare v foo2; begin v := r; return v; end; $f$;
select foo1(null);
foo1
--
(,)
(1 row)
select foo2(null);
ERROR: cannot assign non-composite value to a row variable
CONTEXT: PL/pgSQL function "foo2" whil
y are coded
for).
Of course, changing the definition of a locale will break everything
until you reindex, etc., but we put up with that because the
alternatives are clearly silly.
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
like a bit of a stretch to me... we treat lots of stuff as
immutable which is actually easier to change than pg_conversion entries
(OS locale definitions for example).
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rt_to is defined as stable rather than immutable. (Sure it depends
on server_encoding, but that can't exactly change... if there's any
other reason why it's not immutable, I can't think what it is.)
Example (5) from the original message is the correct approach in any
case;
s to pick it up :-)
I'd rather wait till you can check it.
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
any
new cases; we'll have to take your word for that :-)
The code around this has changed a little on -head. I don't have any
more spare cycles at the moment - are you able to produce an updated
patch for 8.5?
Andrew/Magnus; we do still see occasional failures of this nature, so
I believ
ds; specifically it doesn't contain enough row
visibility info for index-only scans to be possible without consulting
the table.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
and don't see that I ever got a
Joshua> notice that I needed to approve #5085. I did get one for 5804
Joshua> and 5806, FWIW.
That's what I was afraid of; it rather suggests that some submissions are going
astray without any moderator ever seeing them. Someone should probably check
an impression
based on the number of cases in which I am later reminded of the bug and
go back to look for it.)
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 5087
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: any
Operating system: any
Description:Submitted bug reports not showing up in a timely manner
(or at all)
Details
oesn't matter. Leaving the clause out of the
Tom> equivalence machinery is certainly safe; at worst we'll end up
Tom> with a redundant test or two in the final plan.
Yeah, and clearly leaving in that kind of redundant test is no big
deal.
--
Andrew (irc:RhodiumToad)
om> doesn't seem like that's going to come up enough to be worth
Tom> stressing about. If we wanted to be smart about it we'd have to
Tom> have two kinds of single-element equivalence classes (one that
Tom> implies a k = k check is needed, and one that does
qual is being dropped somewhere, which changes
the output since that's a disguised not-null condition.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
age
pd_lower while leaving the rest of the page intact.)
I did ask Bryan on IRC to make a copy of his data directory before doing
the fix.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 5053
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 8.5devel
Operating system: FreeBSD
Description:domain constraints still leak
Details:
Domain NOT NULL constraints
The following bug has been logged online:
Bug reference: 5048
Logged by: Andrew Deryabin
Email address: and...@deryabin.com
PostgreSQL version: 8.4
Operating system: FreeBSD
Description:psql: \g doesn't redirect COPY TO STDOUT, but redirects
next query
Details:
anything with it, it was almost certainly already broken (or
possibly 6179 broke it).
Notice that in the log table, the log entry that records the most
recent update to the row is the one with xmin=4971. There is no
entry in the log table corresponding to 6179.
--
Andrew (irc:RhodiumToad)
--
Sent via
ffected table).
However I'm wondering if another 8.3.4 fix, the RecentGlobalXmin one,
could be relevant here?
http://archives.postgresql.org/pgsql-committers/2008-09/msg00105.php
(I'm not seeing how it would be, but... note that the xids have got
to the point that they'd appear to
6f 00 00 |.o..|
0ae0 00 15 5a 02 00 0a 00 00 00 02 00 00 00 00 00 00 |..Z.|
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
like a probable explanation, but that idea
Tom> goes out the window if there have been no UPDATEs.
No UPDATEs (and there are no HOT flags set on any tuple I looked at).
There may have been DELETEs.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.o
nd event?
The system was recently dump/restored from a different box. The
failing rows are all new inserts since the restore.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
| 77.202.22.228
| 3 | 37349 || 2009-05-09 13:40:09.031336
(79870,5) | 16395 |0 |0 |0 | 15722953 | 0 | 77.202.22.228
|56 | 0 || 2009-05-09 13:40:23.072695
(above 3 rows are)
(full list at http://pastebin.com/m16600dc8
o 8.5.
Hard to keep that win32 acl stuff leak free. There is always a cleanup
goto because you need 6 billion objects to answer any question :o
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Attached is a mix of our two patches. How does that look to you?
looks good.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
n the same message becomes far more unlikely.
Also, they end up being more efficient than sha256 by itself.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
wasn't sure if someone wanted that way. I'd suggest
malloc and free if your going to change it. The only time I use an MS
allocater is when a win32 api function specifically states it must be used.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via
ToDacl() is the only
function making use of GetUserSid(), so this change won't break
anything. The benefit to this approach over my first suggestion is that
it avoids an unneeded HeapAlloc(sid), CopySid(sid) ... and its cleaner.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://ww
address you tried to free.
Although the FreeSid call causes no harm because its defensive, there is
still the issue of leaking the TOKEN_USER structure.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
) line 807
FreeSid(psidUser) should be HeapFree(GetProcessHeap(), 0, psidUser)
in order to work with my suggested changes in GetUserSid().
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
The following bug has been logged online:
Bug reference: 4821
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 8.3-8.4
Operating system: all
Description:LIKE '%_' fails
Details:
# select 'foo'
Simon Riggs wrote:
On Fri, 2009-05-15 at 10:17 -0400, Andrew Dunstan wrote:
This whole area is unfortunately way too fragile. We need some way of
managing these facilities that hides a lot of these details and is
therefore less likely to produce shot feet, IMNSHO. I get very nervous
ess likely to produce shot feet, IMNSHO. I get very nervous
every time I have to touch it.
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 4717
Logged by: Andrew Smith
Email address: laconi...@gmail.com
PostgreSQL version: 8.3.7
Operating system: Windows XP
Description:Installing PostGIS via StackBuilder gives an 'Error
opening file' err
The following bug has been logged online:
Bug reference: 4667
Logged by: Andrew Shved
Email address: ash...@symcor.com
PostgreSQL version: 8.3.5
Operating system: Sun Sloaris 10 SPARC 64 bit ( SunOS 5.10)
Description:pg_standby error on Solaris 10 SPARC 64 bin
it is what I
think it is, the problem is with libc not postgres.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 4553
Logged by: Andrew Gierth
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3-8.4
Operating system: all
Description:HOLD cursors not materializing results fully
Details:
(tested on 8.3.5 and HEAD as
On Mon, Nov 24, 2008 at 01:39:48AM -0500, Andrew Sullivan wrote:
>
> You can't know that, as a matter of SQL semantics.
I shouldn't reply to listmail when bone tired. I was thinking of
rows. Sorry.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
--
Sent via pgsql-bugs mailing
On Sun, Nov 23, 2008 at 05:36:13PM +0100, toruvinn wrote:
> Actually, I prefer it the old way. I just like to know the column order
> `SELECT *' would return (though I never use `SELECT *' myself). Not to
You can't know that, as a matter of SQL semantics.
A
--
A
ed as working for every SQL query
executed in the function, rather than for a specific list of
constructs, this is clearly a bug.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
Alex> I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374
Feel free to add my explanation to that (I couldn't see an obvious way
to do it myself)
--
Andrew.
--
Sent
age
3) any operation that relies on CopSTASH(PL_curcop) (I can only find a
few: sort, reset, and bless) will then behave incorrectly
However, I have no idea why Perl has this difference between threaded
and non-threaded code.
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
lure. It seems to occur ONLY if perl was
built with threading support (ithreads). Without ithreads, I can't
reproduce it (I've tried enabling and disabling multiplicity with no
effect, so it's not that).
Ithreads seem to be the default on many linux package builds of perl.
It is _not_ the
en you build perl with
threading turned off.
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
1 - 100 of 260 matches
Mail list logo
