libraries
sharing some of the data among them.
Thanks once again,
Michal
--
Michal Novotny
System Development Lead
michal.novo...@greycortex.com
GREYCORTEX s.r.o.
Purkynova 127, 61200 Brno
Czech Republic
www.greycortex.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
x27;ve been able to
find the issue.
Thanks again,
Michal
--
Michal Novotny
System Development Lead
michal.novo...@greycortex.com
GREYCORTEX s.r.o.
Purkynova 127, 61200 Brno
Czech Republic
www.greycortex.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
comments inline ...
On 06/29/2017 03:08 PM, Merlin Moncure wrote:
On Thu, Jun 29, 2017 at 4:01 AM, Michal Novotny
wrote:
Hi all,
we've developed an application using libpq to access a table in the PgSQL
database but we're sometimes experiencing segmentation fault on
resetP
SC", nParams=1, paramTypes=0x0, paramValues=0xa2b7b0, paramLengths=0x0, paramFormats=0x0, resultFormat=0) at fe-exec.c:1871
No locals.
Unfortunately we didn't have more information from the crash, at least
for now.
Is this a known issue and can you help me with this one?
Than
Hi Andres,
thanks a lot. I've managed to run DROP TABLE and then cancel process
using pg_cancel_backend(autovacuum_pid) and it passed and dropped the 5T
table.
Thanks a lot!
Michal
On 01/12/2016 12:37 PM, Andres Freund wrote:
> Hi,
>
> On 2016-01-12 12:17:01 +0100, Michal
Hi Andres,
On 01/12/2016 12:37 PM, Andres Freund wrote:
> Hi,
>
> On 2016-01-12 12:17:01 +0100, Michal Novotny wrote:
>> thanks a lot for your reply. Unfortunately I've found out most it didn't
>> really start DROP TABLE yet and it's locked on autovacuum ru
On 01/12/2016 12:20 PM, Andres Freund wrote:
> On 2016-01-12 12:17:09 +0100, Pavel Stehule wrote:
>> 2016-01-12 12:14 GMT+01:00 Michal Novotny :
>>
>>> Hi Pavel,
>>> thanks for the information. I've been doing more investigation of this
>>> is
evelopment. -general or -performance would have been more appropriate.
>
> On 2016-01-12 11:57:05 +0100, Michal Novotny wrote:
>> I've discovered an issue with dropping a large table (~5T). I was
>> thinking drop table is fast operation however I found out my assumption
>>
rop instead?
Thanks,
Michal
On 01/12/2016 12:01 PM, Pavel Stehule wrote:
> Hi
>
> 2016-01-12 11:57 GMT+01:00 Michal Novotny <mailto:michal.novo...@trustport.com>>:
>
> Dear PostgreSQL Hackers,
> I've discovered an issue with dropping a large table (~5T)
Dear PostgreSQL Hackers,
I've discovered an issue with dropping a large table (~5T). I was
thinking drop table is fast operation however I found out my assumption
was wrong.
Is there any way how to tune it to drop a large table in the matter of
seconds or minutes? Any configuration variable in the
Hi Christopher,
thanks a lot for your suggestion however I need to run against dump
files so it's useless for me.
Thanks anyway,
Michal
On 10/13/2015 07:23 PM, Christopher Browne wrote:
> On 13 October 2015 at 11:48, Michal Novotny
> mailto:michal.novo...@trustport.com>> w
est regards
>
> P.S. I think that this is the wrong list for questione like this one.
>
> On Wed, Oct 14, 2015 at 10:26 AM, Shulgin, Oleksandr
> mailto:oleksandr.shul...@zalando.de>> wrote:
>
> On Tue, Oct 13, 2015 at 5:48 PM, Michal Novotny
> mailto:micha
Hi,
thanks a lot for your reply, unfortunately it's not working at all, I
run it as:
# java -jar apgdiff-2.4.jar
But it's stuck on the futex wait so unfortunately it didn't work at all.
Thanks for the reply anyway,
Michal
On 10/14/2015 01:53 PM, Иван Фролков wrote:
>> I would like to ask yo
Hi guys,
I would like to ask you whether is there any tool to be able to compare
database schemas ideally no matter what the column order is or to dump
database table with ascending order of all database columns.
For example, if I have table (called table) in schema A and in schema B
(the time di
14 matches
Mail list logo
