pgsql: Remove temporary WAL and history files at the end of archive rec
Remove temporary WAL and history files at the end of archive recovery cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cw4hsqj+u_r26...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7ca35472cbf36bb822fe56b40cd5af1031e5081a Modified Files -- src/backend/access/transam/xlog.c| 24 src/test/recovery/t/002_archiving.pl | 25 - 2 files changed, 36 insertions(+), 13 deletions(-)
pgsql: Remove temporary WAL and history files at the end of archive rec
Remove temporary WAL and history files at the end of archive recovery cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cw4hsqj+u_r26...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2a724cdbff0bef4b962255c1e322b4deb74c309e Modified Files -- src/backend/access/transam/xlog.c| 24 src/test/recovery/t/002_archiving.pl | 25 - 2 files changed, 36 insertions(+), 13 deletions(-)
pgsql: Remove temporary WAL and history files at the end of archive rec
Remove temporary WAL and history files at the end of archive recovery cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cw4hsqj+u_r26...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ac1efdd080b2a26bf4f072cbd01155ba623ec401 Modified Files -- src/backend/access/transam/xlog.c| 24 src/test/recovery/t/002_archiving.pl | 25 - 2 files changed, 36 insertions(+), 13 deletions(-)
pgsql: Remove temporary WAL and history files at the end of archive rec
Remove temporary WAL and history files at the end of archive recovery cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cw4hsqj+u_r26...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ae205dfe6ced5305777919fc47371a452dfa803f Modified Files -- src/backend/access/transam/xlog.c | 24 1 file changed, 12 insertions(+), 12 deletions(-)
pgsql: Remove temporary WAL and history files at the end of archive rec
Remove temporary WAL and history files at the end of archive recovery cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cw4hsqj+u_r26...@mail.gmail.com Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/df86e52cace2c4134db51de6665682fb985f3195 Modified Files -- src/backend/access/transam/xlog.c| 24 src/test/recovery/t/002_archiving.pl | 25 - 2 files changed, 36 insertions(+), 13 deletions(-)
pgsql: Remove temporary WAL and history files at the end of archive rec
Remove temporary WAL and history files at the end of archive recovery cbc55da has reworked the order of some actions at the end of archive recovery. Unfortunately this overlooked the fact that the startup process needs to remove RECOVERYXLOG (for temporary WAL segment newly recovered from archives) and RECOVERYHISTORY (for temporary history file) at this step, leaving the files around even after recovery ended. Backpatch to 9.5, like the previous commit. Author: Sawada Masahiko Reviewed-by: Fujii Masao, Michael Paquier Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cw4hsqj+u_r26...@mail.gmail.com Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b978de0eba8582f4a9cde123ca09bc776bde8c83 Modified Files -- src/backend/access/transam/xlog.c| 24 src/test/recovery/t/002_archiving.pl | 25 - 2 files changed, 36 insertions(+), 13 deletions(-)
Re: pgsql: Make crash recovery ignore recovery target settings.
Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Sep 30, 2019 at 7:28 AM David Steele wrote: > > I'm surprised that we would consider going to GA with an issue like this > > outstanding. > > Yeah, this is a *bad* problem. I have to agree with this and I'm also pretty disappointed that we seem to be 'damn the torpedos, full steam ahead' with these issues. I don't like the idea of a delay either but ... Thanks, Stephen signature.asc Description: PGP signature
Re: pgsql: Add hooks for session start and session end, take two
On Wed, Oct 02, 2019 at 01:27:50PM +0900, Fujii Masao wrote: > If only session end hook is problematic, you will commit session start > hook again? Sure, it would be possible to cut the apple in half here. Now my understanding was that both hooks were a set. What do people think? Note that to make the stuff complete it is still required to pass down --create-user to REGRESS_OPTS of the test module's Makefile to avoid regression test failures with Windows machines because of unmatching HBA entries. -- Michael signature.asc Description: PGP signature
Re: pgsql: Add hooks for session start and session end, take two
On Wed, Oct 2, 2019 at 9:26 AM Michael Paquier wrote: > > On Tue, Oct 01, 2019 at 05:02:28PM -0700, Andres Freund wrote: > > The reason for that is simply that at that point llvmjit.c's own > > shutdown hook has already shutdown parts of the JIT subsystem (which > > needs to flush profiling information to disk, for profiling to be > > useful). > > Hmm. I missed the actual point. The current location for the session > end hook has been chosen because we are sure that any transaction has > been aborted properly, and we'd still be limited with a hook in > proc_exit_prepare() because of that same argument. I am just going to > revert the patch. If only session end hook is problematic, you will commit session start hook again? Regards, -- Fujii Masao
pgsql: Revert hooks for session start and end, take two
Revert hooks for session start and end, take two The location of the session end hook has been chosen so as it is possible to allow modules to do their own transactions, however any trying to any any subsystem which went through before_shmem_exit() would cause issues, limiting the pluggability of the hook. Per discussion with Tom Lane and Andres Freund. Discussion: https://postgr.es/m/18722.1569906...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9555cc8d2b02c4191d67ba39f589b39b01735518 Modified Files -- src/backend/tcop/postgres.c| 6 - src/backend/utils/init/postinit.c | 6 - src/include/tcop/tcopprot.h| 7 - src/test/modules/Makefile | 1 - src/test/modules/test_session_hooks/.gitignore | 4 - src/test/modules/test_session_hooks/Makefile | 23 --- src/test/modules/test_session_hooks/README | 11 -- .../expected/test_session_hooks.out| 37 - .../modules/test_session_hooks/session_hooks.conf | 2 - .../test_session_hooks/sql/test_session_hooks.sql | 19 --- .../test_session_hooks/test_session_hooks.c| 155 - 11 files changed, 271 deletions(-)
Re: pgsql: Add hooks for session start and session end, take two
On Tue, Oct 01, 2019 at 05:02:28PM -0700, Andres Freund wrote: > The reason for that is simply that at that point llvmjit.c's own > shutdown hook has already shutdown parts of the JIT subsystem (which > needs to flush profiling information to disk, for profiling to be > useful). Hmm. I missed the actual point. The current location for the session end hook has been chosen because we are sure that any transaction has been aborted properly, and we'd still be limited with a hook in proc_exit_prepare() because of that same argument. I am just going to revert the patch. -- Michael signature.asc Description: PGP signature
Re: pgsql: Add hooks for session start and session end, take two
Hi,
On 2019-10-01 14:25:43 +0900, Michael Paquier wrote:
> On Tue, Oct 01, 2019 at 01:10:36AM -0400, Tom Lane wrote:
> > The idea that you can launch a query after proc_exit has started is
> > complete insanity. I hope this is just a poorly-thought-out test
> > case, and not something that's inherent to this module. If there
> > are not reasonable use-cases that don't need that, we should just
> > revert the feature altogether, because it's nothing but a large
> > caliber foot-gun.
>
> That was originally just part of the original test to prove the point
> of the session end hook where people wanted to be able to log some
> activity once the session is done with.
How's that countering Tom's concern? To me it seems pretty broken to
run the session hook from within ShutdownPostgres(). What if that hook
starts another transaction, for example? Or uses any of the other
subsystems that might already have shut down at this point?
The way this is implemented right now this cannot touch *any* subsystem
that uses before_shmem_exit hooks, because they've all already been
shutdown by the time ShutdownPostgres() is called.
Case in point, this fails reliably for me if I force every query to be
JIT compiled:
PGOPTIONS='-cjit_above_cost=0' make check -C
src/test/modules/test_session_hooks/
#0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:67
#1 0x7f3e772a156c in __gthread_mutex_lock (__mutex=0x0) at
/usr/include/x86_64-linux-gnu/c++/8/bits/gthr-default.h:748
#2 __gthread_recursive_mutex_lock (__mutex=0x0) at
/usr/include/x86_64-linux-gnu/c++/8/bits/gthr-default.h:810
#3 std::recursive_mutex::lock (this=0x0) at /usr/include/c++/8/mutex:107
#4 std::lock_guard::lock_guard (__m=..., this=) at /usr/include/c++/8/bits/std_mutex.h:162
#5
llvm::orc::ExecutionSession::runSessionLocked(llvm::orc::ExecutionSession::allocateVModule()::{lambda()#1}&&)
(F=..., this=0x0) at
/home/andres/src/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Core.h:786
#6 llvm::orc::ExecutionSession::allocateVModule (this=0x0) at
/home/andres/src/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Core.h:808
#7
llvm::OrcCBindingsStack::addIRModule > (
this=this@entry=0x0, Layer=..., M=std::unique_ptr =
{...}, MemMgr=std::unique_ptr = {...},
ExternalResolver=ExternalResolver@entry=0x7f3e78223bd0
, ExternalResolverCtx=0x0)
at
/home/andres/src/llvm-project/llvm/lib/ExecutionEngine/Orc/OrcCBindingsStack.h:304
#8 0x7f3e772a1935 in llvm::OrcCBindingsStack::addIRModuleEager
(ExternalResolverCtx=0x0, ExternalResolver=0x7f3e78223bd0
, M=...,
this=0x0) at /usr/include/c++/8/bits/move.h:74
#9 LLVMOrcAddEagerlyCompiledIR (JITStack=0x0,
RetHandle=RetHandle@entry=0x7fff33127f78, Mod=0x1460fb0,
SymbolResolver=SymbolResolver@entry=0x7f3e78223bd0 ,
SymbolResolverCtx=SymbolResolverCtx@entry=0x0)
at
/home/andres/src/llvm-project/llvm/lib/ExecutionEngine/Orc/OrcCBindings.cpp:77
#10 0x7f3e78222d84 in llvm_compile_module (context=0x13aaea8) at
/home/andres/src/postgresql/src/backend/jit/llvm/llvmjit.c:553
#11 llvm_get_function (context=0x13aaea8, funcname=0x14a2370 "evalexpr_1_0") at
/home/andres/src/postgresql/src/backend/jit/llvm/llvmjit.c:262
#12 0x7f3e7822be2e in ExecRunCompiledExpr (state=0x14a1d98,
econtext=0x14a19c0, isNull=0x0)
at /home/andres/src/postgresql/src/backend/jit/llvm/llvmjit_expr.c:2434
#13 0x006b2529 in ExecEvalExprNoReturn (econtext=0x14a19c0,
state=0x14a1d98) at
/home/andres/src/postgresql/src/include/executor/executor.h:356
#14 ExecEvalExprNoReturnSwitchContext (econtext=0x14a19c0, state=0x14a1d98) at
/home/andres/src/postgresql/src/include/executor/executor.h:356
#15 ExecProject (projInfo=0x14a1d90) at
/home/andres/src/postgresql/src/include/executor/executor.h:388
#16 ExecResult (pstate=) at
/home/andres/src/postgresql/src/backend/executor/nodeResult.c:136
#17 0x006afe04 in ExecProcNode (node=0x14a18b0) at
/home/andres/src/postgresql/src/include/executor/executor.h:240
#18 ExecModifyTable (pstate=0x14a1638) at
/home/andres/src/postgresql/src/backend/executor/nodeModifyTable.c:2072
#19 0x00687eec in ExecProcNode (node=0x14a1638) at
/home/andres/src/postgresql/src/include/executor/executor.h:240
#20 ExecutePlan (execute_once=, dest=0xb1a9e0 ,
direction=, numberTuples=0, sendTuples=,
operation=CMD_INSERT, use_parallel_mode=,
planstate=0x14a1638, estate=0x14a12c8)
at /home/andres/src/postgresql/src/backend/executor/execMain.c:1646
#21 standard_ExecutorRun (queryDesc=0x1432db0, direction=,
count=0, execute_once=)
at /home/andres/src/postgresql/src/backend/executor/execMain.c:364
#22 0x006bfe2e in _SPI_pquery (tcount=0, fire_triggers=true,
queryDesc=) at
/home/andres/src/postgresql/src/backend/executor/spi.c:2521
#23 _SPI_execute_plan (plan=, paramLI=,
snapshot=, crosscheck_snapshot=,
read_only=, fire_triggers=, tcount=) at /home/andres/src/postgresql/src/backend/executor/spi.c:2297
#24 0x00
Re: pgsql: Add hooks for session start and session end, take two
On Tue, Oct 01, 2019 at 03:24:21PM -0400, Andrew Dunstan wrote: > I'll fix up the logging. Meanwhile, the log is showing: > > \c :prevdb regress_sess_hook_usr1 > \connect: FATAL: SSPI authentication failed for user > "regress_sess_hook_usr1" > > That's not surprising given the hba and ident file contents. Thanks for the details of the logs! That makes sense, and we actually do not have other modules with NO_INSTALLCHECK which use \c to reconnect in a test. The attached patch should be able to fix the issue. Could you confirm? -- Michael diff --git a/src/test/modules/test_session_hooks/Makefile b/src/test/modules/test_session_hooks/Makefile index e8ba6990f6..f6ecf76ce5 100644 --- a/src/test/modules/test_session_hooks/Makefile +++ b/src/test/modules/test_session_hooks/Makefile @@ -5,7 +5,7 @@ OBJS = test_session_hooks.o $(WIN32RES) PGFILEDESC = "test_session_hooks - tests for start and end session hooks" REGRESS = test_session_hooks -REGRESS_OPTS = --temp-config=$(top_srcdir)/src/test/modules/test_session_hooks/session_hooks.conf +REGRESS_OPTS = --create-role=regress_sess_hook_usr1,regress_sess_hook_usr2 --temp-config=$(top_srcdir)/src/test/modules/test_session_hooks/session_hooks.conf # Disabled because these tests require extra configuration with # "shared_preload_libraries=test_session_hooks", which typical # installcheck users do not have (e.g. buildfarm clients). diff --git a/src/test/modules/test_session_hooks/expected/test_session_hooks.out b/src/test/modules/test_session_hooks/expected/test_session_hooks.out index 120dcc9a11..a5a93a8c39 100644 --- a/src/test/modules/test_session_hooks/expected/test_session_hooks.out +++ b/src/test/modules/test_session_hooks/expected/test_session_hooks.out @@ -2,8 +2,8 @@ -- Tests for start and end session hooks -- -- Only activity from role regress_sess_hook_usr2 is logged. -CREATE ROLE regress_sess_hook_usr1 SUPERUSER LOGIN; -CREATE ROLE regress_sess_hook_usr2 SUPERUSER LOGIN; +ALTER ROLE regress_sess_hook_usr1 SUPERUSER LOGIN; +ALTER ROLE regress_sess_hook_usr2 SUPERUSER LOGIN; \set prevdb :DBNAME \set prevusr :USER CREATE TABLE session_hook_log(id SERIAL, dbname TEXT, username TEXT, hook_at TEXT); @@ -33,5 +33,3 @@ SELECT * FROM session_hook_log ORDER BY id; 2 | contrib_regression | regress_sess_hook_usr2 | END (2 rows) -DROP ROLE regress_sess_hook_usr1; -DROP ROLE regress_sess_hook_usr2; diff --git a/src/test/modules/test_session_hooks/sql/test_session_hooks.sql b/src/test/modules/test_session_hooks/sql/test_session_hooks.sql index 1cc06f613b..f041c8bed8 100644 --- a/src/test/modules/test_session_hooks/sql/test_session_hooks.sql +++ b/src/test/modules/test_session_hooks/sql/test_session_hooks.sql @@ -3,8 +3,8 @@ -- -- Only activity from role regress_sess_hook_usr2 is logged. -CREATE ROLE regress_sess_hook_usr1 SUPERUSER LOGIN; -CREATE ROLE regress_sess_hook_usr2 SUPERUSER LOGIN; +ALTER ROLE regress_sess_hook_usr1 SUPERUSER LOGIN; +ALTER ROLE regress_sess_hook_usr2 SUPERUSER LOGIN; \set prevdb :DBNAME \set prevusr :USER CREATE TABLE session_hook_log(id SERIAL, dbname TEXT, username TEXT, hook_at TEXT); @@ -15,5 +15,3 @@ SELECT * FROM session_hook_log ORDER BY id; SELECT * FROM session_hook_log ORDER BY id; \c :prevdb :prevusr SELECT * FROM session_hook_log ORDER BY id; -DROP ROLE regress_sess_hook_usr1; -DROP ROLE regress_sess_hook_usr2; signature.asc Description: PGP signature
pgsql: Tag refs/tags/REL_12_0 was created
Tag refs/tags/REL_12_0 was created.
Re: pgsql: Add hooks for session start and session end, take two
On 10/1/19 10:28 AM, Michael Paquier wrote: > On Tue, Oct 01, 2019 at 04:13:20PM +0900, Michael Paquier wrote: >> On Tue, Oct 01, 2019 at 02:22:45PM +0900, Michael Paquier wrote: >>> Actually, it makes little sense to allow parallel workers to log their >>> activity in the module. So if there are no objections, I would like >>> to fix that by checking after IsParallelWorker() in the hooks of the >>> module. >> Fixed with 002962dc, and crake has just turned back to green. > Even with that, there is still one failure with Msys and fairywren: > ALTER DATABASE > == running regression test queries== > test test_session_hooks ... FAILED (test process exited with > exit code 2) 493 ms > == shutting down postmaster == > > == > 1 of 1 tests failed. > == > > The differences that caused some tests to fail can be viewed in the > file > "C:/tools/msys64/home/Administrator/bf/root/HEAD/pgsql.build/src/test/modules/test_session_hooks/regression.diffs". > A copy of the test summary that you see above is saved in the file > "C:/tools/msys64/home/Administrator/bf/root/HEAD/pgsql.build/src/test/modules/test_session_hooks/regression.out". > > Unfortunately it is a bit hard to grab what the problem actually is. > Andrew, could it be possible to get more information from this animal? I'll fix up the logging. Meanwhile, the log is showing: \c :prevdb regress_sess_hook_usr1 \connect: FATAL: SSPI authentication failed for user "regress_sess_hook_usr1" That's not surprising given the hba and ident file contents. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: pgsql: Implement jsonpath .datetime() method
On Mon, Sep 30, 2019 at 10:56 PM Robert Haas wrote: > On Sun, Sep 29, 2019 at 10:30 AM Alexander Korotkov > wrote: > > So, jsonpath behaves like 100 is not greater than 2020. This > > looks like plain false. And user can't expect that unless she is > > familiar with our particular issues. Now I got opinion that such > > errors shouldn't be suppressed. We can't suppress *every* error. If > > trying to do this, we can come to an idea to suppress OOM error and > > return garbage then, which is obviously ridiculous. Opinions? > > I don't know enough about jsonpath to have a view on specifically > which errors ought to be suppressed, but I agree that it's probably > not all of them. In fact, I'd go so far as to say that thinking about > it in terms of error suppression is probably not the right approach in > the first place. Rather, you want to ask what behavior you're trying > to create. > > For example, if I'm trying to write a function that takes a string as > input and returns JSON, where the result is formatted as a number if > possible or a string otherwise, I might want access at the C level to > the guts of numeric_in, with all parsing errors returned rather than > thrown. But it would be silly to suppress an out-of-memory condition, > because that doesn't help the caller. The caller wants to know whether > the thing can be parsed as a number or not, and that has nothing to do > with whether we're out of memory, so an out-of-memory error should > still be thrown. > > In this case here, it seems to me that you should similarly start by > defining the behavior you're trying to create. Unless that's clearly > defined, deciding which errors to suppress may be difficult. Making C functions return errors rather than throw is what we're implementing in our patchsets. In big picture the behavior we're trying to create is SQL Standard 2016. It defines error handling as following. > The SQL operators JSON_VALUE, JSON_QUERY, JSON_TABLE, and JSON_EXISTS provide > the following mechanisms to handle these errors: > 1) The SQL/JSON path language traps any errors that occur during the > evaluation > of a . Depending on the precise > contained in the , the result may be Unknown, True, or > False, depending on the outcome of non-error tests evaluated in the predicate>. > 2) The SQL/JSON path language has two modes, strict and lax, which govern > structural errors, as follows: > a) In lax mode: > i) If an operation requires an SQL/JSON array but the operand is not an > SQL > JSON array, then the operand is first “wrapped” in an SQL/JSON array prior > to performing the operation. > ii) If an operation requires something other than an SQL/JSON array, but > the operand is an SQL/JSON array, then the operand is “unwrapped” by > converting its elements into an SQL/JSON sequence prior to performing the > operation. > iii) After applying the preceding resolutions to structural errors, if > there is still a structural error, the result is an empty SQL/JSON > sequence. > b) In strict mode, if the structural error occurs within aexpression>, then the error handling of applies >Otherwise, a structural error is an unhandled error. > 3) Non-structural errors outside of a are always > unhandled errors, resulting in an exception condition returned from the path > engine to the SQL/JSON query operator. > 4) The SQL/JSON query operators provide an ON ERROR clause to specify the > behavior in case of an input conversion error, an unhandled structural error, > an unhandled non-structural error, or an output conversion error. So, basically standard requires us to suppress any error happening in filter expression. But as I wrote before suppression of errors in datetime comparison may lead to surprising results. That happens in rare corner cases, but still. This makes uneasy choice between consistent behavior and standard behavior. However, Nikita Glukhov gave to good idea about that. Instead on thinking about whether we should suppress or not cast errors in datetime comparison, we may just eliminate those error. So, if we know that casting date to timestamp overflows upper bound of finite timestamp, then we also know that this date is greater than any finite timestamp. So, we still able to do correct comparison. I'm going to implement this and post a patch. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company On Mon, Sep 30, 2019 at 10:56 PM Robert Haas wrote: > > On Sun, Sep 29, 2019 at 10:30 AM Alexander Korotkov > wrote: > > So, jsonpath behaves like 100 is not greater than 2020. This > > looks like plain false. And user can't expect that unless she is > > familiar with our particular issues. Now I got opinion that such > > errors shouldn't be suppressed. We can't suppress *every* error. If > > trying to do this, we can come to an idea to suppress OOM error and > > return garbage then, which
pgsql: Blind attempt to fix pglz_maximum_compressed_size
Blind attempt to fix pglz_maximum_compressed_size Commit 11a078cf87 triggered failures on big-endian machines, and the only plausible place for an issue seems to be that TOAST_COMPRESS_SIZE calls VARSIZE instead of VARSIZE_ANY. So try fixing that blindly. Discussion: https://www.postgresql.org/message-id/20191001131803.j6uin7nho7t6vxzy%40development Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/540f31680913b4e11f2caa40cafeca269cfcb22f Modified Files -- src/include/access/toast_internals.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: pgsql: Add hooks for session start and session end, take two
On Tue, Oct 01, 2019 at 04:13:20PM +0900, Michael Paquier wrote: > On Tue, Oct 01, 2019 at 02:22:45PM +0900, Michael Paquier wrote: > > Actually, it makes little sense to allow parallel workers to log their > > activity in the module. So if there are no objections, I would like > > to fix that by checking after IsParallelWorker() in the hooks of the > > module. > > Fixed with 002962dc, and crake has just turned back to green. Even with that, there is still one failure with Msys and fairywren: ALTER DATABASE == running regression test queries== test test_session_hooks ... FAILED (test process exited with exit code 2) 493 ms == shutting down postmaster == == 1 of 1 tests failed. == The differences that caused some tests to fail can be viewed in the file "C:/tools/msys64/home/Administrator/bf/root/HEAD/pgsql.build/src/test/modules/test_session_hooks/regression.diffs". A copy of the test summary that you see above is saved in the file "C:/tools/msys64/home/Administrator/bf/root/HEAD/pgsql.build/src/test/modules/test_session_hooks/regression.out". Unfortunately it is a bit hard to grab what the problem actually is. Andrew, could it be possible to get more information from this animal? -- Michael signature.asc Description: PGP signature
Re: pgsql: Make crash recovery ignore recovery target settings.
On Mon, Sep 30, 2019 at 7:28 AM David Steele wrote: > I'm surprised that we would consider going to GA with an issue like this > outstanding. Yeah, this is a *bad* problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql: Mark two variables in in aset.c with PG_USED_FOR_ASSERTS_ONLY
Mark two variables in in aset.c with PG_USED_FOR_ASSERTS_ONLY This fixes two compiler warnings about unused variables in non-assert builds, introduced by 5dd7fc1519461548eebf26c33eac6878ea3e8788. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fa2fe04bf1d4d31e099808745974964f84eb4521 Modified Files -- src/backend/utils/mmgr/aset.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: Optimize partial TOAST decompression
Optimize partial TOAST decompression Commit 4d0e994eed added support for partial TOAST decompression, so the decompression is interrupted after producing the requested prefix. For prefix and slices near the beginning of the entry, this may saves a lot of decompression work. That however only deals with decompression - the whole compressed entry was still fetched and re-assembled, even though the compression used only a small fraction of it. This commit improves that by computing how much compressed data may be needed to decompress the requested prefix, and then fetches only the necessary part. We always need to fetch a bit more compressed data than the requested (uncompressed) prefix, because the prefix may not be compressible at all and pglz itself adds a bit of overhead. That means this optimization is most effective when the requested prefix is much smaller than the whole compressed entry. Author: Binguo Bao Reviewed-by: Andrey Borodin, Tomas Vondra, Paul Ramsey Discussion: https://www.postgresql.org/message-id/flat/CAL-OGkthU9Gs7TZchf5OWaL-Gsi=hxquftxkv9qpng73d5n...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/11a078cf87ffb611d19c7dec6df68b41084ad9c9 Modified Files -- src/backend/access/common/detoast.c | 54 ++-- src/common/pg_lzcompress.c | 37 src/include/access/toast_internals.h | 1 + src/include/common/pg_lzcompress.h | 2 ++ 4 files changed, 86 insertions(+), 8 deletions(-)
Re: pgsql: Add hooks for session start and session end, take two
On Tue, Oct 01, 2019 at 02:22:45PM +0900, Michael Paquier wrote: > Actually, it makes little sense to allow parallel workers to log their > activity in the module. So if there are no objections, I would like > to fix that by checking after IsParallelWorker() in the hooks of the > module. Fixed with 002962dc, and crake has just turned back to green. -- Michael signature.asc Description: PGP signature
