On 15/12/2023 15:58, Richard Guo wrote:
With the patch the estimate for the number of distinct 'b' values is
more accurate.
+1 to commit this patch.
It looks good and resolves kind of a bug in the code.
BTW, this patch does not change any existing regression test results. I
attempted to
On Wed, Feb 14, 2024 at 9:07 AM Hayato Kuroda (Fujitsu)
wrote:
>
> > pg_upgrade/t/004_subscription.pl says
> >
> > |my $mode = $ENV{PG_TEST_PG_UPGRADE_MODE} || '--copy';
> >
> > ..but I think maybe it should not.
> >
> > When you try to use --link, it fails:
> >
Hi,
In <20240213.173340.1518143507526518973@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 13 Feb 2024 17:33:40 +0900 (JST),
Sutou Kouhei wrote:
> I'll reply other comments later...
I've read other comments and my answers for them are
On 18/12/2023 19:53, Tomas Vondra wrote:
On 12/18/23 11:40, Richard Guo wrote:
The challenge is where to get usable information about correlation
between columns. I only have a couple very rought ideas of what might
try. For example, if we have multi-column ndistinct statistics, we might
look at
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 14 Feb 2024 15:52:36 +0900,
Michael Paquier wrote:
>> How about InputFunctionCallSafeWithInfo(),
>> InputFunctionCallSafeInfo() or
>> InputFunctionCallInfoCallSafe()?
>
> WithInfo() would not be a
At Thu, 15 Feb 2024 09:22:23 +0530, shveta malik wrote
in
> On Thu, Feb 15, 2024 at 8:26 AM Amit Kapila wrote:
> >
> > On Wed, Feb 14, 2024 at 7:51 PM Euler Taveira wrote:
> > >
> > > On Wed, Feb 14, 2024, at 8:45 AM, Amit Kapila wrote:
> > >
> > > Now, I am less clear about whether to quote
On Fri, Feb 2, 2024 at 12:48 AM vignesh C wrote:
>
> On Tue, 3 Oct 2023 at 15:54, vignesh C wrote:
> >
> > On Mon, 3 Jul 2023 at 07:16, Masahiko Sawada wrote:
> > >
> > > On Fri, Jun 23, 2023 at 12:39 PM Dilip Kumar
> > > wrote:
> > > >
> > > > On Fri, Jun 9, 2023 at 10:47 AM Masahiko Sawada
On Thu, Feb 15, 2024 at 10:37 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Euler,
>
> Here are my minor comments for 17.
>
> 01.
> ```
> /* Options */
> static const char *progname;
>
> static char *primary_slot_name = NULL;
> static bool dry_run = false;
>
> static bool success = false;
>
> static
On Thu, Feb 15, 2024 at 12:15:40PM +0700, Oleg Tselebrovskiy wrote:
> Greetings again.
> I was looking through more static analyzer output and found another problem.
> In ecpg/pgtypeslib/dt_common.c there are 4 calls of pgtypes_alloc.
> This function uses calloc and returns NULL if OOM, but we
Greetings, everyone!
While analyzing output of Svace static analyzer [1] I've found a bug.
In function pgxmlNodeSetToText there is a call of xmlBufferCreate that
doesn't
have its return value checked. In all four other calls of
xmlBufferCreate there
is a try...catch that checks the return
On Thu, 15 Feb 2024 at 08:42, Amit Kapila wrote:
>
> On Wed, Feb 14, 2024 at 12:58 PM vignesh C wrote:
> >
> > On Wed, 7 Feb 2024 at 16:27, vignesh C wrote:
> > >
> > > I was able to reproduce the issue consistently with the changes shared
> > > by Tom Lane at [1].
> > > I have made changes to
Greetings again.
I was looking through more static analyzer output and found another
problem.
In ecpg/pgtypeslib/dt_common.c there are 4 calls of pgtypes_alloc.
This function uses calloc and returns NULL if OOM, but we don't check
its
return value and immediately pass it to strcpy, which could
On Thu, Feb 15, 2024 at 3:07 AM Andres Freund wrote:
> > I think the last remaining question here is about the 0- vs 1-based indexing
> > of BackendIds. Is it a good idea to switch to 0-based indexing? And if we do
> > it, should we reserve PGPROC 0. I'm on the fence on this one.
>
> I lean
On Thu, Jan 18, 2024 at 02:20:28PM +, Bertrand Drouvot wrote:
> On Thu, Jan 18, 2024 at 04:59:39PM +0530, Bharath Rupireddy wrote:
>> I'm not sure if it
>> can happen at all, but I think we can rely on previous conflict reason
>> instead of previous
On Thu, Feb 15, 2024 at 10:33 AM Andres Freund wrote:
> The issue here is that we need to read index leaf pages (synchronously for
> now!) to get the tids to do readahead of table data. What you describe is done
> for the table data (IMO not a good idea medium term [1]), but the problem at
> hand
On Wed, 7 Feb 2024 at 12:05, Andy Fan wrote:
> +static int
> +pathkeys_useful_for_setop(PlannerInfo *root, List *pathkeys)
> +{
> + int n_common_pathkeys;
> +
> + if (root->setop_pathkeys == NIL)
> + return 0; /* no
Hi,
On 2024-02-15 09:59:27 +0530, Robert Haas wrote:
> I would have thought that the way this prefetching would work is that
> we would bring pages into shared_buffers sooner than we currently do,
> but not actually pin them until we're ready to use them, so that it's
> possible they might be
On Tue, 6 Feb 2024 at 22:05, Richard Guo wrote:
> I'm thinking that maybe it'd be better to move the work of sorting the
> subquery's paths to the outer query level, specifically within the
> build_setop_child_paths() function, just before we stick SubqueryScanPath
> on top of the subquery's
On Wed, Feb 14, 2024 at 7:43 PM Tomas Vondra
wrote:
> I don't think it's just a bookkeeping problem. In a way, nbtree already
> does keep an array of tuples to kill (see btgettuple), but it's always
> for the current index page. So it's not that we immediately go and kill
> the prior tuple -
On Fri, Jan 19, 2024 at 11:35:30AM +1300, Thomas Munro wrote:
> On Fri, Jan 19, 2024 at 1:47 AM Anton Voloshin
> wrote:
>> I believe there is a small problem in the 039_end_of_wal.pl's
>> "xl_tot_len zero" test. It supposes that after immediate shutdown the
>> server, upon startup recovery,
On Wed, Feb 14, 2024 at 10:21 PM Tomas Vondra
wrote:
> The way I think about non-transactional sequence changes is as if they
> were tiny transactions that happen "fully" (including commit) at the LSN
> where the LSN change is logged.
100% this.
> It does not mean we can arbitrarily reorder the
On 6/2/2024 19:51, Ashutosh Bapat wrote:
On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
The patches are raw. make check has some crashes that I need to fix. I
am waiting to hear whether this is useful and whether the design is on
the right track.
Let me write words of opinion on that feature.
I
On Thu, Feb 15, 2024 at 8:26 AM Amit Kapila wrote:
>
> On Wed, Feb 14, 2024 at 7:51 PM Euler Taveira wrote:
> >
> > On Wed, Feb 14, 2024, at 8:45 AM, Amit Kapila wrote:
> >
> > Now, I am less clear about whether to quote "logical" or not in the
> > above message. Do you have any suggestions?
> >
On Thursday, February 15, 2024 10:49 AM Amit Kapila
wrote:
>
> On Wed, Feb 14, 2024 at 7:26 PM Bertrand Drouvot
> wrote:
> >
> > On Wed, Feb 14, 2024 at 10:40:11AM +, Zhijie Hou (Fujitsu) wrote:
> > > On Wednesday, February 14, 2024 6:05 PM Amit Kapila
> wrote:
> > > >
> > > > To ensure
On Sat, Feb 10, 2024 at 9:29 PM John Naylor wrote:
>
> On Tue, Feb 6, 2024 at 9:58 AM Masahiko Sawada wrote:
> >
> > On Fri, Feb 2, 2024 at 8:47 PM John Naylor wrote:
>
> > > My todo:
> > > - benchmark tid store / vacuum again, since we haven't since varlen
> > > types and removing unnecessary
Thomas Munro writes:
> On Thu, Oct 5, 2023 at 9:07 PM David Rowley wrote:
>> Thanks. Pushed.
>
> FYI somehow this plan from a8a968a8212e flipped in this run:
>
> === dumping
> /home/bf/bf-build/mylodon/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/regression.diffs
> ===
> diff
On Wed, Feb 14, 2024 at 12:58 PM vignesh C wrote:
>
> On Wed, 7 Feb 2024 at 16:27, vignesh C wrote:
> >
> > I was able to reproduce the issue consistently with the changes shared
> > by Tom Lane at [1].
> > I have made changes to change ALTER SUBSCRIPTION to DROP+CREATE
> > SUBSCRIPTION and
On Thu, 15 Feb 2024 at 07:24, Michael Paquier wrote:
>
> On Wed, Feb 14, 2024 at 03:51:08PM +0530, vignesh C wrote:
> > First regex is the testname_clusterinstance_data, second regex is the
> > timestamp used for pg_upgrade, third regex is for the text files
> > generated by pg_upgrade and fourth
On Wed, Feb 14, 2024 at 7:51 PM Euler Taveira wrote:
>
> On Wed, Feb 14, 2024, at 8:45 AM, Amit Kapila wrote:
>
> Now, I am less clear about whether to quote "logical" or not in the
> above message. Do you have any suggestions?
>
>
> The possible confusion comes from the fact that the sentence
On Wed, Feb 14, 2024 at 7:26 PM Bertrand Drouvot
wrote:
>
> On Wed, Feb 14, 2024 at 10:40:11AM +, Zhijie Hou (Fujitsu) wrote:
> > On Wednesday, February 14, 2024 6:05 PM Amit Kapila
> > wrote:
> > >
> > > To ensure that restart_lsn has been moved to a recent position, we need
> > > to log
On Wed, Feb 14, 2024 at 03:51:08PM +0530, vignesh C wrote:
> First regex is the testname_clusterinstance_data, second regex is the
> timestamp used for pg_upgrade, third regex is for the text files
> generated by pg_upgrade and fourth regex is for the log files
> generated by pg_upgrade.
>
> Can
On Wed, Feb 14, 2024 at 12:29:07PM +0530, Amul Sul wrote:
> Ok, I did that way in the attached version, I have passed the control file's
> full path as a second argument to verify_system_identifier() what we gets in
> verify_backup_file(), but that is not doing any useful things with it,
> since
On Wed, Feb 14, 2024 at 7:28 PM Andres Freund wrote:
> On 2024-02-13 14:54:14 -0500, Peter Geoghegan wrote:
> > This property of index scans is fundamental to how index scans work.
> > Pinning an index page as an interlock against concurrently TID
> > recycling by VACUUM is directly described by
Hi,
On 2024-02-13 14:54:14 -0500, Peter Geoghegan wrote:
> This property of index scans is fundamental to how index scans work.
> Pinning an index page as an interlock against concurrently TID
> recycling by VACUUM is directly described by the index API docs [1],
> even (the docs actually use
Hi,
On 2024-02-14 16:45:57 -0500, Melanie Plageman wrote:
> > > The LIMIT problem is not very clear to me either. Yes, if we get close
> > > to the end of the leaf page, we may need to visit the next leaf page.
> > > But that's kinda the whole point of prefetching - reading stuff ahead,
> > > and
On Wed, Feb 14, 2024 at 11:55:43AM -0800, Noah Misch wrote:
> I took a look over each of these. +1 for all. Thank you.
Committed. Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Feb 14, 2024 at 4:46 PM Melanie Plageman
wrote:
> So, a pin on the index leaf page is sufficient to keep line pointers
> from being reused? If we stick to prefetching heap blocks referred to
> by index tuples in a single index leaf page, and we keep that page
> pinned, will we still have
>>> From [1] I think the JDBC driver sends something like below if
>>> autosave=always option is specified.
>>>
>>> "BEGIN READ ONLY" Parse/Bind/Eexecute (in the extended query protocol)
>>> "SAVEPOINT PGJDBC_AUTOSAVE" (in the simple query protocol)
>>>
>>> It seems the SAVEPOINT is sent without
> On 14 Feb 2024, at 23:06, Melanie Plageman wrote:
>
> On Wed, Feb 14, 2024 at 11:35 AM Jelte Fennema-Nio wrote:
>>
>> This brings our .gitattributes and .editorconfig files more in line. I
>> had the problem that "git add" would complain often about trailing
>> whitespaces when I was
On Wed, Feb 14, 2024 at 11:35 AM Jelte Fennema-Nio wrote:
>
> This brings our .gitattributes and .editorconfig files more in line. I
> had the problem that "git add" would complain often about trailing
> whitespaces when I was changing sgml files specifically.
+1 from me. But when do we want it
On Wed, Feb 14, 2024 at 1:21 PM Peter Geoghegan wrote:
>
> On Wed, Feb 14, 2024 at 8:34 AM Tomas Vondra
> wrote:
> > > Another thing that argues against doing this is that we might not need
> > > to visit any more B-Tree leaf pages when there is a LIMIT n involved.
> > > We could end up scanning
Hi,
On 2024-02-08 13:19:53 +0200, Heikki Linnakangas wrote:
> > > - /*
> > > - * Assign the ProcSignalSlot for an auxiliary process. Since it doesn't
> > > - * have a BackendId, the slot is statically allocated based on the
> > > - * auxiliary process type (MyAuxProcType). Backends use slots
On Wed, Feb 14, 2024 at 11:40 AM Melanie Plageman
wrote:
>
> On Tue, Feb 13, 2024 at 2:01 PM Tomas Vondra
> wrote:
> >
> > On 2/7/24 22:48, Melanie Plageman wrote:
> > > ...
> > > - switching scan directions
> > >
> > > If the index scan switches directions on a given invocation of
> > >
> On 14 Feb 2024, at 19:51, Nathan Bossart wrote:
>
> On Wed, Feb 14, 2024 at 10:04:49AM -0500, Tom Lane wrote:
>> Daniel Gustafsson writes:
>>> On 14 Feb 2024, at 11:35, Dave Page wrote:
That said, pgAdmin III has been out of support for many years, and as
far as I know, it (and
On Mon, Dec 18, 2023 at 11:32:47AM -0600, Nathan Bossart wrote:
> rebased for cfbot
I took a look over each of these. +1 for all. Thank you.
Hi,
On 2024-02-13 18:11:25 -0500, Melanie Plageman wrote:
> Attached is a patch set which refactors BitmapHeapScan such that it
> can use the streaming read API [1]. It also resolves the long-standing
> FIXME in the BitmapHeapScan code suggesting that the skip fetch
> optimization should be
I wrote:
> There's one big remaining to-do item, I think: experimentation with
> pg_upgrade proves that a binary upgrade fails to fix the extension
> membership of arrays/rowtypes. That's because pg_dump needs to
> manually reconstruct the membership dependencies, and it thinks that
> it doesn't
On Wed, Feb 14, 2024 at 11:40 AM Melanie Plageman
wrote:
> I wasn't quite sure how we could use
> index_compute_xid_horizon_for_tuples() for inspiration -- per Peter's
> suggestion. But, I'd like to understand.
The point I was trying to make with that example was: a highly generic
mechanism can
On Wed, Feb 14, 2024 at 10:20:28AM -0800, Jeff Davis wrote:
> If those arguments are still unconvincing, then the next idea is to fix
> the search_path for all maintenance commands[3]. I tried this during
> the 16 cycle, but due to timing issues it was also reverted. I can
> proceed with this
On Wed, Feb 14, 2024 at 10:04:49AM -0500, Tom Lane wrote:
> Daniel Gustafsson writes:
>> On 14 Feb 2024, at 11:35, Dave Page wrote:
>>> That said, pgAdmin III has been out of support for many years, and as
>>> far as I know, it (and similarly old versions of EDB's PEM which was
>>> based on it)
On Wed, Feb 14, 2024 at 01:45:31PM -0500, Tom Lane wrote:
> "Pavlo Golub" writes:
>> Oh, thanks! I forgot, indeed, to update docs and catalog version! My
>> bad!
>
> Docs, yes, but don't include catversion bumps in submitted patches.
> They'll just lead to merge problems when somebody else
On Wed, Feb 14, 2024, 19:45 Tom Lane wrote:
> "Pavlo Golub" writes:
> > Oh, thanks! I forgot, indeed, to update docs and catalog version! My
> > bad!
>
> Docs, yes, but don't include catversion bumps in submitted patches.
> They'll just lead to merge problems when somebody else changes the
>
"Pavlo Golub" writes:
> Oh, thanks! I forgot, indeed, to update docs and catalog version! My
> bad!
Docs, yes, but don't include catversion bumps in submitted patches.
They'll just lead to merge problems when somebody else changes the
current catversion. We rely on the committer to remember to
On Wed, 14 Feb 2024 at 18:41, Alvaro Herrera wrote:
> Hmm, I think the changes to libpq_pipeline in 0005 should be in 0004.
Yeah, you're correct. Fixed that now.
v32-0005-Start-using-new-libpq-cancel-APIs.patch
Description: Binary data
On Wed, Feb 14, 2024 at 8:34 AM Tomas Vondra
wrote:
> > Another thing that argues against doing this is that we might not need
> > to visit any more B-Tree leaf pages when there is a LIMIT n involved.
> > We could end up scanning a whole extra leaf page (including all of its
> > tuples) for want
The MAINTAIN privilege was reverted during the 16 cycle because of the
potential for someone to play tricks with search_path.
For instance, if user foo does:
CREATE FUNCTION mod7(INT) RETURNS INT IMMUTABLE
LANGUAGE plpgsql AS $$ BEGIN RETURN mod($1, 7); END; $$;
CREATE TABLE x(i INT);
On Mon, Feb 12, 2024 at 09:49:45AM -0600, Nathan Bossart wrote:
Okay. I'll plan on committing this in the next few days.
Here is what I have staged for commit.
Oh, thanks! I forgot, indeed, to update docs and catalog version! My
bad!
In my defense, I was trying to find tests but I
On Wed, Feb 14, 2024 at 08:59:06AM +0100, Daniel Gustafsson wrote:
> LGTM.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 2024-Feb-14, Jelte Fennema-Nio wrote:
> Attached is a new version of the final patches, with much improved
> docs (imho) and the new function names: PQcancelStart and
> PQcancelBlocking.
Hmm, I think the changes to libpq_pipeline in 0005 should be in 0004.
--
Álvaro Herrera
On Sun, 4 Feb 2024 at 16:39, Alvaro Herrera wrote:
> Maybe this is okay? I'll have a look at the whole final situation more
> carefully later; or if somebody else wants to share an opinion, please
> do so.
Attached is a new version of the final patches, with much improved
docs (imho) and the
On Tue, Feb 13, 2024, at 23:56, Corey Huinker wrote:
> This patch came out of a discussion at the last PgCon with the person
> who made the "fringe feature" quote, who seemed quite supportive of
> documenting the technique. The comment may have been in regards to
> actually implementing a LIMIT
On 08.02.24 16:53, Tom Lane wrote:
Daniel Gustafsson writes:
On 8 Feb 2024, at 08:01, Peter Eisentraut wrote:
I suppose we could start using it for completely new scripts.
+1, it would be nice to eventually be able to move to it everywhere so starting
now with new scripts may make the
On 2/13/24 17:37, Robert Haas wrote:
> On Sun, Jan 28, 2024 at 1:07 AM Tomas Vondra
> wrote:
>> Right, locks + apply in commit order gives us this guarantee (I can't
>> think of a case where it wouldn't be the case).
>
> I couldn't find any cases of inadequate locking other than the one I
>
This should target PG 18, but that status is not available in the CF app yet,
so just making a note here.
> On Feb 14, 2024, at 6:47 AM, Melanie Plageman
> wrote:
>
> Just curious, did your table AM implement
> table_scan_bitmap_next_block() and table_scan_bitmap_next_tuple(),
> and, if so, did you use the TBMIterateResult? Since it is not used in
> BitmapHeapNext() in my version, table AMs
On Tue, Feb 13, 2024 at 2:01 PM Tomas Vondra
wrote:
>
> On 2/7/24 22:48, Melanie Plageman wrote:
> > ...
Issues
> > ---
> > - kill prior tuple
> >
> > This optimization doesn't work with index prefetching with the current
> > design. Kill prior tuple relies on alternating between fetching a
> >
This brings our .gitattributes and .editorconfig files more in line. I
had the problem that "git add" would complain often about trailing
whitespaces when I was changing sgml files specifically.
v1-0001-Configure-trailing-whitespace-trimming-in-editorc.patch
Description: Binary data
Hi,
On Sat, Feb 10, 2024 at 05:02:27PM -0800, Noah Misch wrote:
> Coincidentally, one of my buildfarm animals hanged several weeks in a
> different test, 035_standby_logical_decoding.pl. A LOG_SNAPSHOT_INTERVAL_MS
> reduction was part of making it reproducible:
>
> On Fri, Feb 02, 2024 at
Daniel Gustafsson writes:
> On 14 Feb 2024, at 11:35, Dave Page wrote:
>> That said, pgAdmin III has been out of support for many years, and as far as
>> I know, it (and similarly old versions of EDB's PEM which was based on it)
>> were the only consumers of adminpack. I would not be sad to
On Tue, Feb 13, 2024 at 11:34 PM Mark Dilger
wrote:
>
> > On Feb 13, 2024, at 3:11 PM, Melanie Plageman
> > wrote:
>
> Thanks for the patch...
>
> > Attached is a patch set which refactors BitmapHeapScan such that it
> > can use the streaming read API [1]. It also resolves the long-standing
> >
On Wed, Feb 14, 2024, at 8:45 AM, Amit Kapila wrote:
> Now, I am less clear about whether to quote "logical" or not in the
> above message. Do you have any suggestions?
The possible confusion comes from the fact that the sentence contains "must be"
in the middle of a comparison expression. For
On 2/14/24 08:10, Robert Haas wrote:
> On Thu, Feb 8, 2024 at 3:18 AM Melanie Plageman
> wrote:
>> - kill prior tuple
>>
>> This optimization doesn't work with index prefetching with the current
>> design. Kill prior tuple relies on alternating between fetching a
>> single index tuple and
Hi,
On Wed, Feb 14, 2024 at 10:40:11AM +, Zhijie Hou (Fujitsu) wrote:
> On Wednesday, February 14, 2024 6:05 PM Amit Kapila
> wrote:
> >
> > On Wed, Feb 14, 2024 at 2:14 PM Amit Kapila wrote:
> > >
> > > On Wed, Feb 14, 2024 at 9:34 AM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > >
> On 14 Feb 2024, at 11:35, Dave Page wrote:
> That said, pgAdmin III has been out of support for many years, and as far as
> I know, it (and similarly old versions of EDB's PEM which was based on it)
> were the only consumers of adminpack. I would not be sad to see it removed
> entirely
On 2/13/24 20:54, Peter Geoghegan wrote:
> On Tue, Feb 13, 2024 at 2:01 PM Tomas Vondra
> wrote:
>> On 2/7/24 22:48, Melanie Plageman wrote:
>> I admit I haven't thought about kill_prior_tuple until you pointed out.
>> Yeah, prefetching separates (de-synchronizes) the two scans (index and
>>
Hi!
On Fri, Jan 12, 2024 at 11:00 PM Robert Haas wrote:
> On Fri, Jan 12, 2024 at 10:12 AM Heikki Linnakangas wrote:
> > Here's one goto-free attempt. It adds a local loop to where the
> > recursion was, so that if you have a chain of subtransactions that need
> > to be aborted in
On Wed, Feb 14, 2024 at 12:57 PM Kyotaro Horiguchi
wrote:
>
> A recent commit added the following message:
>
> > "wal_level" must be >= logical.
>
> The use of the term "logical" here is a bit confusing, as it's unclear
> whether it's meant to be a natural language word or a token. (I
> believe
On 12.02.24 15:16, Maiquel Grassi wrote:
>
> (v14)
>
>
v14 applies cleanly and the SSL info is now shown as previously
suggested. Here is a more comprehensive test:
$ /usr/local/postgres-dev/bin/psql -x "\
host=server.uni-muenster.de
hostaddr=172.19.42.1
user=jim dbname=postgres
On 2024-02-12 15:46, Bharath Rupireddy wrote:
Thanks for your comments.
On Mon, Jan 29, 2024 at 8:41 AM torikoshia
wrote:
On 2024-01-27 00:43, David G. Johnston wrote:
>> I'd like to have a new option "log", which skips soft errors and
>> logs
>> information that should have resulted in
On Wed, Feb 14, 2024 at 1:04 PM Kyotaro Horiguchi
wrote:
>
> Just after this, I found another inconsistency regarding quotation.
>
> > 'dbname' must be specified in "%s".
>
> The use of single quotes doesn't seem to comply with our standard.
>
Agreed, I think we have two choices here one is to
On Sat, Feb 10, 2024 at 2:23 AM Masahiko Sawada
wrote:
> On Fri, Feb 9, 2024 at 7:35 PM Ajin Cherian wrote:
> >
> >
> >
> > On Tue, Feb 6, 2024 at 5:06 PM Masahiko Sawada
> wrote:
> >>
> >>
> >> I've attached the new version patch set.
> >>
> >> Regards,
> >>
> >>
> >> --
> >> Masahiko Sawada
On Wednesday, February 14, 2024 6:05 PM Amit Kapila
wrote:
>
> On Wed, Feb 14, 2024 at 2:14 PM Amit Kapila wrote:
> >
> > On Wed, Feb 14, 2024 at 9:34 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > Here is V87 patch that adds test for the suggested cases.
> > >
> >
> > I have pushed this
Hi
On Mon, 12 Feb 2024 at 21:31, Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Tue, Feb 13, 2024 at 2:29 AM Daniel Gustafsson wrote:
> >
> > On that note though, we might want to consider just dropping it
> altogether in
> > v17 (while fixing the incorrect hint in
Hi,
Recently there have been few upgrade tap test failures in buildfarm
like in [1] & [2]. Analysing these failures requires the log files
that are getting generated from src/bin/pg_upgrade at the following
locations:
tmp_check/*/pgdata/pg_upgrade_output.d/*/*.txt - e.g.
On Wed, Feb 14, 2024 at 2:14 PM Amit Kapila wrote:
>
> On Wed, Feb 14, 2024 at 9:34 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Here is V87 patch that adds test for the suggested cases.
> >
>
> I have pushed this patch and it leads to a BF failure:
>
On Wed, Feb 14, 2024 at 1:04 PM Kyotaro Horiguchi
wrote:
>
> At Wed, 14 Feb 2024 16:26:52 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > > "wal_level" must be >= logical.
> ..
> > > wal_level must be set to "replica" or "logical" at server start.
> ..
> > I suggest making the quoting policy
On Wed, Feb 14, 2024 at 9:34 AM Zhijie Hou (Fujitsu)
wrote:
>
> Here is V87 patch that adds test for the suggested cases.
>
I have pushed this patch and it leads to a BF failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris=2024-02-14%2004%3A43%3A37
The test failures
Dear Euler,
>
If someone modifies data after promotion, fine; she has to deal with conflicts,
if any. IMO it is solved adding one or two sentences in the documentation.
>
OK. I could find issues, for now.
>
> >
> Regarding
> GUCs, almost all of them is PGC_POSTMASTER (so it cannot be modified
88 matches
Mail list logo
