On Tue, May 03, 2022 at 10:34:41AM +0200, Alvaro Herrera wrote:
> I remember Greg Mullane posted a tool that attempts to correct page CRC
> mismatches[1]. This new tool might be useful to feed healing attempts,
> too. (It's of course not in any way a *solution*, because the page
> might have
On Sun, May 22, 2022 at 05:10:01PM -0700, Andres Freund wrote:
> On 2022-05-10 16:39:11 +1200, Thomas Munro wrote:
>> Ok, in this version there's two levels of flag:
>> RecoveryConflictPending, so we do nothing if that's not set, and then
>> the loop over RecoveryConflictPendingReasons is moved
On 14.06.22 21:10, Jeremy Schneider wrote:
Does Unicode CDLR provide (or even track) versioning of collation or other i18n
functionality for individual locale settings?
Yes. You can see that in PostgreSQL as various pre-seeded ICU
collations having different versions.
At Wed, 15 Jun 2022 13:05:52 +0900 (JST), Kyotaro Horiguchi
wrote in
> By the way, I noticed that pg_upgrade complains wrong way when the
> specified binary path doesn't contain "postgres" file.
>
> $ pg_upgrade -b /tmp -B /tmp -d /tmp -D /tmp
>
> check for "/tmp/postgres" failed: not a
On Wed, Jun 15, 2022 at 11:33 AM XueJing Zhao wrote:
> Recently I work on grouping sets and I find the last param numGroups of
> create_groupingsets_path is not used.
>
> In create_groupingsets_path we use rollup->numGroups to do cost_agg.
>
Yes indeed. The param 'numGroups' was used originally
By the way, I noticed that pg_upgrade complains wrong way when the
specified binary path doesn't contain "postgres" file.
$ pg_upgrade -b /tmp -B /tmp -d /tmp -D /tmp
check for "/tmp/postgres" failed: not a regular file
Failure, exiting
I think it should be a quite common mistake to specify the
At Tue, 14 Jun 2022 14:57:40 -0400, Tom Lane wrote in
> Per the discussion at [1], pg_upgrade currently doesn't use
> common/logging.c's functions. Making it do so looks like a
> bigger lift than is justified, but there is one particular
> inconsistency that I think we ought to remove:
On Wed, Jun 15, 2022 at 5:44 AM Zheng Li wrote:
>
>
> While I agree that the deparser is needed to handle the potential
> syntax differences between
> the pub/sub, I think it's only relevant for the use cases where only a
> subset of tables in the database
> are replicated. For other use cases
Dear Postgres,
Recently I work on grouping sets and I find the last param numGroups of
create_groupingsets_path is not used.
In create_groupingsets_path we use rollup->numGroups to do cost_agg. So I
remove the param numGroups for
create_groupingsets_path.
I generate a diff.patch, which is sent
On Tue, Jun 14, 2022 8:57 PM Amit Kapila wrote:
>
> > v4-0002 looks good btw, except the bitpick about test comment similar
> > to my earlier comment regarding v5-0001:
> >
> > +# Change the column order of table on publisher
> >
> > I think it might be better to say something specific to
On Tue, Jun 14, 2022 at 9:57 PM Amit Kapila wrote:
> On Tue, Jun 14, 2022 at 1:02 PM Amit Langote wrote:
> > > +# Change the column order of table on publisher
> > I think it might be better to say something specific to describe the
> > test intent, like:
> >
> > Test that replication into
On Tue, Jun 14, 2022 at 7:21 PM Robert Haas wrote:
> On Tue, Jun 14, 2022 at 9:56 PM Peter Geoghegan wrote:
> > Technically we don't already do that today, with the 16-bit checksums
> > that are stored in PageHeaderData.pd_checksum. But we do something
> > equivalent: low-level tools can still
On Tue, Jun 14, 2022 at 10:21:16PM -0400, Robert Haas wrote:
> On Tue, Jun 14, 2022 at 9:56 PM Peter Geoghegan wrote:
>> Technically we don't already do that today, with the 16-bit checksums
>> that are stored in PageHeaderData.pd_checksum. But we do something
>> equivalent: low-level tools can
On Tue, Jun 14, 2022 at 7:17 PM Robert Haas wrote:
> But it seems
> absolutely clear that our goal ought to be to leak as little
> information as possible.
But at what cost?
Basically I think that this is giving up rather a lot. For example,
isn't it possible that we'd have corruption that
On Tue, Jun 14, 2022 at 9:56 PM Peter Geoghegan wrote:
> Technically we don't already do that today, with the 16-bit checksums
> that are stored in PageHeaderData.pd_checksum. But we do something
> equivalent: low-level tools can still infer that checksums must not be
> enabled on the page
On Tue, Jun 14, 2022 at 4:33 PM Peter Geoghegan wrote:
> I'm just making a general point. Why wouldn't we start out with the
> assumption that we use some pd_flags bit space for this stuff?
Well, the reason that wasn't my starting assumption is because I
didn't think of the idea.
> I'm
On Tue, Jun 14, 2022 at 1:32 PM Peter Geoghegan wrote:
> On Tue, Jun 14, 2022 at 1:22 PM Robert Haas wrote:
> > I still am not clear on precisely what you are proposing here. I do
> > agree that there is significant bit space available in pd_flags and
> > that consuming some of it wouldn't be
On Tue, Jun 14, 2022 at 3:57 PM Amit Kapila wrote:
>
> On Mon, Jun 13, 2022 at 8:29 AM Masahiko Sawada wrote:
> >
> > On Tue, Jun 7, 2022 at 9:32 PM Amit Kapila wrote:
> > >
> > > On Mon, May 30, 2022 at 11:13 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, May 25, 2022 at 12:11 PM
> On Jun 14, 2022, at 19:06, Thomas Munro wrote:
> One difference would be the effect if ICU ever ships a minor library
> version update that changes the reported collversion.
If I’m reading it correctly, ICU would not change collation in major versions,
as an explicit matter of policy
> Thanks for providing this idea.
>
> I looked at the string that is used for replication:
>
> """
> {ALTERTABLESTMT :relation {RANGEVAR :schemaname public :relname foo
> :inh true :relpersistence p :alias <> :location 12} :cmds ({ALTERTABLECMD
> :subtype 0 :name <> :num 0 :newowner <> :def
On Tue, Jun 14, 2022 at 05:08:28PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > OK, here's a more principled couple of patches. For config_data, if you
> > give multiple options it gives you back the list of values. If you don't
> > specify any, in scalar context it just gives you back all
On Tue, Jun 14, 2022 at 12:20:56PM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
>> The second changes the new GUCs TAP test to check against the installed
>> postgresql.conf.sample rather than the one in the original source
>> location. There are probably arguments both ways, but if we ever
On Wed, May 04, 2022 at 07:34:15AM -0700, David G. Johnston wrote:
> On Wed, May 4, 2022 at 7:29 AM Petr Vejsada wrote:
> > We solved it (in our case) dropping the aggregate before upgrade and
> > re-create in using new syntax in V14:
> >
> > but pg_upgrade shouldn't fail on this.
> >
> > I hope
On Wed, Jun 15, 2022 at 7:10 AM Jeremy Schneider
wrote:
> > On Jun 14, 2022, at 14:10, Peter Eisentraut
> > wrote:
> > Conversely, why are we looking at the ICU version instead of the collation
> > version. If we have recorded the collation as being version 1234, we need
> > to look through
On Tue, Jun 14, 2022 at 11:39 AM huangning...@yahoo.com <
huangning...@yahoo.com> wrote:
> Hi:
> I create a gin index for a bigint array. and then want to find the array
> which contains the key is start with special prefix. for example:
>
> row1: { 112, 345, 118}
> row2: { 356, 258, 358}
>
Andrew Dunstan writes:
> OK, here's a more principled couple of patches. For config_data, if you
> give multiple options it gives you back the list of values. If you don't
> specify any, in scalar context it just gives you back all of pg_config's
> output, but in array context it gives you a map,
On Tue, May 24, 2022 at 09:48:17PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-05-24 17:17:47 -0500, Justin Pryzby wrote:
> > Also, /O2 cuts ~3 minutes off the test time on cirrus, which seems worth it,
> > except that it omits frame pointers, which probably breaks debuggability.
>
> It likely
On Tue, Jun 14, 2022 at 1:22 PM Robert Haas wrote:
> I still am not clear on precisely what you are proposing here. I do
> agree that there is significant bit space available in pd_flags and
> that consuming some of it wouldn't be stupid, but that doesn't add up
> to a proposal. Maybe the
On Tue, Jun 14, 2022 at 3:25 PM Peter Geoghegan wrote:
> I am proposing that we not commit ourselves to relying on implicit
> information about what must be true for every page in the cluster.
> Just having a little additional page-header metadata (in pd_flags)
> would accomplish that much, and
On 2022-06-14 Tu 12:44, Álvaro Herrera wrote:
> The comment atop config_data still mentions $option, but after the patch
> that's no longer a name used in the function. (I have to admit that using @_
> in the body of the function was a little bit confusing to me at first. Did
> you do that in
Tom Lane wrote on 14.06.2022 15:43:
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= writes:
Please let me know what is the convention (procedure) of adding new
functions to pg_proc. Specifically how oid is allocated.
See
On Tue, Jun 14, 2022 at 12:13 PM Robert Haas wrote:
> Peter, unless I have missed something, this email is the very first
> one where you or anyone else have said anything at all about a PD_*
> bit. Even here, it's not very clear exactly what you are proposing.
> Therefore I have neither said
On Tue, Jun 14, 2022 at 3:01 PM Peter Geoghegan wrote:
> A tool like pg_filedump or a backup tool can easily afford this
> overhead. The only cost that TDE has to pay for this added flexibility
> is that it has to set one of the PD_* bits in a code path that is
> already bound to be very
> On Jun 14, 2022, at 14:10, Peter Eisentraut
> wrote:
>
> Conversely, why are we looking at the ICU version instead of the collation
> version. If we have recorded the collation as being version 1234, we need to
> look through the available ICU versions (assuming we can load multiple
On Tue, Jun 14, 2022 at 11:52 AM Robert Haas wrote:
> > Even within TDE, it might be okay to assume that it's a feature that
> > the user must commit to using for a whole cluster at initdb time. What
> > isn't okay is committing to that assumption now and forever, by
> > leaving the door open to
Per the discussion at [1], pg_upgrade currently doesn't use
common/logging.c's functions. Making it do so looks like a
bigger lift than is justified, but there is one particular
inconsistency that I think we ought to remove: pg_upgrade
expects (most) message strings to end in newlines, while
On Tue, Jun 14, 2022 at 2:23 PM Peter Geoghegan wrote:
> Maybe not -- it depends on the particulars of the code. For example,
> it might be okay for the B-Tree code to assume that B-Tree pages have
> a special area at a known fixed offset, determined at compile time. At
> the same time, it might
On 2022-06-14 20:47:59 +0200, Peter Eisentraut wrote:
> On 14.06.22 20:27, Andres Freund wrote:
> > One thing I'm not quite sure about: Why does the makefile need awareness of
> > the stop files, but Install.pm doesn't? I suspect currently the patch leads
> > to
> > stopwords not being installed
On 14.06.22 20:27, Andres Freund wrote:
One thing I'm not quite sure about: Why does the makefile need awareness of
the stop files, but Install.pm doesn't? I suspect currently the patch leads to
stopwords not being installed on windows anymore?
Install.pm contains this elsewhere:
Hi,
On 2022-06-08 14:33:16 +0200, Peter Eisentraut wrote:
> Attached is a patch the finishes up the work to move the snowball SQL script
> generation into a separate script.
That looks good, merged. I did split the commit, because there's not yet a
meson.build "at the time" of the prereq:
On Tue, Jun 14, 2022 at 11:14 AM Robert Haas wrote:
> We can have anything we want here, but we can't have everything we
> want at the same time. There are irreducible engineering trade-offs
> here. If all pages in a given cluster are the same, backends can
> compute the values of things that are
Hi,
On 2022-06-08 08:27:06 +0200, Peter Eisentraut wrote:
> I looked at some of the "prereq" patches again to see what state they are
> in:
>
> commit 351a12f48e395b31cce4aca239b934174b36ea9d
> Author: Andres Freund
> Date: Wed Apr 20 22:46:54 2022
>
> prereq: deal with \ paths in
On Tue, Jun 14, 2022 at 1:43 PM Peter Geoghegan wrote:
> There is no doubt that it's not worth breaking on-disk compatibility
> just for pg_filedump. The important principle here is that
> high-context page formats are bad, and should be avoided whenever
> possible.
I agree.
> Why isn't it
On Tue, Jun 14, 2022 at 10:43 AM Robert Haas wrote:
> Hmm, but on the other hand, if you imagine a scenario in which the
> "storage system extra blob" is actually a nonce for TDE, you need to
> be able to find it before you've decrypted the rest of the page. If
> pd_checksum gives you the offset
On 11.06.22 05:35, Peter Geoghegan wrote:
Do we even need to store a version for indexes most of the time if
we're versioning ICU itself, as part of the "time travelling
collations" design? For that matter, do we even need to version
collations directly anymore?
Conversely, why are we looking
On 13.06.22 23:32, Thomas Munro wrote:
Hrmph, I changed my CC to "ccache gcc-mp-11" (what MacPorts calls GCC
11), and I still can't reproduce the problem. I still get "(from
executable)". In your original quote you showed "gcc", not "gcc-11",
which (assuming it is found as /usr/bin/gcc) is
On Tue, Jun 14, 2022 at 9:26 AM Tom Lane wrote:
> It's been some years since I had much to do with pg_filedump, but
> my recollection is that the size of the special space is only one
> part of its heuristics, because there already *are* collisions.
Right, there are collisions even today. The
On Tue, Jun 14, 2022 at 11:08 AM Matthias van de Meent
wrote:
> I agree with the premise of one only needing one such blob on the
> page, yet I don't think that putting it on the exact end of the page
> is the best option.
>
> PageGetSpecialPointer is much simpler when you can rely on the
>
On Wed, Mar 30, 2022 at 01:16:37PM -0400, Greg Stark wrote:
> On Mon, 28 Feb 2022 at 17:50, Tom Lane wrote:
> >
> > Chapman Flack writes:
> > > In the current state of affairs, what's considered the ur-source of that
> > > information?
> >
> > The source code for the type's send/receive
On 2022-06-14 Tu 12:20, Tom Lane wrote:
> Andrew Dunstan writes:
>> The first makes the argument for $node->config_data() optional. If it's
>> not supplied, pg_config is called without an argument and the whole
>> result is returned. Currently, if you try that you get back a nasty and
>>
The comment atop config_data still mentions $option, but after the patch that's
no longer a name used in the function. (I have to admit that using @_ in the
body of the function was a little bit confusing to me at first. Did you do that
in order to allow multiple options to be passed?)
Also:
Peter Geoghegan writes:
> On Tue, Jun 14, 2022 at 8:48 AM Robert Haas wrote:
>> However, pg_filedump and I think also some code internal
>> to PostgreSQL try to figure out what kind of page we've got by looking
>> at the *size* of the special space. It's only good luck that we
>> haven't had a
Andrew Dunstan writes:
> The first makes the argument for $node->config_data() optional. If it's
> not supplied, pg_config is called without an argument and the whole
> result is returned. Currently, if you try that you get back a nasty and
> cryptic error.
No opinion about whether that's
On Tue, Jun 14, 2022 at 8:48 AM Robert Haas wrote:
> On Mon, Jun 13, 2022 at 6:26 PM Peter Geoghegan wrote:
> > Anyway, I can see how it would be useful to be able to know the offset
> > of a nonce or of a hash digest on any given page, without access to a
> > running server. But why shouldn't
Here's a couple of small patches I came up with while doing some related
work on TAP tests.
The first makes the argument for $node->config_data() optional. If it's
not supplied, pg_config is called without an argument and the whole
result is returned. Currently, if you try that you get back a
On Mon, Jun 13, 2022 at 6:26 PM Peter Geoghegan wrote:
> Anyway, I can see how it would be useful to be able to know the offset
> of a nonce or of a hash digest on any given page, without access to a
> running server. But why shouldn't that be possible with other designs,
> including designs
On Tue, 14 Jun 2022 at 14:56, Robert Haas wrote:
>
> On Mon, Jun 13, 2022 at 5:14 PM Matthias van de Meent
> wrote:
> > It's not that I disagree with (or dislike the idea of) increasing the
> > resilience of checksums, I just want to be very careful that we don't
> > trade (potentially
On Tue, May 24, 2022 at 08:19:27PM -0500, Justin Pryzby wrote:
> On Wed, May 25, 2022 at 01:08:12AM +, Shinoda, Noriyoshi (PN Japan FSIP)
> wrote:
> > Hi hackers,
> > Thanks to all the developers. The attached patch updates the manual for the
> > pg_stats_ext and pg_stats_ext_exprs view.
> >
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= writes:
> Please let me know what is the convention (procedure) of adding new
> functions to pg_proc. Specifically how oid is allocated.
See
https://www.postgresql.org/docs/devel/system-catalog-initial-data.html#SYSTEM-CATALOG-OID-ASSIGNMENT
(you should
Dear colleagues,
Please let me know what is the convention (procedure) of adding new
functions to pg_proc. Specifically how oid is allocated.
This will allow me to continue working on the patch.
I have to extend the timestamptz_pl_interval function, which is in fact
an addition operator. But
On Tue, Jun 14, 2022 at 1:02 PM Amit Langote wrote:
>
> On Tue, Jun 14, 2022 at 3:31 PM Amit Langote wrote:
> > On Mon, Jun 13, 2022 at 6:14 PM Amit Kapila wrote:
> > > I think we can do that way as well but do you see any benefit in it?
> > > The way I am suggesting will avoid the effort of
On Mon, Jun 13, 2022 at 5:14 PM Matthias van de Meent
wrote:
> It's not that I disagree with (or dislike the idea of) increasing the
> resilience of checksums, I just want to be very careful that we don't
> trade (potentially significant) runtime performance for features
> people might not use.
On 2022-06-13 Mo 22:50, Michael Paquier wrote:
> On Fri, Jun 10, 2022 at 05:45:11PM -0400, Andrew Dunstan wrote:
>> The module is already a noop if there's a TAP test for pg_upgrade. So I
>> don't understand the point of the PR at all.
> Oh. I thought that the old path was still taken as long
On Fri, Jun 10, 2022 at 2:09 PM Peter Smith wrote:
>
> Below are some review comments for the patch v18-0004
>
> ==
>
> 1. Commit message
>
> Document the steps for the following:
> a) Create a two-node bidirectional replication when there is no data in both
> the
> nodes.
> b) Adding a new
Hi Kuroda san,
> I think even if LRG is implemented as contrib modules or any extensions,
> it will deeply depend on the subscription option "origin" proposed in [1].
> So LRG cannot be used for older version, only PG16 or later.
Sorry, I misunderstood.
I understand now.
Regards,
Ryohei
Dear Takahashi-san,
Thanks for giving feedbacks!
> > I don't know if it requires the kind of code you are thinking but I
> > agree that it is worth considering implementing it as an extension.
>
> I think the other advantage to implement as an extension is that users could
> install the
On Wed, Jun 1, 2022, at 5:28 PM, Alvaro Herrera wrote:
> Re-reading the modified paragraph, I propose "see X for a thorough
> explanation on the behavior of MERGE under concurrency". However, in
> the proposed patch the link goes to Chapter 13 "Concurrency Control",
> and the explanation that we
On Mon, Jun 13, 2022 at 04:46:46PM +0900, Michael Paquier wrote:
>
> Some nits. I would suggest to reword this error message, like "cannot
> use \"match\" with HEADER in COPY TO".
Agreed.
> There is no need for the extra
> comment, and the error code should be ERRCODE_FEATURE_NOT_SUPPORTED.
On Tue, Jun 14, 2022 2:18 PM Amit Langote wrote:
>
> On Mon, Jun 13, 2022 at 9:26 PM Amit Kapila
> wrote:
> > On Mon, Jun 13, 2022 at 1:03 PM houzj.f...@fujitsu.com
> > wrote:
> > > On Monday, June 13, 2022 1:53 PM Amit Kapila
> wrote:
> > > I have separated out the bug-fix for the
On Mon, Jun 13, 2022 at 11:25 PM Robert Haas wrote:
>
> On Sun, Apr 17, 2022 at 11:22 PM Noah Misch wrote:
> > > Yes, but it could be false positives in some cases. For instance, the
> > > column {oid, bool, XLogRecPtr} should be okay on ALIGNOF_DOUBLE == 4
> > > and 8 platforms but the new test
On Fri, Jun 10, 2022 at 8:42 PM Hsu, John wrote:
>
> Hi,
>
> Why couldn't you terminate the active_pid associated with the slot you
> want to drop if it's active prior to dropping?
In that case, the slot becomes active immediately after killing the
old walsender because the standby/subscriber
On Thu, Jun 09, 2022 at 11:55:11PM +0100, Dagfinn Ilmari Mannsåker wrote:
> Done (and more tests added), v3 attached.
One thing I am wondering is if we'd better mention errdetail_params()
at the top of the initial check done in ExplainQueryParameters().
That's a minor issue, though.
+sub
Hi:I create a gin index for a bigint array. and then want to find the array
which contains the key is start with special prefix. for example:
row1: { 112, 345, 118}row2: { 356, 258, 358}row3: { 116, 358, 369}
I want find the key start "11",so the row1 and row3 will be return.of course it
must
PSA v2 of the patch, based on all feedback received.
~~~
Main differences from v1:
* Rewording and more explanatory text.
* The examples were moved to the "Subscription" [1] page and also
extended to show some normal replication and row filter examples, from
[Amit].
* Added some text to
On Tue, Jun 14, 2022 at 3:31 PM Amit Langote wrote:
> On Mon, Jun 13, 2022 at 6:14 PM Amit Kapila wrote:
> > I think we can do that way as well but do you see any benefit in it?
> > The way I am suggesting will avoid the effort of updating the remote
> > rel copy till we try to access that
On Mon, Jun 13, 2022 at 8:29 AM Masahiko Sawada wrote:
>
> On Tue, Jun 7, 2022 at 9:32 PM Amit Kapila wrote:
> >
> > On Mon, May 30, 2022 at 11:13 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, May 25, 2022 at 12:11 PM Masahiko Sawada
> > > wrote:
> > > >
> > >
> > >
On Mon, Jun 13, 2022 at 6:14 PM Amit Kapila wrote:
> On Mon, Jun 13, 2022 at 2:20 PM Amit Langote wrote:
> > On Sat, Jun 11, 2022 at 10:36 AM Amit Kapila
> > wrote:
> > > On Fri, Jun 10, 2022 at 2:26 PM Amit Langote
> > > wrote:
> > > >
> > > > +logicalrep_partmap_invalidate
> > > >
> > > >
On Mon, Jun 13, 2022 at 9:26 PM Amit Kapila wrote:
> On Mon, Jun 13, 2022 at 1:03 PM houzj.f...@fujitsu.com
> wrote:
> > On Monday, June 13, 2022 1:53 PM Amit Kapila
> > wrote:
> > I have separated out the bug-fix for the subscriber-side.
> > And fix the typo and function name.
> > Attach the
78 matches
Mail list logo
