On Tue, 18 Apr 2023 at 09:21, Melanie Plageman
wrote:
> Are we still thinking that reordering the VACUUM (and ANALYZE) options
> makes sense. And, if so, should it be alphabetical within parameter
> category? That is, all actual parameters (e.g. FULL and FREEZE) are
> alphabetically organized
Over on [1], Peter mentions that we might want to consider putting the
VACUUM options into some order that's better than the apparent random
order that they're currently in.
VACUUM is certainly one command that's grown a fairly good number of
options over the years and it appears we've not given
On Mon, Apr 17, 2023 at 07:57:58PM -0700, sirisha chamarthi wrote:
> On Fri, Apr 14, 2023 at 1:01 AM Kyotaro Horiguchi
> wrote:
>> So, I personally think it should be written like this: "The default
>> size is 80MB. However, if you have changed the WAL segment size from
>> the default of 16MB, it
On Tue, Apr 18, 2023 at 09:51:30AM +0800, Legs Mansion wrote:
> Recently, I ran into a problem, InvokeObjectPostAlterHook was
> implemented for sepgsql, sepgsql use it to determine whether to
> check permissions during certain operations. But
> InvokeObjectPostAlterHook doesn't handle all of the
On Tue, 18 Apr 2023 at 05:01, Corey Huinker wrote:
> I'm ok with the wording as-is, but perhaps we can phrase it as "distinct" vs
> "not equal", thus leaning into the syntax a bit:
>
> By default, null values in a unique column are considered distinct, allowing
> multiple nulls in the column.
>
Attached patch removes xl_heap_lock_updated/XLOG_HEAP2_LOCK_UPDATED,
which allows us to throw out about a hundred lines of duplicative
(though hairy) code, net total. The patch also reclaims some Heap2
info bit space, which seems quite useful.
The patch teaches heap_lock_updated_tuple_rec() to
On Thu, 13 Apr 2023 at 02:40, David Gilman wrote:
> The SQL Language part of the docs has a brief page on unique indexes.
> It doesn't mention the new NULLS NOT DISTINCT functionality on unique
> indexes and this is a good place to mention it, as it already warns
> the user about the old/default
Hi,
On Fri, Apr 14, 2023 at 1:01 AM Kyotaro Horiguchi
wrote:
> At Thu, 13 Apr 2023 12:01:04 -0700, sirisha chamarthi <
> sirichamarth...@gmail.com> wrote in
> > The documentation [1] says max_wal_size and min_wal_size defaults are 1GB
> > and 80 MB respectively. However, these are configured
On Mon, Apr 17, 2023 at 05:00:59PM +0900, Michael Paquier wrote:
> This thinko has been introduced by 3b7ab43, so this needs to go down
> to v11. I'll see to that.
So done. mylodon is feeling unhappy about that, because this has a
C99 declaration:
Amin writes:
> I made sure EXPLAIN returns CustomScan for all scans in the query. But
> still, ExecCustomScan is only called once while the rest of the functions
> are called for each scan separately. Is this expected behavior? How to work
> around this?
[shrug...] There's some bug in your code,
David Rowley writes:
> On Tue, 18 Apr 2023 at 06:00, Alexander Lakhin wrote:
>> Also, maybe OID_MAX should be removed from src/include/postgres_ext.h as
>> it's unused since eb8312a22.
> I didn't touch this. It seems like it could be useful for extensions
> and client apps even if it's not
On Tue, 18 Apr 2023 at 10:10, Justin Pryzby wrote:
> > - * USER SET values are appliciable only for PGC_USERSET
> > parameters. We
> > + * USER SET values are applicable only for PGC_USERSET
> > parameters. We
> >* use InvalidOid as role in order to
Recently, I ran into a problem, InvokeObjectPostAlterHook was implemented for
sepgsql,
sepgsql use it to determine whether to check permissions during certain
operations.
But InvokeObjectPostAlterHook doesn't handle all of the alter's behavior, at
least the table is not controlled.e.g., ALTER
Dear Julien,
I found a cfbot failure on macOS [1]. According to the log,
"SELECT count(*) FROM t2" was executed before synchronization was done.
```
[09:24:21.018](0.132s) not ok 18 - Table t2 should now have 3 rows on the new
subscriber
```
With the patch present, wait_for_catchup() is
On Tue, 18 Apr 2023 at 06:00, Alexander Lakhin wrote:
> Please consider fixing the following unique words/identifiers introduced in
> v16:
Thanks, I've pushed all of these apart from the following 2.
> 45. tar_set_error -- remove (obsolete since ebfb814f7)
> 46. test_tranche_name -- remove
Hi Tom,
I made sure EXPLAIN returns CustomScan for all scans in the query. But
still, ExecCustomScan is only called once while the rest of the functions
are called for each scan separately. Is this expected behavior? How to work
around this?
Thank you!
On Mon, Apr 17, 2023 at 3:45 PM Tom Lane
On Mon, Apr 17, 2023 at 03:40:14PM -0700, Peter Geoghegan wrote:
> On Mon, Apr 17, 2023 at 2:48 PM Tom Lane wrote:
>> +1. I wonder if we should go further and get rid of TRUST_STRXFRM
>> and the not-so-trivial amount of code around it (pg_strxfrm_enabled
>> etc). Carrying that indefinitely in
Amin writes:
> To simplify: Can CustomScan scan multiple relations in the same query or it
> will always be assigned to one or zero relations?
There's barely any code in the core planner that is specific to custom
scans. Almost certainly this misbehavior is the fault of your
On Mon, Apr 17, 2023 at 2:48 PM Tom Lane wrote:
> +1. I wonder if we should go further and get rid of TRUST_STRXFRM
> and the not-so-trivial amount of code around it (pg_strxfrm_enabled
> etc). Carrying that indefinitely in the probably-vain hope that
> the libraries will become trustworthy
To simplify: Can CustomScan scan multiple relations in the same query or it
will always be assigned to one or zero relations?
On Fri, Apr 14, 2023 at 4:33 PM Amin wrote:
> Hi there,
>
> In my implementation of CustomScan, when I have a query that scans
> multiple tables (select c from
On Mon, Apr 17, 2023 at 09:00:00PM +0300, Alexander Lakhin wrote:
> Hello hackers,
>
> Please consider fixing the following unique words/identifiers introduced in
> v16:
Well done.
Note that your patches are overlapping:
3 --- a/src/backend/utils/misc/guc.c
2 ---
Justin Pryzby writes:
> On Mon, Apr 17, 2023 at 01:50:30PM -0400, Tom Lane wrote:
>> Bingo: bisecting shows the failure started at
> Just curious: what "test" did you use to bisect with ?
The test case I used looked like
start postmaster with -c wal_level=minimal -c max_wal_senders=0
make
On Mon, Apr 17, 2023 at 02:21:41PM -0700, Nathan Bossart wrote:
> AFAICT this is committed, but the commitfest entry [0] is still set to
> "needs review." Can it be closed now?
Yes, done. Thanks.
--
Michael
signature.asc
Description: PGP signature
On Mon, Apr 17, 2023 at 01:50:30PM -0400, Tom Lane wrote:
> I wrote:
> > Yeah, I just came to the same conclusion. One thing I don't understand
> > yet: log_newpage_range is old (it looks like this back to v12), and
> > that Assert is older, so why doesn't this reproduce further back?
> > Maybe
Nathan Bossart writes:
> On Thu, Dec 15, 2022 at 03:22:59PM +1300, Thomas Munro wrote:
>> While studying Jeff's new crop of collation patches I noticed in
>> passing that check_strxfrm_bug() must surely by now be unnecessary.
>> The buffer overrun bugs were fixed a decade ago, and the relevant
>>
On Tue, Apr 18, 2023 at 4:06 AM Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Apr 15, 2023 at 2:19 PM Tom Lane wrote:
> >> I get the impression that we are going to need an actual runtime
> >> test if we want to defend against this. Not entirely convinced
> >> it's worth the trouble. Who,
On Wed, 5 Apr 2023 at 13:42, Andres Freund wrote:
>
> Somehow it doesn't feel right to use vac_update_relstats() in
> heapam_handler.c.
>
> I also don't like that your patch references
> heapam_relation_nontransactional_truncate in AddNewRelationTuple() - we
> shouldn't add more comments
On Fri, Apr 14, 2023 at 07:32:13AM +0900, Michael Paquier wrote:
> On Thu, Apr 13, 2023 at 11:58:51AM +0200, Alvaro Herrera wrote:
>> I agree with the downthread votes to clean this up now rather than
>> waiting. Also, you're adding exactly zero lines of new code, so I don't
>> think feature
On Sat, Apr 15, 2023 at 12:59:52PM +1200, David Rowley wrote:
> On Fri, 14 Apr 2023 at 19:20, Peter Eisentraut
> wrote:
> >
> > I came across these new options and had a little bit of trouble figuring
> > them out from the documentation. Maybe this could be polished a bit.
> >
> > vacuumdb
On Thu, Dec 15, 2022 at 03:22:59PM +1300, Thomas Munro wrote:
> While studying Jeff's new crop of collation patches I noticed in
> passing that check_strxfrm_bug() must surely by now be unnecessary.
> The buffer overrun bugs were fixed a decade ago, and the relevant
> systems are way out of
Here is a new patch set. I've split it into two patches: one for the
64-bit functions, and one for the 32-bit functions. I've also added tests
for pg_lfind64/pg_lfind64_idx and deduplicated the code a bit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From
Robert Haas writes:
> On Mon, Apr 17, 2023 at 1:55 PM Jeff Davis wrote:
>> Maybe we should have a single new message type 'x' to indicate a
>> message for a protocol extension, and then have a sub-message-type? It
>> might make error handling better for unexpected messages.
> ...
> The point of
On Mon, Apr 17, 2023 at 1:55 PM Jeff Davis wrote:
> It involves introducing new message types which I didn't really
> consider. We might want to be careful about how many kinds of messages
> we introduce so that the one-letter codes are still managable. I've
> been frustrated in the past that we
Jeff Davis writes:
> Is now a reasonable time to check it in and see what breaks? It looks
> like there are quite a few buildfarm members that specify neither --
> with-icu nor --without-icu.
I see you just pinged buildfarm-members again, so I'd think it's
polite to give people 24 hours or so to
Andres Freund writes:
> On 2023-04-17 13:50:30 -0400, Tom Lane wrote:
>> So previously, log_newpage_range could only have failed in very
>> unlikely circumstances, whereas now it's not hard to hit when
>> committing a table creation. I wonder what other bugs may be
>> lurking.
> Oh,
On Mon, 2023-04-17 at 08:23 -0500, Justin Pryzby wrote:
> > I don't object to this patch. I suggest waiting until next week to
> > commit
> > it and then see what happens. It's easy to revert if it goes
> > terribly.
>
> Is this still being considered for v16 ?
Yes, unless someone raises a
Hi,
On 2023-04-17 13:50:30 -0400, Tom Lane wrote:
> I wrote:
> > Yeah, I just came to the same conclusion. One thing I don't understand
> > yet: log_newpage_range is old (it looks like this back to v12), and
> > that Assert is older, so why doesn't this reproduce further back?
> > Maybe the
Hello hackers,
Please consider fixing the following unique words/identifiers introduced in v16:
1. addresess -> addresses
2. adminstrator -> administrator // the same typo found in src/backend/po/id.po, but perhaps it should be fixed via
pgsql-translators
3. appeneded -> appended
4.
On Mon, 2023-04-17 at 12:17 -0400, Robert Haas wrote:
> In the case at hand, it seems like the problem could easily be solved
> by allowing the property to be changed after connection startup.
> Instead of using the protocol extension mechanism to negotiate a
> specific value for the property, we
Hi,
On 2023-04-17 12:13:41 -0400, Tom Lane wrote:
> Matthias van de Meent writes:
> > Looking at log_newpage_range, it seems like we're always trying to log
> > a record if startblk < endblk; but don't register the PageIsNew()
> > buffers in the range. That means that if the last buffers in the
I wrote:
> Yeah, I just came to the same conclusion. One thing I don't understand
> yet: log_newpage_range is old (it looks like this back to v12), and
> that Assert is older, so why doesn't this reproduce further back?
> Maybe the state where all the pages are new didn't happen before?
Bingo:
On Wed, Apr 12, 2023 at 10:40 AM David Gilman
wrote:
> The SQL Language part of the docs has a brief page on unique indexes.
> It doesn't mention the new NULLS NOT DISTINCT functionality on unique
> indexes and this is a good place to mention it, as it already warns
> the user about the
On Fri, Apr 14, 2023 at 3:36 PM Daniel Gustafsson wrote:
> This "error: Success" error has been reported to the list numerous times as
> misleading, and I'd love to make progress on improving error reporting during
> the v17 cycle.
Agreed!
> The attached checks for the specific known error, and
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b8856e61d775bc248a292163facc0b227abdde97 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 23 Feb 2023 14:27:48 -0800
Subject: [PATCH v15 1/7] Move extra code out of the Pre/PostRestoreCommand()
block.
If
On Wed, Mar 29, 2023 at 12:04 PM Jeff Davis wrote:
> I'm starting to agree that the awkwardness around connection poolers is
> a problem. If that's the case, I'm wondering if the protocol extensions
> will ever be useful.
In the case at hand, it seems like the problem could easily be solved
by
Matthias van de Meent writes:
> Looking at log_newpage_range, it seems like we're always trying to log
> a record if startblk < endblk; but don't register the PageIsNew()
> buffers in the range. That means that if the last buffers in the range
> are new, this can result in no buffers being
Robert Haas writes:
> On Sat, Apr 15, 2023 at 2:19 PM Tom Lane wrote:
>> I get the impression that we are going to need an actual runtime
>> test if we want to defend against this. Not entirely convinced
>> it's worth the trouble. Who, other than our deliberately rear-guard
>> buildfarm
I wrote:
> Hmm. I wonder if log_newpages() is confused here:
> XLogEnsureRecordSpace(XLR_MAX_BLOCK_ID - 1, 0);
Oh, no, it's simpler than that: log_newpage_range is trying to
log zero page images, and ReserveXLogInsertLocation doesn't
like that because every WAL record should contain some
On Mon, 17 Apr 2023 at 17:53, Justin Pryzby wrote:
>
> I hit this assertion while pg_restoring data into a v16 instance.
> postgresql16-server-16-alpha_20230417_PGDG.rhel7.x86_64
>
> wal_level=minimal and pg_dump --single-transaction both seem to be
> required to hit the issue.
>
> $
On Sat, Apr 15, 2023 at 2:19 PM Tom Lane wrote:
> I get the impression that we are going to need an actual runtime
> test if we want to defend against this. Not entirely convinced
> it's worth the trouble. Who, other than our deliberately rear-guard
> buildfarm animals, is going to be building
Justin Pryzby writes:
> I hit this assertion while pg_restoring data into a v16 instance.
> postgresql16-server-16-alpha_20230417_PGDG.rhel7.x86_64
> wal_level=minimal and pg_dump --single-transaction both seem to be
> required to hit the issue.
Hmm. I wonder if log_newpages() is confused
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm guessing it's not really an issue but it does make changing
> > configure a bit annoying on my Ubuntu 22.04, when I run autoconf2.69, I
> > end up with this additional hunk as changed from what our configure
> >
Richard Guo writes:
> So now it seems that the breakage of regression tests is more severe
> than being cosmetic. I wonder if we need to update the comments to
> indicate the potential wrong results issue if we move the initPlans to
> the Gather node.
I wondered about that too, but how come
I hit this assertion while pg_restoring data into a v16 instance.
postgresql16-server-16-alpha_20230417_PGDG.rhel7.x86_64
wal_level=minimal and pg_dump --single-transaction both seem to be
required to hit the issue.
$ /usr/pgsql-16/bin/postgres -D ./pg16test -c maintenance_work_mem=1GB -c
Stephen Frost writes:
> I'm guessing it's not really an issue but it does make changing
> configure a bit annoying on my Ubuntu 22.04, when I run autoconf2.69, I
> end up with this additional hunk as changed from what our configure
> currently has.
Not surprising. Thanks to autoconf's long
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > Done that way.
> >
> > Looks like you neglected to update the configure script proper?
>
> Pah, indeed. Will fix. Sorry about that.
Fixed.
I'm guessing it's not
Hi,
On 4/14/23 3:22 PM, Drouvot, Bertrand wrote:
Now that the "Minimal logical decoding on standby" patch series (mentioned
up-thread) has been
committed, I think we can resume working on this one ("Synchronizing slots from
primary to standby").
I'll work on a rebase and share it once done
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Done that way.
>
> Looks like you neglected to update the configure script proper?
Pah, indeed. Will fix. Sorry about that.
Thanks,
Stephen
signature.asc
Description: PGP signature
Stephen Frost writes:
> Done that way.
Looks like you neglected to update the configure script proper?
regards, tom lane
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > How about the attached which just switches from testing for
> > gss_init_sec_context to testing for gss_store_cred_into?
>
> WFM.
Done that way.
Thanks!
Stephen
signature.asc
Description: PGP signature
On Fri, Apr 7, 2023 at 6:55 PM John Naylor wrote:
>
> On Thu, Feb 16, 2023 at 11:44 PM Andres Freund wrote:
> >
> > We really ought to replace the tid bitmap used for bitmap heap scans. The
> > hashtable we use is a pretty awful data structure for it. And that's not
> > filled in-order, for
Stephen Frost writes:
> How about the attached which just switches from testing for
> gss_init_sec_context to testing for gss_store_cred_into?
WFM.
regards, tom lane
On Sun, Apr 16, 2023 at 1:20 AM Miroslav Bendik
wrote:
> Postgres allows incremental sort only for ordered indexes. Function
> build_index_paths dont build partial order paths for access methods
> with order support. My patch adds support for incremental ordering
> with access method.
I think
On Wed, Apr 05, 2023 at 09:33:25AM +0200, Peter Eisentraut wrote:
> On 16.03.23 14:52, Peter Eisentraut wrote:
> > On 09.03.23 20:14, Jeff Davis wrote:
> > > > Let's come back to that after dealing with the other two.
> > >
> > > Leaving 0001 open for now.
> >
> > I suspect making a change like
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Pushed, thanks again to everyone.
> > I'll monitor the buildfarm and assuming there isn't anything unexpected
> > then I'll mark the open item as resolved now.
>
> The Debian 7 (Wheezy) members of the buildfarm
Here are some more review comments for the patch 0002-2023_04_07-2
Note: This is a WIP review (part 2); the comments in this post are
only for the commit message and the PG docs
==
Commit message
1.
It's not obvious that those "-" (like "- For DROP object:") represent
major sections of this
On Wednesday, April 12, 2023 7:24 PM Amit Kapila
wrote:
>
> On Fri, Apr 7, 2023 at 8:52 AM houzj.f...@fujitsu.com
> wrote:
> >
>
> Few comments on 0001
Thanks for the comments.
> ===
> 1.
> + ConstrObjDomain,
> + ConstrObjForeignTable
> +} ConstraintObjType;
>
> These both
On Sat, 15 Apr 2023 at 06:38, vignesh C wrote:
>
> On Fri, 14 Apr 2023 at 13:06, vignesh C wrote:
> >
> > Few comments:
Few more comments:
1) since missing_ok is passed as false, if there is an error the error
will be handled in find_string_in_jsonbcontainer, "missing operator
name" handling
Hi,
On 4/17/23 11:55 AM, Alvaro Herrera wrote:
On 2023-Apr-12, Drouvot, Bertrand wrote:
I'm not sure if adding those 2 tests should be considered as an open
item. I can add this open item if we think that makes sense. I'd be
happy to do so but it looks like I don't have the privileges to edit
On 2023-Apr-12, Drouvot, Bertrand wrote:
> I'm not sure if adding those 2 tests should be considered as an open
> item. I can add this open item if we think that makes sense. I'd be
> happy to do so but it looks like I don't have the privileges to edit
>
> Le 17 avr. 2023 à 03:25, Tom Lane a écrit :
>
> You can do this:
>
> $ psql -d "postgres://localhost/test"
>
> but that's not the same thing as reinterpreting the dbname field
> of what we have already determined to be a connection string.
>
Yes, I know see the difference, I got confused
(sorry for the wrong subject..)
At Mon, 17 Apr 2023 17:00:59 +0900, Michael Paquier wrote
in
> On Mon, Apr 10, 2023 at 05:35:00PM +0900, Kyotaro Horiguchi wrote:
> > This results in overwriting str[-1], the last byte of the preceding
> > numeric in this case, with 0x00, representing the digit
At Mon, 17 Apr 2023 15:21:02 +0900, Etsuro Fujita
wrote in
> > >> Although the primary message is the same, the supplemental message pro=
> vides additional context that can help distinguish which function is report=
> ing the message.
> > >
> > > If the user is familiar with the
Hi, here are some review comments for the patch 0002-2023_04_07-2
Note: This is a WIP review. The patch is quite large and I have
managed to only look at ~50% of it. I will continue reviewing this
same 0002-2023_04_07-2 and send more comments at a later time.
Meanwhile, here are the review
On Mon, Apr 10, 2023 at 05:35:00PM +0900, Kyotaro Horiguchi wrote:
> This results in overwriting str[-1], the last byte of the preceding
> numeric in this case, with 0x00, representing the digit '0'. When
> callers of ecpg_get_data() explicitly pass zero as varcharsize, they
> provide storage that
Hi,
31.03.2023 17:00, Alexander Lakhin wrote:
31.03.2023 15:55, Tom Lane wrote:
See also the thread about bug #16329 [1]. Alexander promised to look
into improving the test coverage in this area, maybe he can keep an
eye on the WAL logic coverage too.
Yes, I'm going to analyze that area too.
On Mon, Apr 17, 2023 at 10:57 AM Richard Guo wrote:
> The initPlan has been moved from the Result node to the Gather node. As
> a result, when doing tuple projection for the Result node, we'd get a
> ParamExecData entry with NULL execPlan. So the initPlan does not get
> chance to be executed.
On Fri, Apr 14, 2023 at 11:28 PM Fujii Masao
wrote:
> On 2023/04/14 18:59, Etsuro Fujita wrote:
> >> The primary message basically should avoid reference to implementation
> >> details such as specific structure names like PGcancel, shouldn't it, as
> >> per the error message style guide?
> >
>
78 matches
Mail list logo
