[HACKERS] "could not found trigger %u"

nabled = enabled WHERE tgname = trigger_name; UPDATE pg_class SET reltriggers = 0 WHERE relname = table_name; UPDATE pg_class SET reltriggers = (SELECT count(*) FROM pg_trigger WHERE pg_class.oid = tgrelid) WHERE relname = table_name; SELECT oid INTO ret_val FROM

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 10 марта 2016 г., в 11:50, Simon Riggs написал(а): > > On 10 March 2016 at 06:27, Michael Paquier > wrote: > On Thu, Mar 10, 2016 at 1:29 AM, David Steele > wrote: > > On 1/8/16 9:34 AM, Alvaro Herrera wrote: > >> Simon Riggs wrot

Re: [HACKERS] Proposal: RETURNING primary_key()

t; is more like a "plug & pray" kind of API. ORMs should know the column names of the primary keys => ORMs should use "return specific column names" API, not just "return something generated". ​ Vladimir

Re: [HACKERS] Background Processes and reporting

> 11 марта 2016 г., в 22:16, Andres Freund написал(а): > > Hi, > > We now have "Provide much better wait information in pg_stat_activity" > and "Add a generic command progress reporting facility" making it easier > to provide insight into the system. > > > While working on the writeback contr

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 0:22, Andres Freund написал(а): > > On 2016-03-11 23:53:15 +0300, Vladimir Borodin wrote: >> It was many times stated in threads about waits monitoring [0, 1, 2] >> and supported by different people, but ultimately waits information >> wa

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 2:45, Andres Freund написал(а): > > On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: >> Idea of individual time measurement of every wait event met criticism >> because it might have high overhead [1]. > > Right. And that's actually one of the point which I meant wi

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 13:59, Amit Kapila написал(а): > > On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund > wrote: > > > > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > > background writer are in many cases processes that very often are > > >

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 10 марта 2016 г., в 14:38, Simon Riggs написал(а): > > On 10 March 2016 at 09:22, Michael Paquier <mailto:michael.paqu...@gmail.com>> wrote: > On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin <mailto:r...@simply.name>> wrote: > > Let’s do immediately

Re: [HACKERS] Background Processes and reporting

> 14 марта 2016 г., в 22:21, Robert Haas написал(а): > > On Sat, Mar 12, 2016 at 6:05 AM, Oleg Bartunov wrote: >>> So? >> >> So, Robert already has experience with the subject, probably, he has bad >> experience with edb implementation and he'd like to see something better in >> community ver

Re: [HACKERS] Background Processes and reporting

eters of wait events which requires some kind of > synchronization protocol. > 2) Recording time of wait events because time measurements might be expensive > on some platforms. > > Simultaneously there are machines and workloads where both of these features > doesn't produce

Re: [HACKERS] NOT EXIST for PREPARE

ent" you somehow mean JDBC (e.g. pgjdbc), then it does track which connections have which queries prepared. So the thing we/you need might be not backend support for "prepare if not exists", but some kind of bouncer vs jdbc integration, so jdbc knows which connection it is using at each point in time. Vladimir -- 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] NOT EXIST for PREPARE

d-backend protocol as all clients are supposed to handle ParameterStatus messages, etc. Vladimir -- 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] NOT EXIST for PREPARE

disabled -- that was fixed. What bothers me is current pgjdbc CI has exactly 0 pgbouncer tests. That means "BEGIN is fixed" can easily break and no one would notice that. It is tracked under https://github.com/pgjdbc/pgjdbc/issues/509, so if there's interest in pgbouncer vs pg

Re: [HACKERS] NOT EXIST for PREPARE

Merlin> All I'm saying is that the use of Merlin> server side prepared statements is extremely problematic in Merlin> conjunction with pgbouncer I've filed https://github.com/pgbouncer/pgbouncer/issues/126 to get pgbouncer improved in regard to prepared statements. Vladimir

Re: [HACKERS] NOT EXIST for PREPARE

ndeed be at the protocol level? What's wrong with say "select * from backend_capabilities" at the connection setup? Vladimir -- 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] NOT EXIST for PREPARE

f __ convention" does not require protocol version bump, while "adding new message" does require the bump. Just to be clear: I'm not fond of encoding the answer to the universe into statement name. However, I find that "name convention" a smart invention. Vladim

Re: [HACKERS] NOT EXIST for PREPARE

eds no cooperation from backend nor from app side in order to implement prepared statements properly. [1]: https://github.com/pgbouncer/pgbouncer/issues/126#issuecomment-200900171 Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 25 марта 2016 г., в 19:11, David Steele написал(а): > > Hi Vladimir, > > On 3/14/16 2:15 PM, Vladimir Borodin wrote: > >> JFYI, I’m preparing the stand to reproduce the initial problem and I >> hope to finish testing this week. > > Do you know when you&

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

= $2) Rows Removed by Filter: 90 Buffers: shared hit=18182 read=2735 Execution time: 355.901 ms Vladimir plan_flipper.sql Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mai

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

> I don't know if there is a good solution except disabling server prepared > statements. Why doesn't backend reuse already existing good plan? The plan does account for the skew. Can backend take selectivities from the original bind values? Vladimir -- Sent via pgsql-hack

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

bind values", so it would calculate proper selectivities for $1, $2. PS. It is not the first time the problem bites me, so I hand-crafted a testcase. Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postg

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

/utils/cache/plancache.c#L1151-L1152 Does that make sense? Vladimir -- 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] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

Please, read my suggestion again. TL;DR: I suggest to create "generic plan" with regard to current bind values. What's wrong with that approach? Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

h looks like this: >Now the plan gets invoked with $1 = 5. What exactly in your mind would >happen here? A sequential scan with $1=5 condition. What else could be there? Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscripti

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

ll return proper result for every possible bind value), yet refer to the values of 6th binds when estimating cardinalitites. Is it clear now? Vladimir -- 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] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

t be better using separate server-prepared statements (the one for "unique values", and another one for "non-unique"). Vladimir -- 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] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

>This completely screws over PL/PgSQL, among other things. Can you elaborate a bit? Vladimir -- 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] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

e to tune queries) to convince plpgsql to use different statement ids. Vladimir -- 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] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

es are nonunique and the rest is unique you'll get AF>*drastically* different plans, each performing badly for the other case; AF>with the unique cardinality plan being extremly bad. Can you elaborate a bit? I can hardly follow that. Vladimir -- 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] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

y this pattern. Well, why was it chosen over "UNNN"? In other words, a pattern like UNNN would "create a lot of others" as you say. NUNUNUNUNUN -- perfect optimizer would replan every time (or have two sets of plans, but let's leave that out) Neither my sugg

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

>A value of -1 could disable generic plans I do not like the idea. I've seen dramatic performance improvements from using cached plans. The numbers are like "20ms to plan vs 1ms to execute" for an often used OLTP query. Query text is involved (~5-10KiB). Vladimir -- Sent

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

pplications, but my message is that "one should *not* think that DB has artificial intelligence to properly identify a plan for each bind sets and cache plans at the same time". Vladimir -- 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] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

al can be good enough for 2/3 cases and it doesn't block any >other enhancing Albe's proposal effectively disables plan cache, thus it blocks enhancing. If a user goes "replan every time" route, there is no way you introduce plan caching there. [1]: https://en.wikipedia.org/w

[HACKERS] Insert values() per-statement overhead

t significant time is spent in standard_ExecutorStart: see [3] In fact, the time spent in standard_ExecutorStart even exceeds the time spent in standard_ExecutorRun. [1]: http://www.postgresql.org/message-id/55130dc8.2070...@redhat.com [2]: https://github.com/pgjdbc/pgjdbc/pull/491#issuecomment-171780054

Re: [HACKERS] Insert values() per-statement overhead

27;>,$3=<2>,$4=<3>,$5=<'s3'>,$6=<3>) 13:53:41.049 (1) FE=> Execute(portal=null,limit=1) 13:53:41.049 (1) FE=> Sync 13:53:41.049 (1) <=BE BindComplete [unnamed] 13:53:41.049 (1) <=BE CommandStatus(INSERT 0 2) 13:53:41.049 (1) <=BE BindComplete [unnamed] 13:53:41.049 (1) <=BE CommandStatus(INSERT 0 2) 13:53:41.049 (1) <=BE ReadyForQuery(I) Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

=0) FE=> Sync <=BE ParseComplete [null] <=BE BindComplete [unnamed] <=BE NoData <=BE CommandStatus(SET) <=BE ReadyForQuery(I) Am I missing something? [1]: http://www.postgresql.org/message-id/22921.1358876...@sss.pgh.pa.us [2]: https://github.com/pgjdbc/pgjdbc/issues/496 Vladimi

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

"cached plan must not change result type" error. Can one expect the issue to be fixed in subsequent 8.4, 8.5, ..., 9.5 versions? Vladimir -- 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] Set search_path + server-prepared statements = cached plan must not change result type

mer2,public; execute stmt; --ERROR: cached plan must not change result type --SQL state: 0A000 [1]: https://github.com/pgjdbc/pgjdbc/commit/8fcd07a24666de308419d54e49e2f65f40661e2a#diff-526a72847ed4c9f31f699515d06e508bR188 [2]: https://travis-ci.org/pgjdbc/pgjdbc/builds/103940843 Vladimi

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

I want to treat 'prepare' operation as an optimization step, so it is functionally equivalent to sending a query text. In other words, I would like backend to track search_path and other parameters if necessary transparently‎, creating (caching) different execution plans if different plans are

Re: [HACKERS] Implementing a new Scripting Language

u checked PL/Java? Vladimir -- 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] Implementing a new Scripting Language

a good way to go) 2) You implement Lucee parser/executor/compiler in C and use it as typical PostgreSQL extension Vladimir -- 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] Set search_path + server-prepared statements = cached plan must not change result type

ts of existing clients assume "prepare just works". If "prepare" command gets deprecated, why "parse" would be better? What would be the use of "prepare" if all the clients would have to use "parse" in order to be search_path-compatible? Vladimir -- 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] [WIP] ALTER ... OWNER TO ... CASCADE

> 15 февр. 2016 г., в 19:25, Tom Lane написал(а): > > Teodor Sigaev writes: >>> So basically, a generic CASCADE facility sounds like a lot of work to >>> produce something that would seldom be anything but a foot-gun. > >> DELETE FROM or TRUNCATE could be a foot-gun too, but it's not a reason

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

> 16 февр. 2016 г., в 18:20, Alvaro Herrera > написал(а): > > Vladimir Borodin wrote: > >>> Moreover, the use case you've sketched (ie, change ownership of all >>> objects inside a database) doesn't actually have anything to do with >>> fo

Re: [HACKERS] Slowness of extended protocol

postgresql.org/docs/9.5/static/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY doc>If successfully created, a named portal object lasts till the end of the current transaction, unless explicitly destroyed Vladimir

Re: [HACKERS] Index Onlys Scan for expressions

ter: 977 Buffers: shared hit=17 -> Index Only Scan using type_vc__vlsi on vlsi (cost=0.55..67.97 rows=971 width=36) (actual time=0.015..0.210 rows=1000 loops=1) Index Cond: (type = '42'::numeric) Heap Fetches: 0 Buffers: shared hit=17 Planning time: 0.086 ms Execution time: 0.503 ms Vladimir

Re: [HACKERS] Stopping logical replication protocol

logical replication. 2016-05-11 7:25 GMT+03:00 Craig Ringer : > On 11 May 2016 at 06:47, Vladimir Gordiychuk wrote: > >> Same thread, I just think these are two somewhat separate changes. One is >>> just in the walsender and allows return to command mode during waiting for >&

Re: [HACKERS] Index Onlys Scan for expressions

;. As shown in "query 2" vs "query 3", PostgreSQL cannot come up with such a plan on its own for some reason. This is not a theoretical issue, but it is something that I use a lot with Oracle DB (it just creates a good plan for "query 2"). Vladimir

Re: [HACKERS] Stopping logical replication protocol

There are no tests. I don't see any really simple way to test this, > though. > > I suggest that you apply these updated/split patches to a fresh copy > of master then see if you can update it based on this feedback. > Something like: > > git checkout master > git pull >

Re: [HACKERS] Index Onlys Scan for expressions

and assume that majority of the rows have length(vc)<128. Under that conditions, it would be nice to do index-only-scan and filter (like in my previous case), but detect "long" rows and do additional recheck for them. Vladimir

Re: [HACKERS] Stopping logical replication protocol

9-08 12:29 GMT+03:00 Craig Ringer : > On 7 September 2016 at 15:44, Vladimir Gordiychuk > wrote: > > > Fixed patch in attach. > > It'd helpful if you summarize the changes made when posting revisions. > > >> * There are no tests. I don't see any really simple way

Re: [HACKERS] Stopping logical replication protocol

>Have you had a chance to look at adding the tests we discussed? Not yet. I plane do it on this weekends 2016-09-16 4:37 GMT+03:00 Craig Ringer : > On 9 September 2016 at 12:03, Craig Ringer wrote: > > > Setting "waiting on author" in CF per discussion of the need for tests. > > Have you had a

Re: [HACKERS] Stopping logical replication protocol

immediately without wait CopyDone from server. 0004 patch contain regression tests on scenarios that fix 0001 and 0002 patches. 2016-09-16 10:11 GMT+03:00 Vladimir Gordiychuk : > >Have you had a chance to look at adding the tests we discussed? > > Not yet. I plane do it on this weekends

Re: [HACKERS] Stopping logical replication protocol

celTime) <= 3, # allow extra time for slow machines "pg_recvlogical exited promptly on sigint when idle" ); ``` Also I do not understand why we do $proc->pump while $proc->pumpable; after send signal to process, why we can not just wait stop replication slot? 2016-09-

Re: [HACKERS] Stopping logical replication protocol

, before this changes stopping logical replication gets N ms but after apply changes it gets NN ms where NN ms less than N ms. Is it available add this kind of benchmark to postgresql? I will be grateful for links. 2016-09-26 5:32 GMT+03:00 Craig Ringer : > On 26 Sep. 2016 02:16, "Vladimir Go

Re: [HACKERS] Statement-level rollback

de a way to do so. Adding protocol messages would blow pgbouncer, etc things, so it makes sense to refrain from new messages unless it is absolutely required. Vladimir

Re: [HACKERS] Statement-level rollback

bloat is not solved. That is what I mean. Vladimir

Re: [HACKERS] Stopping logical replication protocol

> Vladimir, can I have your opinion on the latest patch or if you want to make changes, an updated patch? I am satisfied with all our changes and I thinks it enough to complete this PR. 2016-10-03 6:51 GMT+03:00 Craig Ringer : > On 3 Oct. 2016 10:15, "Michael Paquier" wrote

Re: [HACKERS] Stopping logical replication protocol

> Vladimir? I'm running out of time to spend on this at least until the next CF. Think you can make these changes? Yes, I can. But I thinks It should be discuss first. > Terminating COPY BOTH with ERRCODE_QUERY_CANCELED seems fine. If it > was expecting the error the client c

[HACKERS] Query cancel seems to be broken in master since Oct 17

org/pgjdbc/pgjdbc/builds/168444341 Any hints what could be the issue? Was the breakage intentional? Vladimir

Re: [HACKERS] Query cancel seems to be broken in master since Oct 17

>What platform does the postgres server run on? Ubuntu OS name: "linux", version: "3.19.0-66-generic", arch: "amd64", family: "unix" 2016-10-18 11:05 GMT+03:00 Magnus Hagander : > > > On Tue, Oct 18, 2016 at 1:00 AM, Vladimir Sitnikov <

Re: [HACKERS] Stopping logical replication protocol

Craig, Andres what do you thinks about previous message? 2016-10-06 0:35 GMT+03:00 Vladimir Gordiychuk : > > Vladimir? I'm running out of time to spend on this at least until the next > CF. Think you can make these changes? > > Yes, I can. But I thinks It sho

Re: [HACKERS] Logical decoding and walsender timeouts

>>> When sending a big message, WalSndWriteData() notices that it's >>> approaching timeout and tries to send a keepalive request, but the >>> request just gets buffered behind the remaining output plugin data and >>> isn't seen by the client until the client has received the rest of the >>> pendin

[HACKERS] postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer

Hi, I have this question. Looked for a help on http://dba.stackexchange.com/ No success. Maybe you can answer?.. Thank you in advance "FOREIGN_TABLE" created with postgres_fdw. LOCAL_TABLE is just a local table... Symptoms: 1. I run in psql query SELECT * from FOREIGN_TABLE. No log generated

Re: [HACKERS] postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer

Hi, Sorry - tried to reproduce on other machine and gather all statements. And failed Installed 9.3 (which has those symptoms) and still can't reproduce. Must be platform specific, not version 2016-11-21 21:58 GMT+00:00 Kevin Grittner : > On Mon, Nov 21, 2016 at 8:32 AM, Vladimir Svedov

Re: [HACKERS] Statement-level rollback

legrand>when usingversion 42.0.0 with legrand> jdbc:postgresql://localhost:5432/postgres?autosave=always The pitfall there is the value should be written with upper case like autosave=ALWAYS. I've filed https://github.com/pgjdbc/pgjdbc/issues/769 to improve that at some point. Vladimir

Re: [HACKERS] Statement-level rollback

Please disregard my previous message. pgjdbc is already doing upcase conversion, so I would like to see a test case that reproduces the error. Alternatively, could you please capture and share TRACE log? ( https://jdbc.postgresql.org/documentation/head/logging.html#configuration ) Vladimir ср

[HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

input file: d3/2811.dat.gz: invalid distance too far back Attached small fix for this issue. You can view that patch online on our github: https://github.com/Infotecs/postgres/commit/1578f5011ad22d78ae059a4ef0924426fd6db762 -- Best regards, Vladimir Kunschikov Lead software developer I

Re: [HACKERS] SCRAM auth and Pgpool-II

> 14 июля 2017 г., в 1:33, Stephen Frost написал(а): > > What would be really nice for such cases is support for Kerberos and > delegated Kerberos credentials. Having pgpool support that would remove > the need to deal with passwords at all. Since nearly all systems with some kind of load nowa

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

Hello Alvaro, thanks for the feedback, fixed all of your points. Attached new version of patch. -- Best regards, Vladimir Kunschikov Lead software developer IDS project InfoTeCS JSC From: Alvaro Herrera Sent: Wednesday, July 26, 2017 1:02 AM To

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

s.int/company/structure/Pages/detailsDepartment.aspx?idDepartment=235&idCompany=17> From: Alvaro Herrera Sent: Wednesday, July 26, 2017 7:40:20 PM To: Kunshchikov Vladimir Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [patch] pg_dump/pg_restore zerror() a

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

Hello Alvaro, here goes v4 version: removed unused header. Compilation of this code snippet with -Wall -Wexter -std=c89 doesn't produce any warnings. -- Best regards, Vladimir Kunschikov Lead software developer IDS project InfoTeCS JSC From: Kunshc

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

6df51cf17c0b0a4f201ee0f93cf258de9#diff-98e3f8ce5d6e87950dd66e4c8bdedb21R713 It was rewritten for the sake of somewhat exaggerated security. Version #5 in attachment. -- Regards, Vladimir Kunschikov diff --git a/src/bin/pg_dump/compress_io.c b/src/bin/pg_dump/compress_io.c index 991fe11..b8af1bc 100644 --- a/src/b

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

I haven't seen that but can't guarantee that such case does not exist 28 июля 2017 г. 9:19 PM пользователь "Alvaro Herrera" < alvhe...@2ndquadrant.com> написал: > Vladimir Kunschikov wrote: > > >This "maxlen" business and the fallback error messa

Re: [HACKERS] Funny WAL corruption issue

Hi, Chris. > 10 авг. 2017 г., в 15:09, Chris Travers написал(а): > > Hi; > > I ran into a funny situation today regarding PostgreSQL replication and wal > corruption and wanted to go over what I think happened and what I wonder > about as a possible solution. > > Basic information is custom-

Re: [HACKERS] Funny WAL corruption issue

is caught by checksums. I am not familiar with WAL protocol - do we have enough checksums when writing it out and on the wire? I suspect there are much more things PostgreSQL can do to be more resilient, and at least detect corruptions earlier. -- Vladimir Rusinov PostgreSQL SRE, Google Ireland Goog

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

> 29 апр. 2017 г., в 17:34, Tom Lane написал(а): > > Dmitriy Sarafannikov writes: >>> Maybe we need another type of snapshot that would accept any >>> non-vacuumable tuple. I really don't want SnapshotAny semantics here, > >> If I understood correctly, this new type of snapshot would help if

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

Hi. > 25 апр. 2017 г., в 18:13, Dmitriy Sarafannikov > написал(а): > > I'd like to propose to search min and max value in index with SnapshotAny in > get_actual_variable_range function. > Current implementation scans index with SnapshotDirty which accepts > uncommitted rows and rejects dead r

Re: [HACKERS] Broken hint bits (freeze)

> 24 мая 2017 г., в 15:44, Robert Haas написал(а): > > On Wed, May 24, 2017 at 7:27 AM, Dmitriy Sarafannikov > wrote: >> It seems like replica did not replayed corresponding WAL records. >> Any thoughts? > > heap_xlog_freeze_page() is a pretty simple function. It's not > impossible that it co

Re: [HACKERS] Broken hint bits (freeze)

> 26 мая 2017 г., в 23:04, Michael Paquier > написал(а): > > On Fri, May 26, 2017 at 2:39 PM, Amit Kapila wrote: >> Yeah, I think this is quite suspicious. This seems to indicate that >> not all WAL records are replicated before the switchover. What is the >> value of "synchronous_commit" yo

Re: [HACKERS] Broken hint bits (freeze)

> 26 мая 2017 г., в 21:39, Amit Kapila написал(а): > >> And LSN on replica is greater that LSN on master (838D/C4A0D280 > >> 8092/6A26DD08) >> How can this be possible? >> > > Yeah, I think this is quite suspicious. This seems to indicate that > not all WAL records are replicated before the

Re: [HACKERS] Broken hint bits (freeze)

> 27 мая 2017 г., в 19:56, Andres Freund написал(а): > > On 2017-05-27 19:48:24 +0300, Vladimir Borodin wrote: >> Well, actually clean shutdown of master with exit code 0 from `pg_ctl >> stop -m fast` guarantees that all WAL has been replicated to standby. > > It do

Re: [HACKERS] Broken hint bits (freeze)

> 6 июня 2017 г., в 23:30, Sergey Burladyan написал(а): > > Dmitriy Sarafannikov writes: > >> Starting and stopping master after running pg_upgrade but before rsync to >> collect statistics >> was a bad idea. > > But, starting and stopping master after running pg_upgrade is *required* > by d

Re: [HACKERS] Broken hint bits (freeze)

> 8 июня 2017 г., в 17:03, Amit Kapila написал(а): > > On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sarafannikov > wrote: >> >>> Why didn't rsync made the copies on master and replica same? >> >> Because rsync was running with —size-only flag. >> > > IIUC the situation, the new WAL and updated p

Re: [HACKERS] Broken hint bits (freeze)

> 12 июня 2017 г., в 13:19, Amit Kapila написал(а): > > On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin <mailto:r...@simply.name>> wrote: >> >> 8 июня 2017 г., в 17:03, Amit Kapila написал(а): >> >> On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sar

[HACKERS] Приглашение: Re: [HACKERS] intermittent failures in Cygwin from select... - пт, 16 июнь 2017 09:00 - 10:00 (MSK) (pgsql-hackers@postgresql.org)

BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20170616T06Z DTEND:20170616T07Z DTSTAMP:20170615T193848Z ORGANIZER;CN=Vladimir Sitnikov:mailto:sitnikov.vladi...@gmail.com UID:2a6cc082-5202-11e7-978f

Re: [HACKERS] Proposal: pg_rewind to skip config files

> 5 сент. 2017 г., в 12:31, Chris Travers написал(а): > > I think the simplest solution for now is to skip any files ending in .conf, > .log, and serverlog. Why don’t you want to solve the problem once? It is a bit harder to get consensus on a way how to do it, but it seems that there are no

Re: [HACKERS] Proposal: pg_rewind to skip config files

> 5 сент. 2017 г., в 14:04, Michael Paquier > написал(а): > >> For example, in archive_command we put WALs for archiving from >> pg_xlog/pg_wal into another directory inside PGDATA and than another cron >> task makes real archiving. This directory ideally should be skipped by >> pg_rewind, but

Re: [HACKERS] Proposal: pg_rewind to skip config files

> 5 сент. 2017 г., в 15:42, Chris Travers написал(а): > > On Tue, Sep 5, 2017 at 2:40 PM, Vladimir Borodin <mailto:r...@simply.name>> wrote: > >> 5 сент. 2017 г., в 14:04, Michael Paquier > <mailto:michael.paqu...@gmail.com>> написал(а): >> >&g

Re: [HACKERS] Proposal: pg_rewind to skip config files

> 5 сент. 2017 г., в 15:48, Michael Paquier > написал(а): > > On Tue, Sep 5, 2017 at 9:40 PM, Vladimir Borodin wrote: >> We do compress WALs and send them over network. Doing it via archive_command >> in single thread is sometimes slower than new WALs are written unde

Re: [HACKERS] pgjdbc logical replication client throwing exception

ons, so it would be easier to reson about Have you tried "withStatusInterval(20, TimeUnit.SECONDS)" instead of 20 millis? I don't think it matter much, however 20ms seems to be an overkill. Vladimir пт, 15 сент. 2017 г. в 19:57, Dipesh Dangol : > hi, > > I am trying to im

Re: [HACKERS] 64-bit queryId?

>OK, so here's a patch. Review appreciated. Please correct typo "Write an unsigned integer field (anythign written with UINT64_FORMAT)". anythign -> anything. Vladimir

[HACKERS] make check-world problem

'--with-tcl' '--with-openssl' \ '--enable-thread-safety' '--with-ldap' '--with-gssapi' '--with-pam' '--with-libxml' '--with-libxslt' \ "--prefix=$POSTGRESQL/dev-install" > configure-out-de

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

25 авг. 2015 г., в 16:03, Michael Paquier написал(а):On Sun, Jul 26, 2015 at 9:46 PM, Andres Freund wrote:On 2015-07-24 09:53:49 +0300, Heikki Linnakangas wrote:To me it sounds like this shouldn't go through the full ReadBuffer()rigamarole. That code is already complex e

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

tion (does it?), however that is a different discussion. Regards, Vladimir Sitnikov

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 12 сент. 2015 г., в 14:05, Amit Kapila написал(а): > > On Thu, Aug 6, 2015 at 3:31 PM, Ildus Kurbangaliev > mailto:i.kurbangal...@postgrespro.ru>> wrote: > > > > On 08/05/2015 09:33 PM, Robert Haas wrote: > >> > >> > >> You're missing the point. Those multi-byte fields have additional > >> s

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 16 сент. 2015 г., в 20:52, Robert Haas написал(а): > > On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov > wrote: >> Yes, the major question is cost. But I think we should validate our thoughts >> by experiments assuming there are more possible synchronization protocols. >> Ildus posted im

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 18 сент. 2015 г., в 20:16, Robert Haas написал(а): > > On Fri, Sep 18, 2015 at 4:08 AM, Vladimir Borodin wrote: >> For both scenarios on linux we got approximately the same results - version >> with timings was faster then version with sampling (sampling was done eve

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 27 окт. 2015 г., в 19:45, Vladimir Borodin написал(а): > > Hi all. > > I’m wondering why do I get conflicts with recovery on hot standby using > replication slots and read commited isolation level? And if I start > repeatable read transaction I don’t get any

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 29 окт. 2015 г., в 13:12, Michael Paquier > написал(а): > > On Thu, Oct 29, 2015 at 9:42 AM, Vladimir Borodin wrote: >> I’m wondering why do I get conflicts with recovery on hot standby using >> replication slots and read commited isolation level? And if I

  1   2   3   >