On Thu, Nov 12, 2009 at 4:42 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev gray...@gmail.com wrote:
Was this situation mentioned before and is there a solution or
workaround? (I didn't find any) If not please give me a glue where to
dig or what
On Mon, Nov 16, 2009 at 9:56 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Sergey Konoplev escribió:
I tried to get locks with this queries
Did you try pg_locks?
I tried monitor locks with pgrowlocks. Isn't it better way? If it
isn't what points should I pay attention with pg_lock
to normal for you.
Here it is http://pastie.org/702742
--
Regards,
Sergey Konoplev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Nov 16, 2009 at 10:17 PM, Andres Freund and...@anarazel.de wrote:
On Wednesday 11 November 2009 18:50:46 Sergey Konoplev wrote:
Hello community,
Second time after migration 8.3.7 -- 8.4.1 I was caught by this
problem. Migration was 8 days ago.
(note, I never seen such situation
?
--
Regards,
Sergey Konoplev
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in
update to use DEFAULT value of the column.
IMHO convenient solution is to make possible to specify something like
COLUMN_DEFAULT as input value of function.
I wonder if it's possible.
--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english russian
http://gray-hemp.blogspot.com/search/label
IMHO convenient solution is to make possible to specify something like
COLUMN_DEFAULT as input value of function.
I wonder if it's possible.
So, what do you think of it?
--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english russian
http://gray-hemp.blogspot.com/search/label
(COALESCE(obj_main_pic_obj_id, 0::bigint)::double precision) DESC,
obj_created DESC) WHERE obj_status_did = 1;
And you will see something like this http://drop.io/5tla8sg
p.s. One thing I have forgotten to write - I tried it on Ubuntu 9.04,
PG was built from sources.
--
Regards,
Sergey Konoplev
.
Was this situation mentioned before and is there a solution or
workaround? (I didn't find any) If not please give me a glue where to
dig or what information should I provide?
Thank you.
--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english russian
http://gray-hemp.blogspot.com/search
var_name text := 'bla';
BEGIN
RAISE INFO '%', func_alias.var_name;
...
--
Sergey Konoplev
Blog: http://gray-hemp.blogspot.com /
Linkedin: http://ru.linkedin.com/in/grayhemp /
JID/GTalk: gray...@gmail.com / Skype: gray-hemp / ICQ: 29353802
--
Sent via pgsql-hackers mailing list (pgsql
for the test case and report.
p.s. The user Andrew mentioned above is me and if you have a question
to me I am ready to answer it.
--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english russian
http://gray-hemp.blogspot.com/search/label/postgresql/
--
Sent via pgsql-hackers mailing list (pgsql
assumption is
absolutely correct and I welcome your criticism.
--
Regards,
Sergey Konoplev
--
PostgreSQL articles in english russian
http://gray-hemp.blogspot.com/search/label/postgresql/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
; stanullfrac | stawidth
-+--(0 rows)
grayhemp@[local]:5432 test=#analyze t1;ANALYZEgrayhemp@[local]:5432
test=#select stanullfrac, stawidth from pg_statistic where starelid =
't1'::regclass; stanullfrac | stawidth -+--
0 | 4(1 row)
--
Sergey Konoplev
Blog
On Fri, Jan 27, 2012 at 9:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 14, 2012 at 7:34 AM, Sergey Konoplev gray...@gmail.com wrote:
I've added a note to that effect to the documentation for ANALYZE,
which seems like a more appropriate place than the pg_statistic
documentation
://www.postgresql.org/mailpref/pgsql-hackers
--
Sergey Konoplev
a database and software architect
http://www.linkedin.com/in/grayhemp
Jabber: gray...@gmail.com Skype: gray-hemp Phone: +79160686204
Streaming replication based failover
Let us suppose that there is a hot standby replication set up
-visible according to the
visibility map. Did we mean to test (nonempty_pages 0) there ? But
even that may not work except for the case when there are no dead
tuples in the relation.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sergey Konoplev
Blog
(pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Kind regards,
Sergey Konoplev
Database and Software Consultant
Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988
)
is of segment 0001000E00A7.
Wonder if whatever configuration he is using is sub-optimal that these
many WAL segments can be re-cycled upon a checkpoint? Or is this okay?
Is archive_mode=on?
What is archive_command?
Is the server in the recovery mode?
--
Kind regards,
Sergey Konoplev
/restore plus trigger
based replication (londiste, slony) to migrate data.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979
Skype: gray-hemp
Jabber: gray...@gmail.com
/pgstattuple.html
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979
Skype: gray-hemp
Jabber: gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
|
204321460 | 3.21 | 5939017376 | 93.32
(1 row)
I guess you need to VACUUM FULL pg_attribute, if it is possible in
your situation of course. If it is not, let me know, I have another
one tricky way of solving this problem in my mind.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant
that intensively create tables or columns
and then delete them or create them in transaction and rollback the
transaction?
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray...@gmail.com
.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
jumps
from 1.82 to 70.07 in one minute, so I suppose an empty tail is
inevitable anyway, so there should be locks to truncate by vacuum, if
I understand things correct.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901
-longexclusive-locks/
Are there any caveats?
Thank you.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Wed, Sep 18, 2013 at 2:06 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-17 23:12:24 -0700, Sergey Konoplev wrote:
How safe is it to use the technique described by the link below with
system catalog tables to remove bloat?
(in a couple of words it is about moving tuples
not the only person
who faced these nuances.
According to this I would like to know if it is possible to move
pgstattuple to core? And if it is I would like to request this
feature.
Thank you.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1
? In what way is
pgstattuple like or not like the other things that are in core?
I would highlight it as it became a kind of routine one. Also,
sometimes it is required to solve problems, not to make new features,
so it often can not wait.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant
of
9.3? IMHO hugepages is a very important ability that postgres lost in
9.3, and it would be great to have it back ASAP.
Thank you.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray
On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sergey Konoplev gray...@gmail.com writes:
On Wed, Oct 23, 2013 at 11:03 PM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
This is a slightly reworked version of the patch submitted by Richard
Poole last month, which
On Wed, Oct 30, 2013 at 8:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Sergey Konoplev gray...@gmail.com writes:
On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Say what? There's never been any hugepages support in Postgres.
There were an ability to back shared memory
dynamic_shared_memory_type in file
/etc/postgresql/9.3/main/postgresql.conf line 114
FATAL: configuration file /etc/postgresql/9.3/main/postgresql.conf
contains errors
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888
. And the win becomes mostly significant when you
have 64GB and more on your server.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list
On Wed, Oct 30, 2013 at 12:51 PM, Sergey Konoplev gray...@gmail.com wrote:
On Wed, Oct 30, 2013 at 12:17 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I wasn't talking about a built-in support. It was about an ability (a
way) to back sh_buf with hugepages.
Then what you need is to set
*r.y;
end; $$ language plpgsql strict stable;
create function volume(r derived_table) returns integer as $$ begin
return volume(r::base_table) *r.z;
end; $$ language plpgsql strict stable;
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415
On Mon, Dec 30, 2013 at 2:03 AM, knizhnik knizh...@garret.ru wrote:
On 12/30/2013 01:22 AM, Sergey Konoplev wrote:
On Sun, Dec 29, 2013 at 8:44 AM, knizhnik knizh...@garret.ru wrote:
But passing direved_table type instead of base_table type to volume()
function for record belonging
:
http://www.postgresql.org/message-id/flat/CAL_0b1s4QCkFy_55kk_8XWcJPs7wsgVWf8vn4=jxe6v4r7h...@mail.gmail.com
This problem worries me a lot too. If someone is interested I still
have a file system copy of the buggy cluster including WAL.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant
Hi everyone,
On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich stas.kelv...@gmail.com wrote:
Here is the patch that introduces kNN search for cubes with euclidean,
taxicab and chebyshev distances.
What is the status of this patch?
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
On Thu, Mar 27, 2014 at 3:26 PM, Sergey Konoplev gray...@gmail.com wrote:
On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich stas.kelv...@gmail.com wrote:
Here is the patch that introduces kNN search for cubes with euclidean,
taxicab and chebyshev distances.
What is the status of this patch
Hamming/Manhattan distance
experiments/thoughts/discussions, if kNN can be used here or not,
because from my understanding it can be represented as spatial (I
might be very wrong here).
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867
was copied, timeline id was 0 after upgrade, but
skytools3 sometimes still didn't like it. Also note sometimes here,
so in some cases everything was okay, but in some it wasn't. I still
can't explain this, but incrementing timeline id always helped.
--
Kind regards,
Sergey Konoplev
PostgreSQL
On Tue, Apr 22, 2014 at 8:08 PM, Sergey Burladyan eshkin...@gmail.com wrote:
On Wed, Apr 23, 2014 at 6:38 AM, Sergey Konoplev gray...@gmail.com wrote:
BTW, I didn't manage to make a test case yet. Recently, when I was
migrating several servers to skytools3 and upgrading from 9.0 to 9.2,
I
systems.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Tue, Sep 2, 2014 at 7:59 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote:
On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian br...@momjian.us wrote:
Sergey, are you seeing a problem only because you are
interacting with other systems
archive_directory in the target directory :(
I started getting these errors after upgrading from 9.2.8 to 9.2.10.
Is it something critical that requires version downgrade or I can just
ignore that errors?
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1
: disconnected..
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (499) 346-7196, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
need some extra info or debugging.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (499) 346-7196, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
quite easily be worked
around by creating the archive_status directory.
The workaround works perfectly for me in this case, I'm going to
updrade it up to 9.4 anyway soon.
Thank you, Andres.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415
48 matches
Mail list logo
