Re: Add client connection check during the execution of the query

application shutdown then client OS should itself properly close than connection and therefore this patch will detect such situation without keepalives configured. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Read-only access to temp tables for 2PC transactions

> On 14 May 2019, at 12:53, Stas Kelvich wrote: > > Hi, > > That is an attempt number N+1 to relax checks for a temporary table access > in a transaction that is going to be prepared. > Konstantin Knizhnik made off-list review of this patch and spotted few problems.

Read-only access to temp tables for 2PC transactions

transaction, so during commit, only tables from that hash will be truncated. That way ON COMMIT DELETE tables in the backend will not prevent read-only access to some other table in a given backend. Any thoughts? -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian

XLogInsert() of dangling pointer while logging replica identity

Hi, hackers. It seems that heapam.c:3082 calls XLogRegisterData() with an argument allocated on stack, but following call to XLogInsert() happens after end of context for that variable. Issue spotted by clang's AddressSanitizer. Fix attached. -- Stas Kelvich Postgres Professional: http

Re: Global snapshots

> On 31 Jan 2019, at 18:42, Andres Freund wrote: > > Hi, > > On 2018-11-30 16:00:17 +0300, Stas Kelvich wrote: >>> On 29 Nov 2018, at 18:21, Dmitry Dolgov <9erthali...@gmail.com> wrote: >>> Is there any resulting patch where the ideas how to implement

Re: Global snapshots

nces bunch of previous articles and [REED78] is one them) was actually about distributed transactions and uses more or less the same approach with pseudo-time in their terminology to order transaction and assign snapshots. [HARD17] https://dl.acm.org/citation.cfm?id=3055548 [REED78] https://dl.a

Re: Global snapshots

ible to achieve READ COMMITED with postgres_fwd using global snapshots. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Global snapshots

h set and that it will be possible to address that later (in a long run such connection will be anyway needed at least for a deadlock detection). However, if you think that current behavior + STO analog isn't good enough, then I'm ready to pursue that track. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Global snapshots

int of view, but it's not obvious how to integrate that into postgres_fdw. Probably that will require bi-derectional connection between postgres_fdw nodes (also distributed deadlock detection will be easy with such connection). -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Global snapshots

always gives a value that were global_snapshot_xmin seconds ago and we have mapping from time (or GlobalCSN) to globalxmin for each second in this range. So when some backends imports global snapshot with some GlobalCSN, that GlobalCSN is mapped to a xmin and this xmin is set as a Proc->xmin. -- S

Re: Global snapshots

> On 3 May 2018, at 18:28, Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Wed, May 2, 2018 at 1:27 AM, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: >> 1) To achieve commit atomicity of different nodes intermediate step is >> introduced: at fi

Re: Global snapshots

> On 2 May 2018, at 05:58, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> > wrote: > > On 5/1/18 12:27, Stas Kelvich wrote: >> Clock-SI is described in [5] and here I provide a small overview, which >> supposedly should be enough to catch the idea. Assume

Re: Global snapshots

me(). And clock time is supposedly more or less the same on different nodes in normal condition. But correctness here will not depend on degree of clock synchronisation, only performance of global transactions will. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

FinishPreparedTransaction missing HOLD_INTERRUPTS section

and therefore can cancel backend or throw an error before GXact clean-up. Other similar places like CommitTransaction and PrepareTransaction have such hold interrupts sections. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company 0001-Add

Re: unused_oids script is broken with bsd sed

> On 25 Apr 2018, at 17:55, John Naylor <jcnay...@gmail.com> wrote: > > On 4/25/18, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: >>> On 25 Apr 2018, at 17:18, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I think we should rewrite >>> both of

Re: unused_oids script is broken with bsd sed

> On 25 Apr 2018, at 17:18, Tom Lane <t...@sss.pgh.pa.us> wrote: > I think we should rewrite > both of them to use the Catalog.pm infrastructure. Okay, seems reasonable. I'll put shared code in Catalog.pm and update patch. -- Stas Kelvich Postgres Professional: http://www.

Re: unused_oids script is broken with bsd sed

astructure. > > regards, tom lane Hm, I attached patch in first message, but seems that my mail client again messed with attachment. However archive caught it: https://www.postgresql.org/message-id/attachment/60920/0001-Rewrite-unused_oids-in-perl.patch -- Stas

Re: [HACKERS] logical decoding of two-phase transactions

be zero, so this way logical replication between postgres-10 and postgres-with-2pc-decoding will be broken. So ISTM it’s better to set LOGICALREP_IS_COMMIT to zero and change flags checking rules to accommodate that. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] logical decoding of two-phase transactions

cluding the additional regular and tap >> tests that we have added as part of this patch. >> > > PFA, latest version of this patch. > > This latest version takes care of the abort-while-decoding issue along > with additional test cases and documentation changes. > > -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Issues with logical replication

GetRunningTransactionData it possible to have a custom lock there. In this case GetRunningTransactionData will hold three locks simultaneously, since it already holds ProcArrayLock and XidGenLock =) Any better ideas? -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company xltw_fix.diff Description: Binary data

Re: [HACKERS] Issues with logical replication

25 I’ve quickly checked other usages of XactLockTableWait() and it seems that it is used mostly with xids from heap so tx definetly set it lock somewhere in the past. Not sure what it the best approach to handle that. May be write running xacts only if they already set their lock? Also attachi

Re: [HACKERS] logical decoding of two-phase transactions

le then (imho) it is better to just forbid to prepare such transactions. Otherwise if some realistic examples that can block decoding are actually exist, then we probably need to reconsider the way tx being decoded. Anyway this part probably need Andres blessing. Stas Kelvich

Re: [HACKERS] Transactions involving multiple postgres foreign servers

jour_2014.pdf [3] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/samehe-clocksi.srds2013.pdf [4] https://github.com/ept/hermitage Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] Transactions involving multiple postgres foreign servers

ow fdw doesn’t guarantee neither isolation nor atomicity. And if one isn’t doing cross-node analytical transactions it will be safe to live without isolation. But living without atomicity means that some parts of data can be lost without simple way to detect and fix that. Stas Kelvich Pos

Re: [HACKERS] Dynamic instrumentation of lwlock wait times (lwlock flamegraphs)

er > stack > - ... > > I think it might be interesting to collect a few of these somewhere > centrally once halfway mature. Maybe in src/tools or such. Wow, that’s extremely helpful, thanks a lot. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres C

Re: [HACKERS] snapbuild woes

uld not fsync file "pg_logical/mappings/map-4000-4df-0_A4EA29F8-5aa5-5ae6": Too many open files in system I’m not sure whether this is boils down to some of the previous issues mentioned here or not, so posting here as observation. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical replication ApplyContext bloat

every message >> (as the name implies), not only some messages. > > Committed that. > >> Also, perhaps ApplyMessageContext should be a child of >> TopTransactionContext. (You have it as a child of ApplyContext, which >> is under TopMemoryContext.) > >

Re: [HACKERS] Logical replication ApplyContext bloat

> On 20 Apr 2017, at 17:01, Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Thu, Apr 20, 2017 at 7:04 PM, Stas Kelvich <s.kelv...@postgrespro.ru> > wrote: >> Thanks for noting. >> >> Added short description of ApplyContext and ApplyMessageContext to

Re: [HACKERS] Logical replication ApplyContext bloat

> On 19 Apr 2017, at 16:07, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Stas Kelvich wrote: > >> With patch MemoryContextStats() shows following hierarchy during slot >> operations in >> apply worker: >> >> TopMemoryContext: 83824 tot

Re: [HACKERS] Logical replication ApplyContext bloat

> On 19 Apr 2017, at 14:30, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: > > On 19/04/17 12:46, Stas Kelvich wrote: >> >> Right now ApplyContext cleaned after each transaction and by this patch I >> basically >> suggest to clean it after eac

Re: [HACKERS] Logical replication ApplyContext bloat

probably better just explicitly call reset at the end of each function involved. > > -- > Simon Riggs http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services Stas Kelvich Postgres Professional: http://www.postgrespro

Re: [HACKERS] Logical replication ApplyContext bloat

> On 19 Apr 2017, at 12:37, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: > > On 18/04/17 13:45, Stas Kelvich wrote: >> Hi, >> >> currently logical replication worker uses ApplyContext to decode received >> data >> and that context is nev

[HACKERS] Logical replication ApplyContext bloat

. applycontext_bloat.patch Description: Binary data Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c

; I’ve reproduced failure, this happens under tablesync worker and putting pgstat_report_stat() under the previous condition block should help. However for me it took about an hour of running this script to catch original assert. Can you check with that patch applied? logical_worke

Re: [HACKERS] Failed recovery with new faster 2PC code

two crash bugs in as many days and lack of clarity about > how to fix it. > > Stas, I thought this patch was very important to you, yet two releases > in a row we are too-late-and-buggy. I’m looking at pgstat issue in nearby thread right now and will switch to this shortly. If that

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

esearch whether it is possible to create special code path for COPY in which errors don’t cancel transaction. At least when COPY called outside of transaction block. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hack

Run same pipeline on all nodes (and with different params)

Hi there. I'm now using declarative Jenkinsfile to build C project and run bunch of tests and observe results in blue ocean interface. However also I want to be able to run whole pipeline on different OSes and different compilers/buildoptions. I tried to write Jenkinsfile that runs nodes in

Re: [HACKERS] logical replication worker and statistics

> On 10 Apr 2017, at 19:50, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> > wrote: > > On 4/10/17 05:49, Stas Kelvich wrote: >> Here is small patch to call statistics in logical worker. Originally i >> thought that stat >> collection during logical

Re: [HACKERS] logical replication worker and statistics

> On 10 Apr 2017, at 05:20, Noah Misch <n...@leadboat.com> wrote: > > On Wed, Apr 05, 2017 at 05:02:18PM +0300, Stas Kelvich wrote: >>> On 27 Mar 2017, at 18:59, Robert Haas <robertmh...@gmail.com> wrote: >>> On Mon, Mar 27, 2017 at 11:14 AM, Fu

Re: [HACKERS] logical replication worker and statistics

and no statistics about >> table accesses by logical replication workers are collected. >> For example, this can prevent autovacuum from working on >> those tables properly. > > Yeah, that doesn't sound good. Seems that nobody is working on this, so i’m going to cre

Re: [HACKERS] logical decoding of two-phase transactions

repared tx nobody yet found such cases and it is hard to address or argue about. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company logical_twophase_v6.diff Description: Binary data logical_twophase_regresstest.diff Description: Binary data -- Sent via

Re: [HACKERS] logical decoding of two-phase transactions

ements logic i’ve just described. There is runtest.sh script that setups postgres, runs python logical consumer in background and starts regression test. Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company logical_twophase_v5.diff Description: Binary data

Re: [HACKERS] logical decoding of two-phase transactions

> On 28 Mar 2017, at 00:25, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: >> Ok, here it is. > > On a very quick skim, this doesn't seem to solve the issues around > deadlocks of prepared tr

Re: [HACKERS] logical decoding of two-phase transactions

> On 28 Mar 2017, at 00:19, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: > > * It is actually doesn’t pass one of mine regression tests. I’ve added > expected output > as it should be. I’ll try to send follow up message with fix, but right now > sending it > as is,

Re: [HACKERS] logical decoding of two-phase transactions

> On 27 Mar 2017, at 16:29, Craig Ringer <cr...@2ndquadrant.com> wrote: > > On 27 March 2017 at 17:53, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: > >> I’m heavily underestimated amount of changes there, but almost finished >> and will send updated patch

Re: [HACKERS] logical decoding of two-phase transactions

t useful for the main case when commit/abort is generated after receiver side will answer to prepares. Also that two-pass scan is a massive change in relcache.c and genam.c (FWIW there were no problems with cache, but some problems with index scan and handling one-to-many queries to catalog, e.g

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

> On 23 Mar 2017, at 15:53, Craig Ringer wrote: > > On 23 March 2017 at 19:33, Alexey Kondratov > wrote: > >> (1) Add errors handling to COPY as a minimum program > > Huge +1 if you can do it in an efficient way. > > I think the main

Re: [HACKERS] logical decoding of two-phase transactions

> On 20 Mar 2017, at 16:39, Craig Ringer <cr...@2ndquadrant.com> wrote: > > On 20 March 2017 at 20:57, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: >> >>> On 20 Mar 2017, at 15:17, Craig Ringer <cr...@2ndquadrant.com> wrote: >>> >&g

Re: [HACKERS] logical decoding of two-phase transactions

or > something, to make it clear what we're doing. Yes, that will be less confusing. However there is no any kind of queue, so SnapBuildStartPrepare / SnapBuildFinishPrepare should work too. > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 2

Re: [HACKERS] logical decoding of two-phase transactions

n 17 Mar 2017, at 05:38, Craig Ringer <cr...@2ndquadrant.com> wrote: > > On 16 March 2017 at 19:52, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: > >> >> I’m working right now on issue with building snapshots for decoding prepared >> tx. >> I hope

Re: [HACKERS] logical decoding of two-phase transactions

me of decoding prepare record we already know that it is aborted than such decoding doesn’t have a lot of sense. IMO intended usage of logical 2pc decoding is to decide about commit/abort based on answers from logical subscribers/replicas. So there will be barrier between prepare and commit/abort

Re: [HACKERS] logical decoding of two-phase transactions

> On 16 Mar 2017, at 14:44, Craig Ringer wrote: > > I'm going to try to pick this patch up and amend its interface per our > discussion earlier, see if I can get it committable. I’m working right now on issue with building snapshots for decoding prepared tx. I hope I'll

Re: [HACKERS] logical decoding of two-phase transactions

form prepare decoding with some kind of copied-end-edited snapshot. I’ll have a look at this. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical decoding of two-phase transactions

points about this topic. Or, maybe, I’m failing to understand some points. Can we maybe setup skype call to discuss this and post summary here? Craig? Peter? -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mai

[HACKERS] Walsender crash

14: 0x00010e76371f postgres`main(argc=3, argv=0x7fbcabc02b90) + 751 at main.c:228 frame #15: 0x7fffa951c255 libdyld.dylib`start + 1 frame #16: 0x7fffa951c255 libdyld.dylib`start + 1 Patch with lacking initStringInfo() attached. init_reply_message.diff Description: Binary

Re: [HACKERS] logical decoding of two-phase transactions

= 0/D8B43E28 and with 194-byte GID’s difference in WAL size is about 18% So using big GID’s (as J2EE does) can cause notable WAL bloat, while small GID’s are almost unnoticeable. May be we can introduce configuration option track_commit_gid by analogy with track_commit_timestamp and make tha

Re: [HACKERS] logical decoding of two-phase transactions

MIT/ABORT 4. COMMIT/ABORT decoded and sent After step 3 there is no more memory state associated with that prepared tx, so if will fail between 3 and 4 then we can’t know GID unless we wrote it commit record (or table). -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian

Re: [HACKERS] Speedup twophase transactions

gt; KnownPreparedList in the code path that follows as well as elsewhere. Thanks Nikhil, now I got that. Since we are talking about promotion we are on different timescale and 1-10 second lag matters a lot. I think I have in my mind realistic scenario when proposed recovery code path will hit

Re: [HACKERS] logical decoding of two-phase transactions

we should invent something more nasty like writing them into a table. > That should eliminate Simon's > objection re the cost of tracking GIDs and still let us have access to > them when we want them, which is the best of both worlds really. Having 2PC decoding in core is a good thing an

Re: [HACKERS] Speedup twophase transactions

e segments should be re-read after cache drop) master, without constant cache_drop: time to recover 35 segments: 2h 25m (after that i tired to wait) expected total recovery time: 4.5 hours -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical decoding of two-phase transactions

GID on all of the child nodes then we don't need to add the > GID. Yes, that’s also possible but seems to be less flexible restricting us to some specific GID format. Anyway, I can measure WAL space overhead introduced by the GID’s inside commit records to know exactly what will be th

Re: [HACKERS] logical decoding of two-phase transactions

d GID to any WAL records, nor to any in-memory structures. Other part of the story is how to find GID during decoding of commit prepared record. I did that by adding GID field to the commit WAL record, because by the time of decoding all memory structures that were holding xid<->gid cor

[HACKERS] logical decoding of two-phase transactions

logical replication. [1] https://www.postgresql.org/message-id/EE7452CA-3C39-4A0E-97EC-17A414972884%40postgrespro.ru logical_twophase.diff Description: Binary data -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers

Re: [HACKERS] Speedup twophase transactions

m to reduce the overall noise between > two measurements though. Okay, i’ll perform such testing. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Speedup twophase transactions

filesystem cache applies here as well, but just without spending time on file creation. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Speedup twophase transactions

> It must have been stripped by our email system. You were a direct CC so > you received it. > Then, probably, my mail client did something strange. I’ll check. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers

Re: [HACKERS] Speedup twophase transactions

On 27 Sep 2016, at 03:30, Michael Paquier wrote:OK. I am marking this patch as returned with feedback then. Lookingforward to seeing the next investigations.. At least this review hastaught us one thing or two.So, here is brand new implementation of the same thing.Now

[HACKERS] Stats sender and 2pc minor problem

of 0. Fix along with test is attached. 2pc-stats.patch Description: Binary data -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] WIP: About CMake v2

. Tried to generate Xcode project out of cmake, build fails on genbki.pl: can't locate Catalog.pm (which itself lives in src/backend/catalog/Catalog.pm) -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] assert violation in logical messages serialization

-- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Speedup twophase transactions

> On 21 Sep 2016, at 10:32, Michael Paquier <michael.paqu...@gmail.com> wrote: > > On Tue, Sep 20, 2016 at 11:13 PM, Stas Kelvich <s.kelv...@postgrespro.ru> > wrote: >> >> Putting that before actual WAL replay is just following historical order of >> e

Re: [HACKERS] Speedup twophase transactions

t is possible even without DSM, it possible to allocate static sized array storing some info about tx, whether it is in the WAL or in file, xid, gid. Some sort of PGXACT doppelganger only for replay purposes instead of using normal one. So taking into account my comments what do you think? Sh

Re: [HACKERS] Speedup twophase transactions

> On 07 Sep 2016, at 11:07, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: > >> On 07 Sep 2016, at 03:09, Michael Paquier <michael.paqu...@gmail.com> wrote: >> >>>> On 06 Sep 2016, at 12:03, Michael Paquier <michael.paqu...@gmail.com> >>>

Re: [HACKERS] Suggestions for first contribution?

handler.html [2] https://www.postgresql.org/docs/current/static/gist-extensibility.html -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Bug in two-phase transaction recovery

at StandbyRecoverPreparedTransactions() i’ve noticed that buffer for 2pc file is allocated in TopMemoryContext but never freed. That probably exists for a long time. gidlen_fixes.diff Description: Binary data standby_recover_pfree.diff Description: Binary data -- Stas Kelvich Postgres

Re: [HACKERS] Speedup twophase transactions

> On 07 Sep 2016, at 03:09, Michael Paquier <michael.paqu...@gmail.com> wrote: > >>> On 06 Sep 2016, at 12:03, Michael Paquier <michael.paqu...@gmail.com> wrote: >>> >>> On Tue, Sep 6, 2016 at 5:58 PM, Stas Kelvich <s.kelv...@postgrespro.ru&g

Re: [HACKERS] Speedup twophase transactions

> On 06 Sep 2016, at 12:09, Simon Riggs <si...@2ndquadrant.com> wrote: > > On 6 September 2016 at 09:58, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: >> >> I'll check it against my failure scenario with subtransactions and post >> results or updated pat

Re: [HACKERS] Speedup twophase transactions

> On 06 Sep 2016, at 04:41, Michael Paquier <michael.paqu...@gmail.com> wrote: > > On Sat, Sep 3, 2016 at 10:26 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Fri, Sep 2, 2016 at 5:06 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>

Re: [HACKERS] Logical decoding restart problems

> On 31 Aug 2016, at 03:28, Craig Ringer <cr...@2ndquadrant.com> wrote: > > On 25 Aug. 2016 20:03, "Stas Kelvich" <s.kelv...@postgrespro.ru> wrote: > > > > Thanks for clarification about how restart_lsn is working. > > > > Digging slightly

Re: [HACKERS] Logical decoding restart problems

decoding output plugin, and current postgres master). -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical Replication WIP

--- 0/1530F30 | 7FFF/5E7F6A30 | 7FFF/5E7F6A30 | 7FFF/5E7F6A30 (1 row) -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical Replication WIP

lass: 6102 * Several time i’ve run in a situation where provider's postmaster ignores Ctrl-C until subscribed node is switched off. * Patch with small typos fixed attached. I’ll do more testing, just want to share what i have so far. typos.diff Description: Binary data -- Stas Kelvich Postg

Re: [HACKERS] Naming of new tsvector functions

That would be a good convention if we were able to easily rename old functions. But now that will just create another pattern on top of three existing (no prefix, ts_*, tsvector_*). Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-h

Re: [HACKERS] Naming of new tsvector functions

> On 04 May 2016, at 20:15, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Stas Kelvich <s.kelv...@postgrespro.ru> writes: >>> On 04 May 2016, at 16:58, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> The other ones are not so problematic because they do not conf

Re: [HACKERS] Naming of new tsvector functions

> On 04 May 2016, at 16:58, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Stas Kelvich <s.kelv...@postgrespro.ru> writes: >>> On 03 May 2016, at 00:59, David Fetter <da...@fetter.org> wrote: >>> I suspect that steering that ship would be a good idea startin

Re: [HACKERS] Naming of new tsvector functions

), numnode(), strip() Recent commit added setweight(), delete(), unnest(), tsvector_to_array(), array_to_tsvector(), filter(). Last bunch can be painlessly renamed, for example to ts_setweight, ts_delete, ts_unnest, ts_filter. The question is what to do with old ones? Leave them as is? Rename to ts_

[HACKERS] tsvector filter problem

Hi. As discovered by Oleg Bartunov, current filter() function for tsvector can crash backend. Bug was caused erroneous usage of char type in memmove argument. tsvector_bugfix_type.diff Description: Binary data -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian

Re: [HACKERS] Parser extensions (maybe for 10?)

ier to allow extensions to define custom parameters for WITH, than to extend parser. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://

Re: [HACKERS] Speedup twophase transactions

> On 13 Apr 2016, at 01:04, Michael Paquier <michael.paqu...@gmail.com> wrote: > > On Wed, Apr 13, 2016 at 1:53 AM, Stas Kelvich <s.kelv...@postgrespro.ru> > wrote: >>> On 12 Apr 2016, at 15:47, Michael Paquier <michael.paqu...@gmail.com> wrote: >>

Re: [HACKERS] Speedup twophase transactions

> On 12 Apr 2016, at 15:47, Michael Paquier <michael.paqu...@gmail.com> wrote: > > On Mon, Apr 11, 2016 at 7:16 PM, Stas Kelvich wrote: >> Michael, it looks like that you are the only one person who can reproduce >> that bug. I’ve tried on bunch of OS’s and di

Re: [HACKERS] 'Create table if not exists as' breaks SPI_execute

> On 11 Apr 2016, at 18:41, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: > > Hi. > > SPI_execute assumes that CreateTableAsStmt always have completionTag == > “completionTag”. > But it isn’t true in case of ‘IF NOT EXISTS’ present. > > > Sorry, I meant

[HACKERS] 'Create table if not exists as' breaks SPI_execute

Hi. SPI_execute assumes that CreateTableAsStmt always have completionTag == “completionTag”. But it isn’t true in case of ‘IF NOT EXISTS’ present. spi-cta.patch Description: Binary data -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent

Re: [HACKERS] Speedup twophase transactions

> On 08 Apr 2016, at 16:09, Stas Kelvich <s.kelv...@postgrespro.ru> wrote: > > Tried on linux and os x 10.11 and 10.4. > > Still can’t reproduce, but have played around with your backtrace. > > I see in xlodump on slave following sequence of records: > > rmgr:

Re: [HACKERS] closing CommitFest 2016-03, feature freeze now in effect

ghtful decision, taking into account that absence of that patch in release can cause problems with replication in some cases as it was warned by Jesper[1] and Andres[2]. [1] http://www.postgresql.org/message-id/5707a8cc.6080...@redhat.com [2] http://www.postgresql.org/message-id/80856693-5065-4392

Fwd: [HACKERS] Speedup twophase transactions

> On 08 Apr 2016, at 21:55, Jesper Pedersen <jesper.peder...@redhat.com> wrote: > > On 04/08/2016 02:42 PM, Robert Haas wrote: >> On Tue, Jan 26, 2016 at 7:43 AM, Stas Kelvich <s.kelv...@postgrespro.ru> >> wrote: >>> Hi, >>> >>>

Re: [HACKERS] Speedup twophase transactions

> On 08 Apr 2016, at 21:42, Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Jan 26, 2016 at 7:43 AM, Stas Kelvich <s.kelv...@postgrespro.ru> > wrote: >> Hi, >> >> Thanks for reviews and commit! > > I apologize for being clueless here, b

Re: [HACKERS] Speedup twophase transactions

s just quick script to reproduce bug, that Michael faced. If there will be deterministic way to reproduce that bug, i'll rework it and move to 00X_twophase.pl -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] Speedup twophase transactions

ideas on why that can be caused by changing procedures of PREPARE replay. Just to keep things sane, here is my current diff: twophase_replay.v4.patch Description: Binary data -- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company -- Sent via pgsql-hackers

Re: [HACKERS] Speedup twophase transactions

> On Apr 2, 2016, at 3:14 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > > On Fri, Apr 1, 2016 at 10:53 PM, Stas Kelvich <s.kelv...@postgrespro.ru> > wrote: >> I wrote: >>> While testing the patch, I found a bug in the recovery conflict

Re: [HACKERS] Speedup twophase transactions

rame #9: 0x000107e70f93 > postgres`LockAcquireExtended(locktag=0x7fff581f0238, lockmode=8, > sessionLock='\x01', dontWait='\0', reportMemoryError='\0') + 2819 at > lock.c:998 >frame #10: 0x000107e6a9a6 > postgres`StandbyAcquireAccessExclusiveLock(xid=

  1   2   >