Thanks everyone for the explanations. I posted a feature request for improved
enum manipulation in psql-general.
Dmitry Epstein | Developer
Allied Testing
www.alliedtesting.com
We Deliver Quality.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscr
Josh Kupershmidt writes:
>> Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011:
>>> Anyway, the procedure that we used (based on
>>> http://en.dklab.ru/lib/dklab_postgresql_enum/) does the necessary
>>> checks before removing enum values.
> Not exactly; that code is rife with race
On Wed, Sep 28, 2011 at 10:40 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011:
>>> ALTER TYPE ... ADD VALUE does not work inside transaction blocks, period,
>>> whether they are executed as a multi-command string or one query at
On Wed, Sep 28, 2011 at 10:51 AM, Alvaro Herrera
wrote:
> Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011:
>> Anyway, the procedure that we used (based on
>> http://en.dklab.ru/lib/dklab_postgresql_enum/) does the necessary
>> checks before removing enum values.
Not exactly; th
Alvaro Herrera writes:
> Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011:
>> ALTER TYPE ... ADD VALUE does not work inside transaction blocks, period,
>> whether they are executed as a multi-command string or one query at a time.
>> Try it:
> The reason it is not allowed is
Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011:
> > -Original Message-
> > From: Merlin Moncure [mailto:mmonc...@gmail.com]
> > Sent: Tuesday, September 27, 2011 10:31 PM
> > > 1. We can use ALTER TYPE to add enum values, but there is no matching
> > command to remove v
On Wed, Sep 28, 2011 at 5:21 AM, wrote:
>> -Original Message-
>> From: Merlin Moncure [mailto:mmonc...@gmail.com]
>> Sent: Tuesday, September 27, 2011 10:31 PM
>> > 1. We can use ALTER TYPE to add enum values, but there is no matching
>> command to remove values, which makes this an incom
> -Original Message-
> From: Merlin Moncure [mailto:mmonc...@gmail.com]
> Sent: Tuesday, September 27, 2011 10:31 PM
> > 1. We can use ALTER TYPE to add enum values, but there is no matching
> command to remove values, which makes this an incomplete solution.
>
> you can manually delete fr
On Tue, Sep 27, 2011 at 5:06 AM, wrote:
> Hello,
>
> I've encountered some problems with the updated ENUM in PosgreSQL 9.1:
>
> 1. We can use ALTER TYPE to add enum values, but there is no matching command
> to remove values, which makes this an incomplete solution.
you can manually delete from
wrote:
> I've encountered some problems with the updated ENUM in PosgreSQL
> 9.1:
No matter how I tilt my head, I can't see any of those issues as
bugs. You have two feature requests and a question about how to
work around problems you're having with direct modifications to the
system tables.
Tim Uckun writes:
>> As I've stated repeatedly, your next move needs to be to increase the
>> stats target, at least for that column if not globally.
> Ok How do I go about doing this.
If you want to do it globally for the whole database: change
default_statistics_target in postgresql.conf. If
>
> As I've stated repeatedly, your next move needs to be to increase the
> stats target, at least for that column if not globally. You probably
> don't need to have it know about every last domain id, but you need to
> have it know about enough that it realizes that domains not included in
> the
Tim Uckun writes:
>> Am I right in guessing that pg_stats.n_distinct is much too low for
>> the domain_id column?
> the domain_id is in the topical urls. A select count of domains shows
> that there are 700 domains, the pg_stats shows 170 which seems kind of
> low but maybe is not out of bounds b
> With a table that large, you're probably going to need a larger stats
> target in order to get reasonable estimates for low-frequency values.
> Am I right in guessing that pg_stats.n_distinct is much too low for
> the domain_id column?
the domain_id is in the topical urls. A select count of doma
Tim Uckun writes:
> relname | pg_relation_size | reltuples | relpages
> +--+-+--
> consolidated_urls | 1303060480 | 1.80192e+06 | 159065
> consolidated_urls_pkey |114745344 | 1.80192e+06 |14007
On Mon, Jan 17, 2011 at 8:23 AM, Tim Uckun wrote:
>> Hmm. What do you get for:
>>
>> SELECT relname, pg_relation_size(oid), reltuples, relpages FROM
>> pg_class WHERE relname IN ('consolidated_urls',
>> 'consolidated_urls_pkey');
>
> relname | pg_relation_size | reltuples | relpa
>
> Hmm. What do you get for:
>
> SELECT relname, pg_relation_size(oid), reltuples, relpages FROM
> pg_class WHERE relname IN ('consolidated_urls',
> 'consolidated_urls_pkey');
>
relname | pg_relation_size | reltuples | relpages
+--+-
On Sun, Jan 16, 2011 at 5:47 PM, Tim Uckun wrote:
>> Hmm, autovacuum *should* have been keeping track of things for you,
>> but it might still be worth doing a manual ANALYZE against that table
>> to see if the estimated rowcount changes. If not, you'll need to raise
>> the statistics target for
>
> Hmm, autovacuum *should* have been keeping track of things for you,
> but it might still be worth doing a manual ANALYZE against that table
> to see if the estimated rowcount changes. If not, you'll need to raise
> the statistics target for that column (and again ANALYZE).
The analyze finish
> Hmm, autovacuum *should* have been keeping track of things for you,
> but it might still be worth doing a manual ANALYZE against that table
> to see if the estimated rowcount changes. If not, you'll need to raise
> the statistics target for that column (and again ANALYZE).
>
I started a manual
Tim Uckun writes:
>> Possibly the table's never been ANALYZEd ... do you have autovacuum
>> enabled?
> I do have autovacuum enabled and I am running 8.4
Hmm, autovacuum *should* have been keeping track of things for you,
but it might still be worth doing a manual ANALYZE against that table
to se
>
> Possibly the table's never been ANALYZEd ... do you have autovacuum
> enabled? If it has been analyzed reasonably recently, then it might be
> necessary to crank up the statistics target to get a better estimate.
> It's difficult to give detailed advice when you haven't mentioned what
> PG ver
Both queries use the same row's estimation and cost is comparable. But
execution time differs huge: 0.044s and 3100s. I think that the cost
of backward index scan is too small.
On 1/15/11, Tom Lane wrote:
> Tim Uckun writes:
>> I reported this in the pgsql-general list and was instructed to send
Tim Uckun writes:
> I reported this in the pgsql-general list and was instructed to send
> the analaze outputs here.
This isn't a bug, it's just a poor choice of plan based on a bad
statistical estimate. The planner is estimating that there are 2643
rows having domain_id = 157, when actually the
On Mon, Dec 13, 2010 at 8:46 PM, Jorge Augusto Meira
wrote:
> Have something else I can do to reach the limit of the parameter
> max_connections?
>
> This may be a bug?
Well, I don't think you've really identified what's happening. Kevin
and Tom both suggested possible explanations upthread.
--
Hi again
Have something else I can do to reach the limit of the parameter
max_connections?
This may be a bug?
Thanks
Jorge
On Mon, Dec 6, 2010 at 1:31 PM, Tom Lane wrote:
> Jorge Augusto Meira writes:
>> The error message was:
>> "Erro Conexão: A tentativa de conexão falhou."
>> or
>> "Erro C
Hi, Euler
- How could the test program know?
The test program after any operation (inser, tupdate or select) receive a
message of postgres like OK or ERROR (Connection error: FATAL).
- Are you using some delay between one test and another one? I would be a
good idea, specially if you're restarti
Jorge Augusto Meira escreveu:
> The test program is running in other 5 client machines.
> In the logs of my test program, the max_connection parameter limit is
> never reached.
>
How could the test program know? Indeed it doesn't. Are you using some delay
between one test and another one? I would
Hi Tom
The test program is running in other 5 client machines.
In the logs of my test program, the max_connection parameter limit is never
reached.
Regards
Jorge
On Mon, Dec 6, 2010 at 1:31 PM, Tom Lane wrote:
> Jorge Augusto Meira writes:
> > The error message was:
> > "Erro Conexão: A tenta
Jorge Augusto Meira writes:
> The error message was:
> "Erro Conexão: A tentativa de conexão falhou."
> or
> "Erro Conexão: FATAL: connection limit exceeded for non-superusers"
Hmm ... I can't find the first of those anywhere in the 8.4 message
lists; but the second one definitely says that you *
Hi
Thanks for the answers.
Really, I didn't showed you basic informations.
I used the PostgreSQL 8.4. The server configuration was:
Processor: Intel Xeon Processor W3570 Quad Core Processor
Mem: 20GB
Network Interface: Gigabit
HD: 12 x 1 TB (RAID1+0)
OS: Debian
Euler Taveira de Oliveira wrote:
> Talking about your problem, are you sure you're not reaching
> max_connections?
It also strikes me that from the minimal information given, it might
be possible that pid numbers or port numbers are wrapping around
before the OS is ready to allow re-use. I h
Jorge Augusto Meira escreveu:
> This is a bug?
>
You don't provide sufficient information. PostgreSQL version? Error message?
Talking about your problem, are you sure you're not reaching max_connections?
Did you check the logs?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent
You have a previous postgres user installed in your computer, you can delete it
(if no longer used…) with the command : net.exe user postgres /delete
_
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de filipe moreira
Envoyé : mardi 8 juillet 2008 01:06
À : pgsql-bugs@postgre
"Gerardo Antonio" <[EMAIL PROTECTED]> writes:
> I am trying to compile Postgres 8.1.9 in the following Linux version:
> Linux version 2.6.9-34.EL ([EMAIL PROTECTED]) (gcc version
> 3.4.5 20051201 (Red Hat 3.4.5-2))
> but I get a bunch of errors saying "
> i386 architecture of input file
> `../.
Hello,
When I experience the problem, the current Linux locale on my server is
[EMAIL PROTECTED] Psql works fine if I change the current locale (by setting
the LANG shell variable) to [EMAIL PROTECTED]
I would be glad if psql may work fine without changing the LANG variable
in the current se
Looking at the two patches I just applied I think it might fix your
problem. The problem was actually the general problem of pg_ctl -w start
not returning a non-zero.
---
Steve McWilliams wrote:
> Hello,
>
> I tried sending
How's this one...
I realized that the machine I was testing on was
running '[EMAIL PROTECTED]'.. so I quit it.. Lo and behold
beta 2 compiled and made (with make check) just fine.
Thanks
Ted
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Theodore Petrosky <[EMAIL PROTECTED]> writes:
> > Did I miss
I downloaded the beta 2 source,
./configure --with-rendezvous
make
no other configurations... I did this same
configuration on the beta 1 and it was fine. (other
than a make check that we had to add an env line..)
I am going to try again by throwing away the folder
that starting fresh...
Ted
Theodore Petrosky <[EMAIL PROTECTED]> writes:
> Did I miss something that I should so to make 8.0beta2
> for Mac OS X.
Last time I tried it (which was a couple weeks back), our CVS tip built
perfectly cleanly on OS X. Other people report success too, modulo that
silly minus-zero bit in one regres
On Fri, 30 Jul 2004, [iso-8859-1] liz gonzalez wrote:
> Dear Sr. or Madam,
>
> I am writting to you because I am having problems with
> the configuration of PostgreSQL v. 7.4 on LINUX, I
> want to configurate it in JAVA , I set:
>
> $./configure --with-java
>
> checking whether to build Java
"Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> In 7.4.3, if I rename a column which references another table,
> constraint trigger fails on update or delete from main table.
The following patch (against 7.4.*) appears to fix this problem.
regards, tom lane
Index: t
"Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> In 7.4.3, if I rename a column which references another table,
> constraint trigger fails on update or delete from main table.
> The problem goes away after re-creating the foreign key:
Actually all you have to do is start a fresh backend. Th
On Sat, 17 Jul 2004, Alexander M. Pravking wrote:
> (sorry if it's a dup)
>
> In 7.4.3, if I rename a column which references another table,
> constraint trigger fails on update or delete from main table.
I think this probably has to do with the fact that the plan gets cached.
If I close the con
Hi Denise,
I ran into this problem for quite a while until I read the README that
came with the PostgreSQL installation (under /usr/share/doc, I think).
I highly recommend referring to this document. There could be a couple
causes of your error, and since cygwin handles the Sysv IPC calls
differ
"Alejandro Delu" <[EMAIL PROTECTED]> writes:
> IpcSe
> maphoreCreate: semget(key=3D1, num=3D17, 03600) failed: Function not implem=
> ented
> When I want to init the database, It does the previous error, what's wrong?=
> ??
Looks like your kernel doesn't have SysV shared memory support enabled.
Th
Pavel Hanak <[EMAIL PROTECTED]> writes:
> Now calling "select testfun()" shows this fatal error:
>FATAL: SPI: improper call to spi_dest_setup
Hm, I'm glad I put in that test --- it exposed a problem. Here is
the patch for 7.3.
regards, tom lane
*** src/backend/exec
On Thu, 13 Jun 2002, Michael Beckstette wrote:
> Version: PostgreSQL 7.1.2 on sparc-sun-solaris2.5.1, compiled by GCC 2.95
>
> Hi, when using SELECT queries chained by INTERSECT i get confused about the
> behavour of the INTERSECT operation. I try to outline this with the following
> examples.
"Michael Beckstette" <[EMAIL PROTECTED]> writes:
> Version: PostgreSQL 7.1.2 on sparc-sun-solaris2.5.1, compiled by GCC 2.95
> Hi, when using SELECT queries chained by INTERSECT i get confused about the
> behavour of the INTERSECT operation.
Nested INTERSECT and EXCEPT queries are broken in 7.1.*
"Paulo Jorge Gomes Ferreira" <[EMAIL PROTECTED]> writes:
> I've got a problem in my PostgreSQL server. Anytime I issue some commands
> (like vacuum...) I got the following message:
> prescricoes=> vacuum;
> ERROR: cannot find attribute 3 of relation pg_views
What Postgres version are you runnin
[EMAIL PROTECTED] writes:
> The query does an avg on an interval column and now gets the error:
> ERROR: Bad interval external representation '0'
Sorry about that :-(. A last-minute tightening of the allowed input
formats for interval broke avg(interval), but you're the first one to
notice.
I
Hello
> Long Description
> The given code is destilled from a reallife DB. All attempts to define a rule which
>automatically updates the column aenderungsdatum from table mitglieder on updates
>failed. The result was every
> time
> psql:ruleerror:17: ERROR: query rewritten 10 times, may con
David Kaelbling <[EMAIL PROTECTED]> writes:
>> Those all look like big problems, though. They might all have a
>> single root cause ... hard to tell from here.
> Can you suggest how I might track them down or gather enough information
> that you could diagnose the problem?
In all seriousness, I
Peter Eisentraut wrote:
>
> On Wed, 29 Mar 2000, David Kaelbling wrote:
>
> > "info.c", line 2142: warning(1551): variable "htbl_stmt" is used before
> > its value is set
>
> > There were some "pointless comparison of unsigned integer with zero"
> > messages too. The linker also whined because
Tom Lane wrote:
>
> David, 6.5.2 is pretty much ancient history for us. Some of the
> problems you mention have been addressed in current sources, but
> I'm not sure if they all have been.
Yes, sorry -- that was a typo. I was building 6.5.3.
> > I also had some regression failures:
> > - o
On Wed, 29 Mar 2000, David Kaelbling wrote:
> "info.c", line 2142: warning(1551): variable "htbl_stmt" is used before
> its value is set
> There were some "pointless comparison of unsigned integer with zero"
> messages too. The linker also whined because fmgr_pl_finfo is multiply
> defined, as
David Kaelbling <[EMAIL PROTECTED]> writes:
> I built postgresql 6.5.2 for SGI IRIX 6.x systems, and ran into a few
> problems. I've have diffs if anyone needs them, but they all boil down
> to files in src/interfaces/odbc that use C++ comments in C code.
David, 6.5.2 is pretty much ancient hist
57 matches
Mail list logo
