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 archive
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 archive
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 archive
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 archive
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 archive
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 archive
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 disappoint
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 m
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 inform
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
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
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 inhe
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
Tag refs/tags/REL_12_0 was created.
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 ar
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.
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/m
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
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
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/fa2fe04bf1d4d31e099808
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 deal
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 wi
22 matches
Mail list logo
