es don't have pg_receivexlog) and can 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
ome 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 to you
archive_status/000402B60019.done":
No such file or directory
pg_receivexlog: 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 pg
; Dang. Stupid typo. And my tests didn't catch it, because I had
>> > 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
On Tue, Sep 2, 2014 at 7:59 PM, Bruce Momjian 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 wrote:
>> > Sergey, are you seeing a problem only because you are
>> > interacting with other syst
ny other 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 su
On Tue, Apr 22, 2014 at 8:08 PM, Sergey Burladyan wrote:
> On Wed, Apr 23, 2014 at 6:38 AM, Sergey Konoplev 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 not
noticed that epoch 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.
--
ny postgres related indexable 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.
On Thu, Mar 27, 2014 at 3:26 PM, Sergey Konoplev wrote:
> On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich wrote:
>> Here is the patch that introduces kNN search for cubes with euclidean,
>> taxicab and chebyshev distances.
>
> What is the status of this patch?
Ref
Hi everyone,
On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich 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
ell:
>
>
> 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 Konop
On Mon, Dec 30, 2013 at 2:03 AM, knizhnik wrote:
> On 12/30/2013 01:22 AM, Sergey Konoplev wrote:
>> On Sun, Dec 29, 2013 at 8:44 AM, knizhnik wrote:
>>> But passing direved_table type instead of base_table type to volume()
>>> function for record belonging to derived
unction volume(r base_table) returns integer as $$ begin
return r.x*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
Postgre
On Wed, Oct 30, 2013 at 12:51 PM, Sergey Konoplev wrote:
> On Wed, Oct 30, 2013 at 12:17 PM, Alvaro Herrera
> wrote:
>>> > I wasn't talking about a built-in support. It was about an ability (a
>>> > way) to back sh_buf with hugepages.
&
are several articles in the web describing how to do this,
except the mine one. 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-
I found this parameter in the docs nor it works when I specify
it in postgresql.conf.
LOG: unrecognized configuration parameter
"dynamic_shared_memory_type" in file
"/etc/postgresql/9.3/main/postgresql.conf" line 114
FATAL: configuration file "/etc/postgresql/9.3/main/postgr
On Wed, Oct 30, 2013 at 8:11 AM, Tom Lane wrote:
> Sergey Konoplev writes:
>> On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane wrote:
>>> Say what? There's never been any hugepages support in Postgres.
>
>> There were an ability to back shared memory with hugepages
On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane wrote:
> Sergey Konoplev writes:
>> On Wed, Oct 23, 2013 at 11:03 PM, Abhijit Menon-Sen
>> wrote:
>>> This is a slightly reworked version of the patch submitted by Richard
>>> Poole last month, which was based o
f
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...@gmail.com
ed: Why should we do this here? 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,
Se
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
On Wed, Sep 18, 2013 at 2:06 AM, Andres Freund 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 tuple
-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
uncate will be a non-issue.
Well, according to the pgstattuple log OP showed, free percent 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
Postg
is issue.
--
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
ne day?
Do you have some processes 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) 8
830040 | 0.11 | 1459439 |
> 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.
--
Kin
.2/interactive/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 (p
ther full dump/restore or schema only dump/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-197
37)
> 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
s
>
> --
> looking forward
> thanks
>>
> Mikhail
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Kind regards,
Sergey Konoplev
Da
ng list (pgsql-gene...@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
> --
> Bruce Momjian http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It&#
On Fri, Jan 27, 2012 at 9:14 PM, Robert Haas wrote:
> On Sat, Jan 14, 2012 at 7:34 AM, Sergey Konoplev 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.
Thank you.
>
lid = 't1'::regclass; 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 |
n relpages
> if the last page in the relation is all-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
>
> --
lt;< func_alias >>
DECLARE
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 / I
do when the problem rise up again?
--
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 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.
>>
on't know how that compares 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 9:56 PM, Alvaro Herrera
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 wit
On Thu, Nov 12, 2009 at 4:42 AM, Robert Haas wrote:
> On Wed, Nov 11, 2009 at 12:50 PM, Sergey Konoplev 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 in
e situation.
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
person_vislvl,
(COALESCE(person_photo_is_best::integer, 0)) DESC,
sign(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 Ubun
> 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.b
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/sea
rse not being pg-hacker I can't guaranty that my 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 (p
t 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-h
48 matches
Mail list logo
