Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed Applied this patch, it works well, make what it expected

Re: [HACKERS] Sanity checking for ./configure options?

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed Tested, I think it`s rather important to make cleanup work

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

> Why does it say "tested, failed" for all points above there? ;-) Hi, I just used Web reviewer form on https://commitfest.postgresql.org to make review on patch, but form doesn't work properly unlike the patch.))

Re: [HACKERS] make async slave to wait for lsn to be replayed

'0/693FF800'; Notice: WAITLSN will release on PostmasterDeath or Interruption events if they come earlier then target LSN or timeout. Thank you for reading, will be glad to get your feedback. -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/do

Re: [HACKERS] less expensive pg_buffercache on big shmem

partitions of shared memory in a different way than in consistent or nonconsistent methods. The semi-consistent strategy implies that only one buffer is locked at a time. Therefor has no significant effect on the system, but it takes more time. --- Ivan Kartyshov Postgres Professional: http://www

Re: [HACKERS] make async slave to wait for lsn to be replayed

hing else? Yes you are right, I want to ensure data consistency on downstream before running queries on it. Our clients would use it as a part of background worker and maybe directly in apps too. --- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Compa

Re: [HACKERS] less expensive pg_buffercache on big shmem

gan wrote: > I would like to be able to run pg_buffercache in production from time > to time. Yes, in our experience the usage of fully consistent pg_buffercache in production is quite a courageous decision. --- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russia

[HACKERS] make async slave to wait for lsn to be replayed

with success (without NOTICE message) The WAITLSN as expected wait LSN, and interrupts on PostmasterDeath, interrupts or timeout. Your feedback is welcome! --- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/ref/allfiles.sgml b

[HACKERS] less expensive pg_buffercache on big shmem

our feedback! --- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/contrib/pg_buffercache/Makefile b/contrib/pg_buffercache/Makefile index 065d3d6..8813c50 100644 --- a/contrib/pg_buffercache/Makefile +++ b/contrib/pg_buffercache/Makef

Re: [HACKERS] less expensive pg_buffercache on big shmem

's any point in taking the lock on the buffer mapping partition; I'm thinking that doesn't really do anything unless we lock them all, and we all seem to agree that's going too far. Replace consistent method with semiconsistent (that lock buffer headers without partition lock). Made some add

Re: [HACKERS] make async slave to wait for lsn to be replayed

ure) I will leave the choice of implementation (core/contrib) to the discretion of the community. Will be glad to hear your suggestion about syntax, code and patch. -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sg

Re: [HACKERS] make async slave to wait for lsn to be replayed

terruption events if they come earlier then target LSN or timeout. -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/contrib/pg_waitlsn/Makefile b/contrib/pg_waitlsn/Makefile new file mode 100644 index 000..49a326c --- /dev/null +++

Re: [HACKERS] make async slave to wait for lsn to be replayed

to be a LSN would still allow for progress in transaction management. For example, making PostgreSQL distributed will likely want timestamp and/or vector clock based visibility rules. I'm sorry I did not understand exactly what you meant. Please explain this in more detail. -- Ivan Kartyshov

Re: [HACKERS] make async slave to wait for lsn to be replayed

New little cleanup code changes -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Companycommit 217f842726531edb1b0056a5c5727ab01bab7f9b Author: i.kartyshov <i.kartys...@postgrespro.com> Date: Mon Oct 23 12:08:59 2017 +0300 Cherry picked and

Re: [HACKERS] make async slave to wait for lsn to be replayed

Alexander Korotkov писал 2017-10-23 13:19: Despite code cleanup, you still have some random empty lines removals in your patch. I reconfigured my IDE to avoid this in the future. -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff --git a/doc

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

) -- Ivan Kartyshov Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff --git a/src/backend/catalog/storage.c b/src/backend/catalog/storage.c index 9a5fde0..68decab 100644 --- a/src/backend/catalog/storage.c +++ b/src/backend/catalog/storage.c @@ -31,6 +31,9

Re: [HACKERS] make async slave to wait for lsn to be replayed

Ants Aasma писал 2017-10-26 17:29: On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov <i.kartys...@postgrespro.ru> wrote: Ants Aasma писал 2017-09-26 13:00: Exposing this interface as WAITLSN will encode that visibility order matches LSN order. This removes any chance of fixing for e