On 2010-05-26, Daniele Varrazzo wrote:
> [regexp_matches:] Return all groups of captured substrings resulting
> from matching a POSIX regular expression against the string. Warning:
> in case of no match, tested record is dropped. See Section 9.7.3 for
> more information.
possibly like this inst
The following bug has been logged online:
Bug reference: 5476
Logged by: Piergiorgio Buongiovanni
Email address: p.buongiova...@net-international.com
PostgreSQL version: 8.3.4
Operating system: CentOS (Redhat 5.4)
Description:sequence corruption
Details:
We experime
Tom Lane írta:
> Bob Lunney writes:
>
>> I have a job that summarizes some data from a table, truncates the table,
>> drops the indexes, writes the summarized data back into the table, then
>> recreates the indexes. The operations above are not in a single
>> transaction, but separate state
Boszormenyi Zoltan writes:
> I looked at ruleutils.c and now I am a little confused.
> I mean different functions use different subsystems to
> get their info. E.g.:
Yup.
> Am I missing something?
Yes. That code is hopelessly intertwined with other operations inside
the backend that need to ru
Krzysztof Nienartowicz writes:
> Logs of the system running queries are not utterly clear, so chasing the
> parameters for the explosive query is not that simple (shared logs between
> multiple threads), but from what I see there is no difference between them
> and the plan looks like (without rem
Oh, found an type in the subject. Transaction, not Translation.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On May 19, 8:41 pm, m...@joeconway.com (Joseph Conway) wrote:
> Magnus Hagander wrote:
> > On Wed, May 19, 2010 at 5:10 AM, Valentine Gogichashvili
> > wrote:
> >> The following bug has been logged online:
>
> >> Bug reference: 5465
> >> Logged by: Valentine Gogichashvili
> >> Email
This probably isn't a legitimate bug, but as a precaution
I'm running the following command against PostgreSQL 9.0 beta 1:
psql -U postgres -d test -c "select tablename,
pg_size_pretty(pg_table_size(tablename::regclass)) from pg_tables
order by tablename;"
And getting the following message:
On tor, 2010-05-27 at 22:41 +0100, Thom Brown wrote:
> This probably isn't a legitimate bug, but as a precaution
>
> I'm running the following command against PostgreSQL 9.0 beta 1:
>
> psql -U postgres -d test -c "select tablename,
> pg_size_pretty(pg_table_size(tablename::regclass)) from pg
Thom Brown writes:
> This probably isn't a legitimate bug, but as a precaution
> I'm running the following command against PostgreSQL 9.0 beta 1:
> psql -U postgres -d test -c "select tablename,
> pg_size_pretty(pg_table_size(tablename::regclass)) from pg_tables
> order by tablename;"
> And
On 27 May 2010 23:00, Tom Lane wrote:
> Thom Brown writes:
>> This probably isn't a legitimate bug, but as a precaution
>> I'm running the following command against PostgreSQL 9.0 beta 1:
>
>> psql -U postgres -d test -c "select tablename,
>> pg_size_pretty(pg_table_size(tablename::regclass))
* Thom Brown (thombr...@gmail.com) wrote:
> psql -U postgres -d test -c "select tablename,
> pg_size_pretty(pg_table_size(tablename::regclass)) from pg_tables
> where schemaname = 'public' order by tablename;"
>
> And this, for some reason, works... which is how I did it the other
> day (hence why
12 matches
Mail list logo