Avoid time-of-day-dependent failure in log rotation test.
Buildfarm members pogona and petalura have shown a failure when
pg_ctl/t/004_logrotate.pl starts just before local midnight.
The default rotate-at-midnight behavior occurs just before the
Perl script examines current_logfiles, so it figures
Avoid time-of-day-dependent failure in log rotation test.
Buildfarm members pogona and petalura have shown a failure when
pg_ctl/t/004_logrotate.pl starts just before local midnight.
The default rotate-at-midnight behavior occurs just before the
Perl script examines current_logfiles, so it figures
Avoid time-of-day-dependent failure in log rotation test.
Buildfarm members pogona and petalura have shown a failure when
pg_ctl/t/004_logrotate.pl starts just before local midnight.
The default rotate-at-midnight behavior occurs just before the
Perl script examines current_logfiles, so it figures
On Thu, Dec 24, 2020 at 09:20:27PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I now understand the wisdom of your suggestion. Attached is a patch
> > that removes hex_decode from ecpg properly, and returns -1 from the
> > /common version.
>
> I'm fairly unimpressed with this. I don't li
Bruce Momjian writes:
> I now understand the wisdom of your suggestion. Attached is a patch
> that removes hex_decode from ecpg properly, and returns -1 from the
> /common version.
I'm fairly unimpressed with this. I don't like having fundamentally
different (and 100% undocumented) behaviors be
On Fri, Dec 25, 2020 at 09:04:41AM +0900, Michael Paquier wrote:
> Looks like the defense put in place by 6b1c5ca has allowed to catch up
> a bug here. When base64 has been copied from encode.c to src/common/
> for SCRAM (newlines should not be handled by SCRAM, hence the copy),
> we have done the
On Thu, Dec 24, 2020 at 06:16:20PM -0500, Bruce Momjian wrote:
> On Thu, Dec 24, 2020 at 06:14:49PM -0500, Tom Lane wrote:
>> Bruce Momjian writes:
>> > move hex_decode() to /common so it can be called from frontend
>>
>> The buildfarm seems pretty unimpressed with this.
>
> Yes, we are working
On Thu, Dec 24, 2020 at 06:25:56PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > revert removal of hex_decode() from ecpg from commit c3826f831e
> > ecpglib on certain platforms can't handle the pg_log_fatal calls from
> > libraries. This was reported by the buildfarm. It needs a refactorin
Bruce Momjian writes:
> revert removal of hex_decode() from ecpg from commit c3826f831e
> ecpglib on certain platforms can't handle the pg_log_fatal calls from
> libraries. This was reported by the buildfarm. It needs a refactoring
> and return value change if it is later removed.
Just for the
revert removal of hex_decode() from ecpg from commit c3826f831e
ecpglib on certain platforms can't handle the pg_log_fatal calls from
libraries. This was reported by the buildfarm. It needs a refactoring
and return value change if it is later removed.
Backpatch-through: master
Branch
--
ma
On Thu, Dec 24, 2020 at 06:14:49PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > move hex_decode() to /common so it can be called from frontend
>
> The buildfarm seems pretty unimpressed with this.
Yes, we are working on reverting the ecpg part.
--
Bruce Momjian https://momjian
Bruce Momjian writes:
> move hex_decode() to /common so it can be called from frontend
The buildfarm seems pretty unimpressed with this.
regards, tom lane
move hex_decode() to /common so it can be called from frontend
This allows removal of a copy of hex_decode() from ecpg, and will be
used by the soon-to-be added pg_alterckey command.
Backpatch-through: master
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c3826f83
Fix race condition between shutdown and unstarted background workers.
If a database shutdown (smart or fast) is commanded between the time
some process decides to request a new background worker and the time
that the postmaster can launch that worker, then nothing happens
because the postmaster wo
Fix race condition between shutdown and unstarted background workers.
If a database shutdown (smart or fast) is commanded between the time
some process decides to request a new background worker and the time
that the postmaster can launch that worker, then nothing happens
because the postmaster wo
Fix race condition between shutdown and unstarted background workers.
If a database shutdown (smart or fast) is commanded between the time
some process decides to request a new background worker and the time
that the postmaster can launch that worker, then nothing happens
because the postmaster wo
Fix race condition between shutdown and unstarted background workers.
If a database shutdown (smart or fast) is commanded between the time
some process decides to request a new background worker and the time
that the postmaster can launch that worker, then nothing happens
because the postmaster wo
Fix race condition between shutdown and unstarted background workers.
If a database shutdown (smart or fast) is commanded between the time
some process decides to request a new background worker and the time
that the postmaster can launch that worker, then nothing happens
because the postmaster wo
Improve client error messages for immediate-stop situations.
Up to now, if the DBA issued "pg_ctl stop -m immediate", the message
sent to clients was the same as for a crash-and-restart situation.
This is confusing, not least because the message claims that the
database will soon be up again, some
Fix typos and grammar in docs and comments
This fixes several areas of the documentation and some comments in
matters of style, grammar, or even format.
Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.po
20 matches
Mail list logo
