Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

essExclusive reached standby and max_standby_streaming_delay > -1 you definitely sooner or later get this Fatal on recovery . With this patch we try to get rid of AccessEclusiveLock applied on standby while we have active statement on it. -- Alex Ignatov Postgres Professional: http://

Re: [HACKERS] Parallel sec scan in plpgsql

On 18.09.2016 06:54, Amit Kapila wrote: On Fri, Sep 16, 2016 at 8:48 PM, Alex Ignatov <a.igna...@postgrespro.ru> wrote: On 16.09.2016 16:50, Amit Kapila wrote: Can you try by setting force_parallel_mode = off;? I think it is sending the whole function execution to work

Re: [HACKERS] Parallel sec scan in plpgsql

On 16.09.2016 16:50, Amit Kapila wrote: On Fri, Sep 16, 2016 at 6:57 PM, Alex Ignatov <a.igna...@postgrespro.ru> wrote: No it doesn't. Paralleling neither sql function nor plpgsql: Here is example : ipdr=> show max_worker_processes ; max_worker_processes -- 1

Re: [HACKERS] Parallel sec scan in plpgsql

te (cost=288697.59..288847.74 rows=15015 width=28) Group Key: test.a, test.b, test.c, test.d, test.e -> Seq Scan on test (cost=0.00..163696.15 rows=1115 width=20) So as we can see parallel secscan doesn't works in plpgsql and sql functions. Can somebody explains me where I

[HACKERS] Parallel sec scan in plpgsql

Hello! Does parallel secscan works in plpgsql? -- Alex Ignatov 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

Re: [HACKERS] Block level parallel vacuum WIP

ential scan that this would suck performance out particularly for rotating disks. Rotating disks is not a problem - you can always raid them and etc. 8k allocation per relation once per half an hour that is the problem. Seq scan is this way = random scan... Alex Ignatov Postgres Professional

Re: [HACKERS] Why we lost Uber as a user

s will need be updated). Of course it will make index scan a bit worse, however it looks like at least Uber is fine with that extra cost of index scan. Does it make sense to implement that kind of index as an access method? Vladimir You mean IOT like Oracle have? Alex Ignatov Postgres Profes

Re: [HACKERS] Strange behavior of some volatile function like random(), nextval()

On 29.06.2016 15:30, David G. Johnston wrote: More specifically... On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier <michael.paqu...@gmail.com <mailto:michael.paqu...@gmail.com>>wrote: On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov <a.igna...@postgrespro.ru

[HACKERS] Strange behavior of some volatile function like random(), nextval()

e its value is needed." Something wrong with executor? Is it bug or executor feature related with subquery? -- Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Bug in to_timestamp().

Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company On 20.06.2016 17:09, Albe Laurenz wrote: Tom Lane wrote: I don't necessarily have an opinion yet. I would like to see more than just an unsupported assertion about what Oracle's behavior is. Also

Re: [HACKERS] Bug in to_timestamp().

12 (1 row) On the our side we have some discussions about to write a patch that will change this incorrect behavior. So stay tuned. -- Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 19:37, David G. Johnston wrote: On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov <a.igna...@postgrespro.ru <mailto:a.igna...@postgrespro.ru>>wrote: On 23.06.2016 16:30, Bruce Momjian wrote: On Thu, Jun 23, 2016 at 07:41:26AM +, am

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 16:30, Bruce Momjian wrote: On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: On Monday, 20 June 2016 8:53 PM, Alex Ignatov <a.igna...@postgrespro.ru> wrote: On 13.06.2016 18:52, amul sul wrote: And it wont stop on some simple whitespace. By using to_timestamp y

Re: [HACKERS] Bug in to_timestamp().

99', 'MMDD HH24:MI:SS'); to_timestamp 2016-01-06 14:40:39+03 (1 row) Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] Bug in to_timestamp().

rameters we have no any exceptions or errors about that. I think that to_timestamp() need to has more format checking than it has now. Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

[HACKERS] Why we don't have checksums on clog files

violation. Can anybody explain this situation with clogs? -- Alex Ignatov 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

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

. Regards, Hi! Do we have any confidence that data file is not being corrupted? I.e contains some corrupted page? Can pg_basebackup check page checksum (db init with initdb -k) while backing up files? Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Is pg_control file crashsafe?

On 05.05.2016 7:16, Amit Kapila wrote: On Wed, May 4, 2016 at 8:03 PM, Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>> wrote: > > Amit Kapila <amit.kapil...@gmail.com <mailto:amit.kapil...@gmail.com>> writes: > > On Wed, May 4, 2

Re: [HACKERS] Is pg_control file crashsafe?

On 06.05.2016 0:42, Greg Stark wrote: On 5 May 2016 12:32 am, "Tom Lane" > wrote: > > To repeat, I'm pretty hesitant to change this logic. While this is not > the first report we've ever heard of loss of pg_control, I believe I could > count

Re: [HACKERS] Is pg_control file crashsafe?

On 03.05.2016 2:17, Tom Lane wrote: Alex Ignatov <a.igna...@postgrespro.ru> writes: I think that rename can help a little bit. At least on some FS it is atomic operation. Writing a single sector ought to be atomic too. I'm very skeptical that it'll be an improvement to just move th

Re: [HACKERS] Is pg_control file crashsafe?

Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company On 03.05.2016 2:21, Andres Freund wrote: Hi, On 2016-04-28 21:58:00 +, Alex Ignatov wrote: We have some issue with truncated pg_control file on Windows after power failure.My questions is : 1

Re: [HACKERS] Is pg_control file crashsafe?

On 01.05.2016 0:55, Bruce Momjian wrote: On Thu, Apr 28, 2016 at 09:58:00PM +, Alex Ignatov wrote: Hello everyone! We have some issue with truncated pg_control file on Windows after power failure. My questions is : 1) Is pg_control protected from say , power crash or partial write? 2) How

[HACKERS] Is pg_control file crashsafe?

Hello everyone! We have some issue with truncated pg_control file on Windows after power failure.My questions is : 1) Is pg_control protected from say , power crash or partial write? 2) How PG update pg_control? By writing in it or writing in some temp file and after that rename it to

Re: [HACKERS] Remove Windows crash dump support?

i right? May be we need to add this functionality instead of drop support of it entirely? -- Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company