reserved word and quote it before dumping. 9.0 and
later pg_dump does not. Any ideas?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.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 least painful solution might be to always quote *every* identifier
> in commands sent to the source server, since we don't especially care
> how nice-looking those are.
I've never been clear on why we don't do that in the first place.
--
Josh Berkus
Post
ntly, such as
928311a463d480ca566e2905a369ac6aa0c3e210, so maybe this case got fixed
as a nice side-effect.
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
cript.sql
>
> I expect the parser to load and execute my-script.sql located within
> /some/path/to/sql/script/dir
Yup, that works on a 9.2dev client:
test=# \set my_dir /tmp/foo/bar/baz
test=# \i :my_dir/test.sql
?column?
--
1
(1 row)
with test.sql containing the single l
en't verified this (the way to check would be to do
a git checkout of the 9_1_STABLE branch from git, and see if the fix
is present there).
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
artitioned table.
Since the standby VM is new (I've used the same hosting provider
before, but this is the first time I tried an Ubuntu VM), it's
entirely possible I messed something up in the set-up. Or it could be
some flakiness with the VM itself.
But before I start blowing things away
On Wed, Nov 30, 2011 at 9:17 PM, Tom Lane wrote:
> Can you try that on 9.1 branch tip to see if it's already fixed?
Hrm, don't think that helped - I get the same error in the logs using
a checkout of branch REL9_1_STABLE.
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postg
On Wed, Nov 30, 2011 at 10:50 PM, Tom Lane wrote:
> Josh Kupershmidt writes:
>> On Wed, Nov 30, 2011 at 9:17 PM, Tom Lane wrote:
> It might be worth recompiling at -O0, first to see if that changes the
> behavior and second to see if it changes the reported stack trace.
Her
hared_buffers by a quarter or so ought
> to do as a workaround, till you figure out what's going on.
>
> regards, tom lane
>
Wow, that's interesting, though I can't say I'm completely surprised.
You were spot on about turning down shared_buffers - I'm trying it at
96MB, down from 128MB, and the recovery process is chugging along.
I'll probably just ditch this VM and hosting provider (chvps aka
privatelayer, in case anyone wants to stay away).
Thanks for the investigation!
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
inked to that
emphasizing this would be a good idea. Did you have a specific spot in
the manual in mind for such a note, or a preferred wording?
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
arent using wcte where val = whichtab;
ERROR: could not find plan for CTE "wcte"
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 1/28/12 5:27 PM, Tom Lane wrote:
> Josh Berkus writes:
>> SUMMARY: if you attempt to UPDATE or DELETE FROM a parent table in an
>> inheritance relationship using a wCTE, you get the following error message:
>> ERROR: could not find plan for CTE
>
> Fixed, tha
of thing.
Huh? I don't follow you at all Peter.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
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 error. But if no
>>> input, however misguided, should ever cause that symptom, then it's, I
>>> don't know what the terminology should be, say, a "severe error".
>>
>> +1
>
> I'm strongly in favour of this.
This is *so* not
es in fact mention that contrib
modules will need to be installed by a superuser, so this restriction
is not entirely undocumented.
Josh
[1] http://www.postgresql.org/docs/devel/static/contrib.html
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscrip
chd.conf,
/etc/profile, /etc/bashrc, ~/.bashrc, ~/.bash_profile,
~/.MacOSX/environment.plist, and so on.
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
e.g.
SELECT
(CASE WHEN substr(my_column, 1, 2) ~ '[0-9][0-9]'
THEN substr(my_column, 1, 2)::int
ELSE 99
END)::int
FROM my_table;
By the way, LIKE in your example was incorrect: I think you wanted
either 'SIMILAR TO' or the '~' operator depend
temp_%';
schemaname | relname
+-
... so, apparently we still have an issue with cleaning up pg_toast_temp
schema?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscrip
On 4/26/12 11:22 AM, Tom Lane wrote:
> Josh Berkus writes:
>> summary: database has 291 empty pg_toast_temp schemas.
>
> If your max_connections is 300 or more, this isn't surprising in the
> least.
Yes, they are.
>> ... so, apparently we still have an issue w
On 4/26/12 3:48 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Also, have we discussed maybe hiding these schemas from \dn?
>
> We've done more than discuss it:
> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=e43fb604d6db229d70d3101aa53348cc16a54
to get to the bottom of it.
I also tried a sighup to the logger process, with no effect.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 4/26/12 5:50 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Summary: despite pg_reload(), log directory, filename and destination
>> don't change
>
> Looking at the code, it's really hard to see how this could possibly
> happen, unless maybe the process is
> Do you want to try attaching to the collector with a debugger and seeing
> if it ever gets into the "if (got_SIGHUP)" block in SysLoggerMain?
Hmmm. No debugger on this system, not unexpectedly. I'll see if I can
get authorization to add one.
--
Josh Berkus
Postgre
t a bogus new value of
> log_directory, eg not there or not writable by postgres. In any case,
> if this is the locus of the problem, there ought to be instances of that
> log message in the active log file. (Josh?)
Aha.
Yeah, the problem is, directory permissions to the contrary, somethin
16:38:21 PDT [10181]: [1-1] user=,db= LOG: could not open
log file "/pglogs/check/logs/datacollection-2012-04-26-16-38": No such
file or directory
2012-04-26 16:38:21 PDT [10181]: [2-1] user=,db= LOG: disabling
automatic rotation (use SIGHUP to re-enable)
So, yes, exactly.
--
Josh Be
tracker to put it in so the next time someone is working on the log
collector for other reasons they can tweak this too, or when some new
hacker wants an easy first patch.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
.3. Have you
> perhaps changed any server settings?
I only get the error if I:
SET standard_conforming_strings TO off;
otherwise, it works fine. Perhaps it's still worth fixing though.
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
turns false. But IMO it's worth fixing anyway,
to keep the compilers happy or in case of future code calling
buildACLCommands() or parseAclItem().
Attached is a patch to hopefully fix those two errors. I couldn't
quite verify this fixes the OP's error messages, since "checker-266"
i
On Fri, Jun 1, 2012 at 11:38 AM, Anna Zaks wrote:
> Josh,
>
> What kid of machine are you using? Please, let me know how long it
> took after it's done (It takes about one and a half hours on mine).
It just finished, actually: took about 7 hours to run, not counting
the tim
ht bug,
though there are e.g. non-kosher uses of malloc() which could
certainly be improved.
Hrm, I wonder if proc_exit() and ExitPostmaster() could be declared
with __attribute__((noreturn)) , that seems like it would quiet a few
errors.
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql
to submit for the open CF?
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
9.2beta2 server showed in his version() output. There's a reason we
print out a warning like this:
WARNING: psql version X.a, server version Y.b
Some psql features might not work.
when the major version of psql and the server it is connecting to don't match.
Josh
--
Sent vi
mes to -100, which gets picked up here:
commonLen = Min(commonLen, SPGIST_MAX_PREFIX_LENGTH);
and ultimately palloc'ed as a size. I'm not sure what'd be the right
way to fix this after reading the comment above
SPGIST_MAX_PREFIX_LENGTH, but thought I'd share.
Josh
--
Sent
ath.
> Not sure about what a useful solution would be.
I may not have time to look at this today, but I think this behavior
worked fine in the last version[1] of Gurjeet's \ir patch which I
reviewed, which had different behavior for pathname normalization than
what got committed.
Josh
bugs/2011-10/msg00210.php
and at least there's a doc note now warning against using relative
paths, though it sure would be nice if we could fix this gripe.
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
Jeff, Hackers:
Is there a strong reason why this has to error?
postgres=# select '[,]'::TSTZRANGE
postgres-# ;
tstzrange
---
(,)
(1 row)
postgres=# select '[, ]'::TSTZRANGE;
ERROR: invalid input syntax for type timestamp with time zone: " "
LINE 1: se
nt from
\d *
both in the format of the output, and that the latter displays
pg_catalog tables. At any rate, you can use:
\dtv *.*
for all tables and views in all schemas. (Unfortunately, you are then
stuck with noise from pg_catalog and information_schema.)
Josh
--
Sent via pgsql-bug
ation | RowShareLock| test1
relation | AccessExclusiveLock | test1
I understand why establishing an FK needs an ExclusiveLock on the
referenced table, but it doesn't need an AccessExclusiveLock. This
causes lots of deployment issues for users.
--
Josh Berkus
PostgreSQL Experts I
dropdb and dropuser both support a similar option named --if-exists. I
suggest --if-exists instead of --conditional-drops for consistency.
I've only glanced at the patch, but if it makes no sense to use
--conditional-drops (or --if-exists, whatever it ends up being called)
without --clean, th
ar fixes. I could clean these up for you in a later version if
you'd like.
4. There seem to be spurious whitespace changes to the function
prototype and declaration for _printTocEntry.
That's all I've had time for so far...
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
s to find the range type for timestamptz. Why can't it?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
is not the normal failure for that.
Note that the tables were, in fact, created, and as far as I can tell
there's no corruption of the database.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to y
On 03/08/2013 07:27 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> Folks,
>>
>> This is one I've never seen before:
>>
>> => select generate_master_tables();
>> WARNING: AbortTransaction while in COMMIT state
>> PANIC: cannot abort transa
Mark,
I have PL/R and PL/v8 installed on that server (as well as a few other
extensions). However, neither of those is invoked in the procedure
which caused the crash; it's straight PL/pgSQL.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing
to include a call to setval() to set a
sane value for the sequence. For the record, reimplementing pg_dump is
usually a bad idea.
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Alvaro,
BTW, we haven't been able to reproduce this crash deliberately, yet.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Folks,
So I'm a bit surprised that this bug report hasn't gotten a follow-up.
Does this sound like the known 9.2.2 corruption issue, or is it
potentially something else?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@post
a very simple reproduceable one so
far have met with failure. So I'm filing this bug *in case* we see other
issues with repetitive RESET ROLE calls in the future.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
c:1244
#10 0x000100194089 in main (argc=3, argv=0x100800700) at main.c:196
Josh
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, May 16, 2013 at 3:33 PM, Josh Kupershmidt wrote:
> Backtrace looks like this:
My mistake -- the last backtrace was from an idle client before the
crash. Thank you andres and wulczer for the correction. Here is the
interesting one:
(gdb) bt
#0 has_unnamed_full_join_using (jtnode=0x0)
e, the
> problem shows.
>
> I know that it's probably not a big deal for most of the people, but it
> did bite me, so I'm reporting it.
It has been a nuisance for me too. Possible patch for pg_ctl is in the next CF:
http://www.postgresql.org/message-id/cak3ujrfk8-izau1s
ed in state 7: ERROR: prepared statement "P0_7" does not
exist
Client 2 aborted in state 7: ERROR: prepared statement "P0_7" does not
exist
transaction type: TPC-B (sort of)
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pg
on I even tried it is that I was testing for a
PostgreSQL bug -- but we should fail gracefully, e.g. "Use of prepared
statements with pgbench requires persistent connections. You may not
use the -C and -m prepared options together".
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.
201 - 253 of 253 matches
Mail list logo
