The following bug has been logged on the website:
Bug reference: 8408
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.4
Operating system: Any
Description:
There are simple test case:
create table test_columns (id serial primary
The following bug has been logged on the website:
Bug reference: 8176
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.4
Operating system: Any
Description:
Hi,
It seems that documentation wrong or [ CASCADE | RESTRICT ] feature of
.
+1 for "just remove the column in the next release"
--
Maxim Boguk
Senior Postgresql DBA
http://www.postgresql-consulting.ru/ <http://www.postgresql-consulting.com/>
Phone RU: +7 910 405 4718
Phone AU: +61 45 218 5678
Skype: maxim.boguk
Jabber: maxim.bo...@gmail.com
МойКруг
The following bug has been logged on the website:
Bug reference: 7920
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.3
Operating system: Linux
Description:
sequence_name left stale after sequence rename:
Test case shows same prob
from test;
>> ERROR: failed to re-find MinMaxAggInfo record
>
> Fixed, thanks for the report.
>
> regards, tom lane
Thank you very much.
PS: I know that the query sounds stupid, but most CMS/ORM
unfortunately could produce unlimited amount of strange/s
The following bug has been logged on the website:
Bug reference: 7703
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Any
Description:
Simple test case:
test=# create table test (id serial);
NOTICE: CREATE TAB
On 10/19/12, Vik Reykja wrote:
> On Thu, Oct 18, 2012 at 5:40 PM, wrote:
>
>> The following bug has been logged on the website:
>>
>> Bug reference: 7612
>> Logged by: Maxim Boguk
>> Email address: maxim.bo...@gmail.com
>> PostgreSQL v
The following bug has been logged on the website:
Bug reference: 7612
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
Join between two values() set could produce wrong results:
Test case
conf from old data
directory is wrong move too... if admin forget copy pg_hba.conf to the new
cluster - these settings could be lost forever after delete_old_cluster.sh .
--
> Bruce Momjian http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
The following bug has been logged on the website:
Bug reference: 7580
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
create table t1 as select id from generate_series(1,10) as g(id
The following bug has been logged on the website:
Bug reference: 7579
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
Hi,
After testing migration to 9.2.1, Segmentation fault query were found
The following bug has been logged on the website:
Bug reference: 7573
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.0
Operating system: Linux
Description:
Hi,
today while performing migration of test database (with no critical
> > Does that mean that file was damaged during rsync?
> Not necessarily. When did you initially set up that cluster? Normally the
> file
> should get zeroed out before its being used. If the cluster was copied
> improperly (i.e. no pg_start/stop backup or such) it could easily happen.
> But
> I wo
On Wed, Aug 22, 2012 at 1:50 PM, Maxim Boguk wrote:
>
>
> On Wed, Aug 22, 2012 at 6:08 AM, Andres Freund wrote:
>
>> On Tuesday, August 21, 2012 03:30:44 PM Maxim Boguk wrote:
>> > Hi Andres,
>>
>> I would add something akin to
>>
>> elo
On Wed, Aug 22, 2012 at 6:08 AM, Andres Freund wrote:
> On Tuesday, August 21, 2012 03:30:44 PM Maxim Boguk wrote:
> > Hi Andres,
>
> I would add something akin to
>
> elog(WARNING, "pid of startup is: %d, sleeping for 10s", getpid());
> sleep(10);
>
Hi Andr
Hi Andres,
> > I have some problems with debug startup process with gdb...
> > I following next sequence of commands (and got no useful results):
> Youre debugging the postmaster that way. The easiest way would be to just
> attach to the startup process with gdb -p. Not sure if you can manage tha
On Tue, Aug 21, 2012 at 8:08 PM, Maxim Boguk wrote:
>
> >
>> >
>> > I have kept all that database files for the future investigation.
>> >
>> > What I should look into first?
>> Could you reproduce the error with log_error_verbosity=verbose
> >
> >
> > I have kept all that database files for the future investigation.
> >
> > What I should look into first?
> Could you reproduce the error with log_error_verbosity=verbose? Or even
> better
> provide a backtrace with gdb?
>
>
There log with log_error_verbosity=verbose:
2012-08-21 14:04:
The following bug has been logged on the website:
Bug reference: 7500
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.0.8
Operating system: FreeBSD
Description:
Hi,
Reinitialization of the replica after failover is procedure
The following bug has been logged on the website:
Bug reference: 6736
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.0.4
Operating system: FreeBSD
Description:
Hi,
May be it was fixed in more recent releases, but I can not find rel
>
> > 2012-07-10 03:31:35 MSK 12202 @ from [vxid:1/0 txid:0] [] PANIC: GIN
> > metapage disappeared
>
> This is fixed in current minor releases.
>
>
> http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=268ca4f57ea2dc3bf0dfb0f5c17fbda269b5d462
>
> regards, to
The following bug has been logged on the website:
Bug reference: 6725
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.0.7
Operating system: Debian Linux
Description:
Hi,
On one of my production databases hot-standby server start
On Wed, May 23, 2012 at 12:14 PM, Tom Lane wrote:
> Maxim Boguk writes:
> > if anytextcat() and textanycat() are marked volatile,
> > why the database allows create index on supposedly to be volatile
> > expression:
> > create index test_val_special on test((va
st to include an explicit cast to text, though, instead of
> relying on the assumption that the system will let you concat an integer
> directly to a text string.
>
>regards, tom lane
>
--
Maxim Boguk
Senior Postgresql DBA.
Phone RU: +7 910 405 4718
Phone
The following bug has been logged on the website:
Bug reference: 6662
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.1.3
Operating system: Linux
Description:
I managed create simple self-contained test case for 6658.
create table
The following bug has been logged on the website:
Bug reference: 6658
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.1.3
Operating system: Linux
Description:
Hi,
I have 2 queries which have the same plan/same performance on 8.3 but
The following bug has been logged on the website:
Bug reference: 6513
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.0.7
Operating system: Linux
Description:
I got hit by that bug when explored reasons of one very slow production
The following bug has been logged on the website:
Bug reference: 6422
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Linux
Description:
Hi.
Unfortunately I was hit by that problem in the real project.
During
of mar ene 10 23:00:59 -0300 2012:
> > The following bug has been logged on the website:
> >
> > Bug reference: 6393
> > Logged by: Maxim Boguk
> > Email address: maxim.bo...@gmail.com
> > PostgreSQL version: 9.0.6
> > Operating sys
The following bug has been logged on the website:
Bug reference: 6393
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.0.6
Operating system: Linux Ubuntu
Description:
I have heavy write-load table under PostgreSQL 9.0.6 and sometime
The following bug has been logged on the website:
Bug reference: 6359
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.1.2
Operating system: Ubuntu linux
Description:
Sometime Postgres inline subrequest even if it produce slower plan
the crummy plan where the whole lower join gets computed.
>
>regards, tom lane
>
Thank you very much for information.
Rewriting the query did the trick and resolved performance issues.
Do you plan create "generalized inner indexscan" mechanics for 9.2 version?
--
Maxim Boguk
On Thu, Dec 15, 2011 at 12:00 PM, bricklen wrote:
> On Wed, Dec 14, 2011 at 4:53 PM, Maxim Boguk
> wrote:
> > Here goes self-contained test case.
> >
> > I tested it on the 9.1.2, 9.1.1, 9.0.5, 9.0.4, 8.4.7
>
> I just tested on 9.1.2 and see the same issue.
&
ar problem.
>
> Maybe you'd get enthused enough to try to fix the problem?
>
> --
> Álvaro Herrera
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
--
Maxim Boguk
Senior Postgresql DBA.
Phone RU:
The following bug has been logged on the website:
Bug reference: 6335
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.0.4
Operating system: Linux Ubuntu
Description:
I was explored reasons of high DB load and I localized the next pro
ny way to perform that task it with reasonable efficiency?
--
Maxim Boguk
Senior Postgresql DBA.
The following bug has been logged on the website:
Bug reference: 6326
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.1.1
Operating system: Linux
Description:
SELECT ARRAY(SELECT ...)
doesn't work when subselect return any array.
T
On Mon, Nov 28, 2011 at 6:02 PM, Simon Riggs wrote:
> On Fri, Nov 25, 2011 at 6:33 PM, Tom Lane wrote:
> > Maxim Boguk writes:
> >> I know GIST on intarray[] do not have that problem.
> >> Very likely the problem is limited to intarray[] GIN indexes only
> >
On Fri, Nov 25, 2011 at 11:17 PM, Simon Riggs wrote:
> On Thu, Nov 24, 2011 at 11:12 PM, Maksym Boguk
> wrote:
>
> > postgres=# SELECT * from test where sections && '{2000}';
> > id | sections
> > +--
> > (0 rows)
> >
> > Ooops.
>
> Can you see if this is just intarray or if there a
every minute looping over
create table something_tmp as query (like 20M entries);
instant after
drop table something_tmp;
As a result of that instant drop - an insert volumes were missed by monitoring.
PS: xlogdump really great tool and it was good help in locating and
fixing problem.
--
Maxim Boguk
Senior Postgresql DBA.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ding broken in 9.1?
>
> No, but I think psql prefers to set its encoding according to its locale
> enviroment these days.
>
> regards, tom lane
>
--
Maxim Boguk
Senior Postgresql DBA.
Skype: maxim.boguk
Jabber: maxim.bo...@gmail.com
LinkedIn profile: http:/
hes/power-offs and so on happens on that database for more then year.
Can the second (16384 -> /db/base/main) link be safely deleted?
--
Maxim Boguk
Senior Postgresql DBA.
--
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: 6097
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.0 9.1beta
Operating system: Linux/Freebsd
Description:Server crash when enabling custom_variable_classes
Details:
I found
1040
#27 0x005c0b5a in main (argc=3, argv=0x7fffeb88) at main.c:188
On Sat, Jul 2, 2011 at 10:00 PM, Maxim Boguk wrote:
> Hi and thanks for responding...
>
> While i performing my tests I used pg_dump via local socket
> (
> pg_dump -F c -Z 0 -t changes -a db &
he data flow.
>
> To help with this sort of thing, reduce your send and receive buffer sizes.
> You'll pay a price in terms of throughput, but you'll gain responsiveness.
>
> Without more information, it's hard to know if this is anything except a
> buffering issue. Possib
The following bug has been logged online:
Bug reference: 6087
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.0
Operating system: Linux
Description:Unnest with multidimensional arrays
Details:
I not sure is it actual bug or
On Sat, Mar 26, 2011 at 4:17 AM, Tom Lane wrote:
> "Maxim Boguk" writes:
> > In my case vacuum tried to truncate last 10-15GB from 100Gb relation, and
> > each time (3) it was cost 10+ minutes of service downtime (because that
> > table was completely locked).
&
The following bug has been logged online:
Bug reference: 5946
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4
Operating system: Linux
Description:Long exclusive lock taken by vacuum (not full)
Details:
>From documentation I k
if I find anything else like that.
Now for me start digging next strange problem described here:
http://archives.postgresql.org/pgsql-admin/2011-01/msg00055.php
--
Maxim Boguk
Senior Postgresql DBA.
uple materialization code here as well.
PS: again may be just handwaving... I just started learn postgresql code.
Any help from more skilled persons would be great.
On Mon, Feb 21, 2011 at 10:07 AM, Tom Lane wrote:
> Maxim Boguk writes:
> > I tracked virtual tuple from heaptuple.c::slo
rted study gdb and
postgresql source code.
PPS: I must say thanks to authors of http://doxygen.postgresql.org . It is
great tool and saved me lot time today.
On Sun, Feb 20, 2011 at 12:01 PM, Maxim Boguk wrote:
>
>
> On Sun, Feb 20, 2011 at 5:08 AM, Tom Lane wrote:
>
>> Maxim
On Sun, Feb 20, 2011 at 5:08 AM, Tom Lane wrote:
> Maxim Boguk writes:
> > I finally managed create working slave server with non-stripped
> Postgresql
> > 8.4.7 and working gdb.
> > (sorry for such long delay).
> > And i can reproduce situation quite ea
ributes in returing values list.
On Sun, Feb 20, 2011 at 1:13 AM, Maxim Boguk wrote:
> Hi all and Hi Robert
>
> I finally managed create working slave server with non-stripped Postgresql
> 8.4.7 and working gdb.
> (sorry for such long delay).
> And i can reproduce situation quite easy
master.c:3467
#38 0x0063ab2a in BackendStartup (port=0x803703c00) at
postmaster.c:3081
#39 0x006382dc in ServerLoop () at postmaster.c:1387
#40 0x00637abb in PostmasterMain (argc=3, argv=0x7fffeb88) at
postmaster.c:1040
#41 0x005c0b5a in main (argc=3, argv=0x7fffeb88) at
On Wed, Feb 16, 2011 at 6:18 AM, Tom Lane wrote:
> Maxim Boguk writes:
> > Test case look like:
>
> > create table "references" ( attr_id integer, reference integer,
> > object_id integer );
> > insert into "references" select *100**(random()
ndex Scan using xif02references on "references" rs
(cost=0.00..0.58 rows=11 width=12) (actual time=0.036..0.079 rows=10
loops=1)
Index Cond: (object_id = 1000)
-> Index Scan using xif01references on "references" vm
(cost=0.00..0.53 rows=8 width=12) (actual time=0
The following bug has been logged online:
Bug reference: 5885
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.4
Operating system: Linux
Description:Strange rows estimation for left join
Details:
I found that strange effect while
On Tue, Dec 21, 2010 at 7:48 AM, Tom Lane wrote:
> "Maxim Boguk" writes:
>> Bad explain:
>> billing=# EXPLAIN SELECT * from domains where
>> name='"name"=>"somedomain"'::text::hstore->
e any help with creating a stack backtrace.
On Wed, Dec 22, 2010 at 5:22 PM, Robert Haas wrote:
> On Mon, Dec 20, 2010 at 9:48 PM, Maxim Boguk wrote:
>> Anyone can enlighten me what happens here?
>
> That does look weird, but without a simple test case I think it's
> going
The following bug has been logged online:
Bug reference: 5798
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.4
Operating system: FreeBSD 7.2
Description:Some weird error with pl/pgsql procedure
Details:
While I testing my table
The following bug has been logged online:
Bug reference: 5797
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.4
Operating system: Freebsd
Description:Strange bug with hstore
Details:
One day ago I analyzed slow query for one of
The following bug has been logged online:
Bug reference: 5649
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.4
Operating system: FreeBSD 7.2
Description:strange (probably bugged) explain analyze output
Details:
I not sure it is
ion somehow think need
return all columns of table including dropped column.
If this behavior is not a bug, than documentation should be changed
(because "or to build a complete new record/row to return" will never
work if table contained dropped columns).
On Mon, Jun 14, 2010 at 11:20 AM,
ight
> cause people problems, eg
> http://archives.postgresql.org/pgsql-hackers/2010-03/msg00444.php
> http://archives.postgresql.org/message-id/6645.1267926...@sss.pgh.pa.us
>
> regards, tom lane
>
--
Maxim Boguk
Senior Postgresql DBA.
Skype: maxim.
The following bug has been logged online:
Bug reference: 5328
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.1
Operating system: linux kernel v 2.6.18
Description:GIN index with fastupdates=on provide wrong result on
bitmap scan
65 matches
Mail list logo
