has both en_US.iso88591
and en_US.utf8 installed but operates mostly with the former)?
As an aside, how can one find the status of a Postgres bug?
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
locale remains en_US.iso88591? And, at
least in theory, if a non-LATIN1 character (like 0x92) is presented to
the converted database, will it be stored as is or silently transformed
(or will an error be issued)?
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chang
et The New Boss, Same as the Old Boss" (with the
quotes being part of the title) sorts among the M titles, and not at the
beginning, before the A titles. As I understand, 8.4 will include
LC_COLLATE support at the database rather than cluster level which
should help in this regard.
Joe
--
The following bug has been logged online:
Bug reference: 6245
Logged by: Joe
Email address: m...@me.com
PostgreSQL version: latest
Operating system: win 7 64 bit
Description:one click Installer problem
Details:
the one click Installer hangs up during installation
The following bug has been logged on the website:
Bug reference: 6699
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.1.4
Operating system: OSX
Description:
$ pg_restore -O -j 4 ~/tanga.dump -d tanga_dev_full_backup
pg_restore: [archiver
The following bug has been logged on the website:
Bug reference: 7808
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.2.1
Operating system: OSX
Description:
RhodiumToad says this is a bug in unnest, but honestly I don't quite
understa
The following bug has been logged on the website:
Bug reference: 7809
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.2.2
Operating system: Ubuntu
Description:
Running pg_dump on a streaming replication slave with a database that has
The following bug has been logged on the website:
Bug reference: 7874
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.2.1
Operating system: OSX, Linux
Description:
If I run:
alter database foo set my.name = 'joe';
that
ers.
Please let me know if I can provide any additional information.
Any help is greatly appreciated. I apologize if this is a known
issue, I was unable to turn up a match though struggled to figure out
which search terms might yield a result.
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Possibly, I saw that thread but may not have dug into the content
deeply enough. My apologies if this is the case, i'll check it out
further.
On Sep 10, 2008, at 3:38 PM, Tom Lane wrote:
Joe Uhl <[EMAIL PROTECTED]> writes:
We have a query that returns a different result i
]
dblink.c fix
In dblink.c:785 2nd argument for dblink_get_result(text,bool) is referenced
as 'PG_GETARG_BOOL(2)', must be 'PG_GETARG_BOOL(1)'.
This looks like a correct assessment. Will fix...
Thanks!
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@pos
s used for HMAC. It has the added advantage that
there is no direct storage of the password itself, even in hashed form.
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
or everything including our main product
database (hundreds of transactions/sec, 100's of GB of data) for years
and have never seen this scenario.
Any help is appreciated, I can easily provide any additional
information that may be helpful.
Joe Uhl
--
Sent via pgsql-bugs mailing lis
On Jul 8, 2009, at 2:41 PM, Tom Lane wrote:
Joe Uhl writes:
I had to bounce an OpenMQ broker this morning (this database is the
DB
for an OpenMQ HA setup) and couldn't get it to reconnect to postgres.
On inspecting the database I found dozens of vacuum processes waiting
(I have a cro
On Jul 8, 2009, at 3:00 PM, Tom Lane wrote:
Joe Uhl writes:
On Jul 8, 2009, at 2:41 PM, Tom Lane wrote:
What exactly did you do to "kill" those processes? Do you remember
whether any of them happened to have PID 10453?
I used "kill pid1 pid2 pid3 ..." (no -9) as root.
On Jul 8, 2009, at 3:42 PM, Tom Lane wrote:
Joe Uhl writes:
On Jul 8, 2009, at 3:00 PM, Tom Lane wrote:
Hmm. In any case that shouldn't have led to a lock left hanging.
Assuming that it was a regular and not autovacuum, do you know what
the exact command would have been? (In parti
ing to use them with. For instance, there's
an example of PL/Perl versions available embedded in the code here:
This stuff is pretty trivial to do with PL/R
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ereport() before PQfinish(conn) in
> dblink_record_internal() when we use temporary connection.
Thanks for the report. Patch applied to HEAD and 8.4 branch. Problem
introduced in 8.4
Joe
signature.asc
Description: OpenPGP digital signature
t;host=localhost" does not exist
>>>
>>> This is because the recently-introduced PQconnectStartParams()
>>> doesn't handle correctly the dbname parameter containing '='.
>
>> Hmm, I don't think that was ever really supposed to work, it
gt;> accidental that it did.
>
> No, it was intentional.
Here's a patch.
If "=" is found in the dbname psql argument, the argument is assumed to
be a conninfo string. In that case, append application_name to the
conninfo and use PQsetdbLogin() as before. Otherwise
On 02/02/2010 05:46 PM, Fujii Masao wrote:
> On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
>> Objections?
>
> I think that PQconnectdbParams() rather than psql should handle the
> dbname containing "=". Otherwise whenever we use PQconnectdbParams(),
> we woul
'd suggest
> something like
>
> keywords[0] = "host";
> values[0] = options.host;
> keywords[1] = "port";
> values[1] = options.port;
Will do.
Joe
signature.asc
Description: OpenPGP digital signature
the defaults using connectOptions1(),
applies the supplied other arguments overriding the defaults, and then
finally computes derived options with connectOptions2(). It is
essentially the same as PQconnectdb() except the supplied parameters are
used before setting the derived options.
Joe
signature.asc
Description: OpenPGP digital signature
cation_name";
values[4] = pset.progname;
keywords[5] = "dbname";
values[5] = (options.action == ACT_LIST_DB &&
options.dbname == NULL) ?
"postgres" : options.dbname;
key
On 02/02/2010 10:08 PM, Tom Lane wrote:
> Joe Conway writes:
>> Are there any of the psql parameters that we do not want to allow to be
>> overridden by the conninfo string?
>
> Actually, now that I think about it, psql shouldn't be setting
> application_name
On 02/02/2010 10:23 PM, Tom Lane wrote:
> Joe Conway writes:
>> Should I also be looking to replace all (or most) other instances of
>> PQsetdbLogin()?
>
> I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
> the others are worth troubling over
On 02/04/2010 01:23 AM, Fujii Masao wrote:
> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>> bin/scripts (createdb, vacuumdb, etc). I still need to adjust the docs,
>> but other than that any
On 02/04/2010 08:31 AM, Joe Conway wrote:
> On 02/04/2010 01:23 AM, Fujii Masao wrote:
>> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>>> bin/scripts (createdb, vacuumdb, etc). I still need to adj
On 02/04/2010 09:37 AM, Joe Conway wrote:
> On 02/04/2010 08:31 AM, Joe Conway wrote:
>> On 02/04/2010 01:23 AM, Fujii Masao wrote:
>>> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>>>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>>>
repeat the issue in a fresh CentOS VM when I
got home but did not see the problem (perhaps because jade was part of
the install -- will have to check).
Related to this I have noticed in recent weeks on my own development
machine that "make install" takes *much* longer, but only sp
changed). As a side issue, could/should the vacuumlo functionality be
merged with vacuum?
Cheers,
Joe
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Mount
> Sent: Thursday, March 29, 2001 6:52 PM
> To: Joe Shevland; [EMAIL PROT
values('\\000');
INSERT 1482290 1
test=# select f1 from t1 where f1 = '\\000';
f1
--
\000
(1 row)
test=# select octet_length(f1) from t1 where f1 = '\\000';
octet_length
--
1
(1 row)
HTH,
-- Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
owable
value. Anything starting with 4 - 7 (e.g. 400 octal == 256 decimal) is
too big.
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
ailed program was:
#line 7483 "configure"
#include "confdefs.h"
#include
int main() {
extern int optreset; optreset = 1;
; return 0; }
configure:7516: checking test program
configure:7525: gcc -o conftest conftest.c -lrt -lz -lresolv -lgen
-lnsl -lsocket -ldl -lm 1>&5
con
;--with-openssl" all the time and have never
had a problem. Can anyone comment on the appropriate Makefile changes
for this?
Thanks,
Joe
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
cho
times. The problem is in
ExecEvalArray, which computes the dimension of the result as [1:2]
even though there are no elements to put in it.
Joe, what do you think about this? Offhand I think that the only
workable definition is that this case yields another zero-dimensional
array, but maybe there is
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Sorry for the slow response -- I'm at the airport just heading home from
a marathon 30 day business trip.
Yow. Hope you get some time off...
Yeah, I just took a week. Next week I'm back to work and the week after
used (for this data they are
much faster and also don't crash for large datasets).
Mostly I just want to figure out why postgresql is ever returning
out-of-memory rather than using the disk as a backing store. Is my
database misconfigured, or is this a bug? I would think th
ially since this is the first time anyone has complained.
Did you want me to work on this? I could probably put some time into it
this coming weekend.
Joe
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
s that to be expected? If so,
can you give me pointers (either direct guidance or literal URLs) on how
to build postgres and related extensions with VC++?
Thanks,
Joe
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ds successfully) and the MSVC Postgres.
Joe
p.s. actual output below
8<--
Welcome to psql 8.3.1, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g
nd is unable to load a DLL
that plr.dll depends on. Again, the "depends" tool can hopefully show
you what's missing there.
That's what I was originally thinking (R.dll), but now I suspect the
exported functions is probably the issue. I'll check this out when I get
ho
should probably try a bit harder to propagate the
original error fields. I'm inclined to think that it should propagate
sqlstate/message/detail/hint verbatim, and indicate the fact that this
happened on a dblink connection as CONTEXT, rather than structuring the
ereport the way it does now. J
you have the source, write it.
dblink in cvs will work on 7.2.x and supports UPDATE/INSERT/DELETE.
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
shouldn't this be (or '\\047')
Also a bug. Should be '\\047', as you pointed out.
Thanks for the report! I'll submit a patch.
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
stats=0x8379f58) at analyze.c:1740
#4 0x080ba180 in analyze_rel (relid=74723, vacstmt=0x8378110) at
analyze.c:350
. . .
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
> Ah. So the issue is that ANALYZE tries to do textin(byteaout(...))
> in order to produce a textual representation of the most common value
> in the BYTEA column, and apparently textin feels that the string
> generated by byteaout is not legal text. While Joe s
. I'll search the archives for the
thread.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Joe Conway wrote:
> Bruce Momjian wrote:
>
>> Does this mean we don't have to esacpe >0x7f when inputting bytea
>> anymore?
>
>
> I seem to remember that bytea data was run through the multibute code
> for some reason, and I don't recall seeing th
ll the previous tables are back with data in
> it!!
Try connecting to the template1 database, and then do \dt. Do you see
the tables in question?
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
without a fe/be protocol change, so I'd guess it's a
7.4 issue. But, if there is a way to do it now, and someone gives me a
clue how to proceed, I'll try to get a patch together.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I think this is probably a must do item for 7.3.
Any further guidance or thoughts?
Thanks,
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
table series of actions causes the problem?
Is there a core file and have you looked at it in a debugger?
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
unctionCall1(textout, PointerGetDatum(textp)))
then you can do, e.g.
char *cnum = GET_STR(PG_GETARG_TEXT_P(0));
BTW, there are lots of good examples of C functions in contrib.
HTH,
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe c
-< What is it?
>
> Is that a bug?
It looks like someone dropped user_fomacao_des. What happens if you run:
select * from pg_user;
?
You can fix this by doing:
CREATE USER user_fomacao_des WITH SYSID 131 PASSWORD 'password';
HTH,
Joe
---(end of br
elein (by way of elein ) wrote:
> This will not work if there is no EOS on the data portion of the
> string. Text fields are not usually stored with the EOS on them,
> are they?
Yes, the TEXT data type is NULL terminated.
Joe
---(end of
1915
#17 0x0811cf9d in ServerLoop () at postmaster.c:1002
#18 0x0811c915 in PostmasterMain (argc=3, argv=0x825cc78) at postmaster.c:781
#19 0x080f930f in main (argc=3, argv=0xb7e4) at main.c:209
Note the line:
#8 0x080ca75a in show_upper_qual (qual=0x82d1d50, qlabel=0x81df318 "Filter"
HERE clause. I was struggling as to where to
be looking. BTW, it was still there after I sync'd up with cvs last night.
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
OLD
Data type RECORD; variable holding the old database row for UPDATE/DELETE
operations in ROW level triggers.
It is perhaps confusing, but probably necessary so that a single function can
handle inserts, updates, and deletes (see TG_OP).
Joe
---(end of broa
x27;ll submit a patch this evening if no one
else gets to it first.
Thanks for the report.
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>> Hmmm, looks like nodeFunctionscan.c:tupledesc_mismatch needs to be
>> taught about attisdropped. I'll submit a patch this evening if no
>> one else gets to it first.
>
> Actually, I believe I delibe
l_service service%ROWTYPE;
BEGIN
SELECT INTO l_service service.* FROM service
WHERE service.service_id = l_service_id;
RETURN l_service;
END;
' LANGUAGE 'plpgsql';
Joe
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Andres Cuevas wrote:
If data1 or data2 are NULL the request is NULL
Which is the correct behavior, not a bug. See:
http://techdocs.postgresql.org/guides/BriefGuideToNulls
HTH,
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive
ce distribution."
I have no idea how to install contrib/array using debian's package
manager, but that's what you need to do.
HTH,
Joe
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
mporary tables to be created while using the database.
Are these not working?
HTH,
Joe
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
pace where nspname like ''pg\_%'')
AND pg_catalog.pg_table_is_visible(c.oid) LOOP
sql := ''grant all on '' || rel.relname || '' to '' || $1;
RAISE NOTICE ''%'', sql;
EXECUTE sql;
END LOOP;
RETURN ''OK&#
d element. Not sure if this works pre-7.4
though -- I know I made some changes related to this, but I forget the
exact details.
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
printf flags, it causes big problems.
This was fixed for 7.3.4 (or so I thought); see:
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/varlena.c.diff?r1=1.92&r2=1.92.2.1
Are you sure you don't have something earlier? Was does
select version();
was actually a nice behavior.
I found it similarly irritating at first, and it continues to irritate
me. But that may be because I use system tables more frequently than the
average Joe ;-)
I guess I'd be happy to see tab completion reinstated for system tables
(except toast tables as Tom sugge
guish between catalog version, meaning
something structural has changed, and catalog-data version which is
correctible by running a script.
Joe
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
tions of any trigger functions (particularly any "on delete"
triggers), and if possible a complete reproducible example.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
POSTGRESQL BUG REPORT TEMPLATE
Your name : Joe Sunday
Your email address : [EMAIL
c\006 | f
| t
\002\003abc\006 | f
(5 rows)
select * from test where b like '\001%';
This is weird. I'm sure it worked at one time -- will research.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
OK as I'm not currently subscribed.
Cheers, Dave.
Got it.
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
d == d).
The basic rule at work here is you need to double up all backslashes.
HTH,
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Joe Conway wrote:
David Fetter wrote:
I have a little puzzlement. In the first select, I double the
backslash and return true. In the second, I don't and get false.
Have I missed something important in the docs?
I don't know if it is clear in the docs anywhere wrt regex, but the
stri
ble-nls \
--enable-debug \
--enable-cassert \
--enable-depend \
--with-openssl \
--with-pam \
--enable-integer-datetimes \
--with-krb5=/usr/kerberos \
--with-includes=/usr/include/et/
The only adjustment from my RH9 box was the last line. Without it
com_err.h wasn't being found.
tudio .NET 2003\Common7\IDE".
More than likely you neglected to run vsvars32.bat to set up your
environment correctly.
HTH,
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
cases like this.
But I don't see an inherent reason why "raise an error" is better than
"return a null array".
In fact, the above referenced thread shows a scenario where the former
behavior is unpleasant.
I think Joe Conway is planning to tackle that underlying misfeatur
Dennis Bjorklund wrote:
On Thu, 15 Jan 2004, Joe Conway wrote:
Additionally, this behavior was discussed during the 7.4 development and
beta cycles on at least a couple occassions -- that would have been the
time to complain, not now.
Well, I will complain whenever I see something I don't
Josh Berkus wrote:
Bug: Cannot Use Arrays with Raise Notice in PL/pgSQL.
Version Tested: 7.4.1
Severity: Annoyance
Description:
Attempting to pass an array element to Raise Notice in PL/pgSQL will produce a
parse error:
I can reproduce this with cvs tip -- I'll check into it.
Thanks,
; the numbers when need arises is MUCH faster than subtracting timestamps and
> parsing the result of such a subtraction.
>
> Note: The 'date' data type does not have this problem. The result of two
> dates subtraction is an integer (not 'interval') which I
primary key id for my "recipe" table:
>
>SELECT NEXTVAL('recipe_id_seq') FROM receipt;
You're going to get a value for every row in receipt, which is what you're
seeing.
What you want is
SELECT NEXTVAL( 'recipe_id_seq');
--Joe
--
Joe
le. This is more of a conceptual quibble I have at this point.
I think the standard answer should be "do not use serial columns
in any insert rule". I can see problems in cases other than copying
inserted data to another table with rules.
thanks for the good work,
joe
a look at
it next week.
Joe
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
TE TABLE
regression=# insert into test values ('{"A", "B" }');
INSERT 155428 1
regression=# select * from test;
f1
---
{A,B}
(1 row)
regression=# insert into test values ('{ }');
INSERT 155429 1
regression=# select * from test;
f1
---
{A,B}
{}
(2 rows)
Joe
---(end of broadcast)---
TIP 8: explain analyze is your friend
The following bug has been logged online:
Bug reference: 1466
Logged by: Joe Brown
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0.0
Operating system: Windows XP
Description:#maintenace_work_mem = 16384
Details:
I was attempting to reduce the already
t it by hand to see the output.
Tom Lane wrote:
"Joe Brown" <[EMAIL PROTECTED]> writes:
Uncommenting
maintenace_work_mem = 16384
caused the server immediately stop after start.
You apparently managed to change the spelling while uncommenting;
the actual line in th
joe=> select to_date('19450323','CCYYMMDD');
to_date
----
2045-03-23
(1 row)
joe=> select to_date('19450323','MMDD');
to_date
1945-03-23
(1 row)
I thought the former would be "more" correct. But it seems I a
p's caller to
provide the state storage array_map wants, instead of doing it locally.
Both of the existing callers can easily incorporate array_map's state
data into their own state structs. Joe, you have any better ideas?
That certainly looks like the least invasive fix for 8.0.x and
mp table.
Memory according to top never goes much above 25 megs in use during the query.
8.1 grows until it uses about 4 GB, at which point it dies with the
following error:
ERROR: out of memory
DETAIL: Failed on request of size 8224.
--Joe
--
Joe Sunday <[EMAI
On Tue, Mar 14, 2006 at 03:56:51PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > 8.1 grows until it uses about 4 GB, at which point it dies with the
> > following error:
> > ERROR: out of memory
> > DETAIL: Failed on request of size 8224.
On Tue, Mar 14, 2006 at 11:13:38PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 14, 2006 at 03:56:51PM -0500, Tom Lane wrote:
> >> This error should result in dumping a list of per-context memory usage
> >> into the postmaste
1 0x100ef8a8 in ExecProcNode ()
#12 0x100edea8 in ExecutorRun ()
#13 0x1018519c in ProcessQuery ()
#14 0x10185850 in PortalRun ()
#15 0x1018084c in exec_simple_query ()
#16 0x101825b0 in PostgresMain ()
#17 0x1015510c in ServerLoop ()
#18 0x10155d80 in PostmasterMain ()
#19 0x101101e8 in main ()
On Wed, Mar 15, 2006 at 01:10:41PM -0500, Tom Lane wrote:
> Joe Sunday <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 14, 2006 at 11:29:57PM -0500, Tom Lane wrote:
> >> What I'd try is first letting the problem case run for a bit, then
> >> stopping it wi
hint:
auth-method
Also read:
http://www.postgresql.org/docs/8.4/interactive/contrib-dblink-connect.html
-and-
http://www.postgresql.org/docs/8.4/interactive/contrib-dblink-connect-u.html
HTH,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Train
While browsing the code, "pg_dump.c" the following block *appears* to
be problematic. Additionally, there *appears* to be a malloc without a
free (return or assignment) in the function "getBlobs(Archive *AH)"
(pg_dump.c lines 2169 thru 2188 v9.1.4).
/*
* Each large object has its own BLOB archive
On 01/24/2013 05:21 AM, Mark Kirkwood wrote:
> I admit - it sounds unlikely. However a simple scenario (attached) gives
> rise to:
This is the wrong place for the bug report on PL/R I think, but I'll
take a look.
Joe
> WARNING: AbortTransaction while in COMMIT state
> PAN
On 01/24/2013 08:01 PM, Mark Kirkwood wrote:
> Ah right - sorry, I did a quick look for a mail list on the plr web site
> and didn't spot anything.
No problem. It is plr-general on pgfoundry:
http://pgfoundry.org/mail/?group_id=1000247
Joe
--
Joe Conway
credativ LLC: http://www.
finish and investigating what's causing the first error
> call.
Yeah -- will do. Thanks!
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
--
Sent via pgsql-bugs mailing list (pg
1 - 100 of 107 matches
Mail list logo
