FYI, this was improved in a recent commit:
commit 75af0f401f
Author: Tom Lane
Date: Fri Sep 29 13:13:54 2023 -0400
Doc: improve description of dump/restore's --clean and --if-exists.
Try to make these option descriptions a litt
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Thanks for the review. I have committed the patches.
No objections to what was committed.
> On Thu, Mar 2, 2023 at 2:59 AM Michael Paquier wrote:
> > There is more to it: the page LSN is checked before its checksum.
> > Hence, if the pag
Thanks for the review. I have committed the patches.
On Thu, Mar 2, 2023 at 2:59 AM Michael Paquier wrote:
> Seems right, I think that you should backpatch that as
> VERIFY_CHECKSUMS is the default.
Done.
> There is more to it: the page LSN is checked before its checksum.
> Hence, if the page's
On Thu, Feb 02, 2023 at 03:23:51PM -0500, Robert Haas wrote:
> 0001 fixes what I believe to be a slight logical error in sendFile(),
> introduced by me during the v15 development cycle when I introduced
> the bbsink abstraction. I believe that it is theoretically possible
> for this to cause an ass
Here are a few small patches for basebackup.c:
0001 fixes what I believe to be a slight logical error in sendFile(),
introduced by me during the v15 development cycle when I introduced
the bbsink abstraction. I believe that it is theoretically possible
for this to cause an assertion failure, altho
=?UTF-8?Q?Torsten_F=C3=B6rtsch?= writes:
> Why not
> (void)getRecordTimestamp(record, &recordXtime);
> if (recoveryTarget == RECOVERY_TARGET_TIME)
> ...
Could've done it like that, but I already pushed the other
version, and I don't think it's worth the trouble to change.
Laurenz Albe writes:
> On Wed, 2023-01-18 at 15:03 -0500, Tom Lane wrote:
>> Ah, but that only happens if recoveryTarget == RECOVERY_TARGET_TIME.
>> Digging in the git history, I see that this did use to work as
>> I remember: we always extracted the record time before printing it.
>> That was acc
If we never expect getRecordTimestamp to fail, then why put it in the
if-condition?
getRecordTimestamp can fail if the record is not a restore point nor a
commit or abort record. A few lines before in the same function there is
this:
/* Otherwise we only consider stopping before COMMIT or ABORT
On Wed, 2023-01-18 at 15:03 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> > > I seem to recall that the original idea was to report the timestamp
> > > of the commit/abort record we are stopping at. Maybe my memory is
> > > faulty, but I th
Laurenz Albe writes:
> On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
>> I seem to recall that the original idea was to report the timestamp
>> of the commit/abort record we are stopping at. Maybe my memory is
>> faulty, but I think that'd be significantly more useful than the
>> current beha
On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-01-16 at 19:59 +0100, Torsten Förtsch wrote:
> > > So, the timestamp displayed in the log message is certainly wrong.
>
> > If recovery stops at a WAL record that has no timestamp, you get this
> > bogus re
Laurenz Albe writes:
> On Mon, 2023-01-16 at 19:59 +0100, Torsten Förtsch wrote:
>> So, the timestamp displayed in the log message is certainly wrong.
> If recovery stops at a WAL record that has no timestamp, you get this
> bogus recovery stop time. I think we should show the recovery stop time
On Tue, Jan 17, 2023 at 10:42:03AM +0100, Laurenz Albe wrote:
> If recovery stops at a WAL record that has no timestamp, you get this
> bogus recovery stop time. I think we should show the recovery stop time
> only if time was the target, as in the attached patch.
Good catch! I'll try to take a
On Mon, 2023-01-16 at 19:59 +0100, Torsten Förtsch wrote:
> not sure if this is known behavior.
>
> Server version is 14.6 (Debian 14.6-1.pgdg110+1).
>
> In a PITR setup I have these settings:
>
> recovery_target_xid = '852381'
> recovery_target_inclusive = 'false'
>
> In the log file I see thi
On 10/24/22 03:01, Tom Lane wrote:
=?UTF-8?Q?Fr=c3=a9d=c3=a9ric_Yhuel?= writes:
When using pg_dump (or pg_restore) with option "--clean", there is some
SQL code to drop every objects at the beginning.
Yup ...
The DROP statement for a view involving circular dependencies is :
CREATE OR REPLA
=?UTF-8?Q?Fr=c3=a9d=c3=a9ric_Yhuel?= writes:
> When using pg_dump (or pg_restore) with option "--clean", there is some
> SQL code to drop every objects at the beginning.
Yup ...
> The DROP statement for a view involving circular dependencies is :
> CREATE OR REPLACE VIEW [...]
> (see commit mes
Hi,
Good catch! Here are several points for improvement:
1. pg_dump.c:17380
Maybe better to write simpler
appendPQExpBuffer(delcmd, "CREATE SCHEMA IF NOT EXISTS %s;\n",
tbinfo->dobj.namespace->dobj.name);
because there is a schema name inside the `tbinfo->dobj.namespace->dobj.name
`
2. pg_back
Hello,
When using pg_dump (or pg_restore) with option "--clean", there is some
SQL code to drop every objects at the beginning.
The DROP statement for a view involving circular dependencies is :
CREATE OR REPLACE VIEW [...]
(see commit message of d8c05aff for a much better explanation)
If t
Hi,
While looking at sort_inner_and_outer() I was rather confused what is
stored in all_pathkeys, because the code does this:
List *all_pathkeys;
...
all_pathkeys = select_outer_pathkeys_for_merge(root,
extra->mergeclause_list,
During a stress test of an experimental patch (which implements a new
technique for managing B-Tree index bloat caused by non-HOT updates),
I noticed a minor bug in _bt_truncate(). The issue affects Postgres 12
+ master.
The problem is that INCLUDE indexes don't have their non-key
attri
On Wed, 30 Oct 2019 09:26:21 +0900
Michael Paquier wrote:
> On Tue, Oct 29, 2019 at 04:42:07PM -0700, Peter Geoghegan wrote:
> > The same commit from Heikki omitted one field from that record, for no
> > good reason. I backpatched a bugfix to the output format for nbtree
> > page splits a few wee
t 2c03216d831160bedd72d45f712601b6f7d03f1c
> Author: Heikki Linnakangas
> Date: 2014-11-20 17:56:26 +0200
>
> Revamp the WAL record format.
>
>
> Does anybody have an opinion about fixing it just in master or also
> backpatching it? I guess there could be
On Tue, Oct 29, 2019 at 04:42:07PM -0700, Peter Geoghegan wrote:
> The same commit from Heikki omitted one field from that record, for no
> good reason. I backpatched a bugfix to the output format for nbtree
> page splits a few weeks ago, fixing that problem. I agree that we
> should also backpatch
On Tue, Oct 29, 2019 at 4:33 PM Andres Freund wrote:
> Does anybody have an opinion about fixing it just in master or also
> backpatching it? I guess there could be people having written parsers
> for the waldump output? I'm inclined to backpatch.
The same commit from Heikki omitted one field fr
oes anybody have an opinion about fixing it just in master or also
backpatching it? I guess there could be people having written parsers
for the waldump output? I'm inclined to backpatch.
I also find a second minor bug:
static void
XLogDumpDisplayRecord(XLogDumpConfig *config, XLogReaderStat
Hello Michaël,
Thanks, committed and back-patched.
Ok.
I have added some tests for least() and greatest() on the way.
Good!
Thanks,
--
Fabien.
On Thu, Jul 26, 2018 at 11:16:06PM -0400, Fabien COELHO wrote:
> Could be backpatched to 11 where hash was introduced.
Thanks, committed and back-patched. I have added some tests for least()
and greatest() on the way.
--
Michael
signature.asc
Description: PGP signature
While doing something else, I noticed that pgbench's hash() does not fail
gracefully:
sh> cat hash.sql
\set i hash()
sh> pgbench -f hash.sql -t 1
...
cannot coerce (null) to int
client 0 aborted in command 0 (set) of script 0; evaluation of meta-command
failed
The message is not very
On Thu, Jan 18, 2018 at 03:27:43PM +0300, Anna Akenteva wrote:
> Would it be possible to fix it the same way in REL9_6_STABLE and maybe other
> older versions too?
Yes, this was part of an investigation that led to 052cc223 to improve
OOM handling, which involved way more code paths than just this
After checking some code from REL9_6_STABLE with a static analyzer, I've
found this bit:
src/common/exec.c:586 putenv(strdup(env_path));
...
src/common/exec.c:597 putenv(strdup(env_path));
Theoretically, strdup might return NULL, and we'll send NULL as an
argument to putenv
30 matches
Mail list logo
