On Tue, Jun 14, 2022 3:36 PM Peter Smith wrote:
>
> 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 replic
On 14.06.22 05:34, Peter Smith wrote:
FWIW, I stumbled on this obscure possible typo (?) in src/pl/plperl/po/ro.po:
~~~
#: plperl.c:788
msgid "while parsing Perl initialization"
msgstr "în timpul parsing inițializării Perl"
#: plperl.c:793
msgid "while running Perl initialization"
msgstr "în ti
On 13.06.22 20:20, Robert Haas wrote:
If the user wants 16-bit checksums, the feature we've already got
seems good enough -- and, as you say, it doesn't use any extra disk
space. This proposal is just about making people happy if they want a
bigger checksum.
It's hard to get any definite inform
PSA a test script that demonstrates all the documented steps for
setting up n-way bidirectional replication. These steps are the same
as those documented [1] on the new page "Bidirectional logical
replication".
This script works using the current latest v20* patch set. Each of the
sections of 31.1
On 14.06.22 11:13, Julien Rouhaud wrote:
There is no need for the extra
comment, and the error code should be ERRCODE_FEATURE_NOT_SUPPORTED.
Is there any rule for what error code should be used?
Maybe that's just me but I understand "not supported" as "this makes sense, but
this is currently
On 13.06.22 20:00, Robert Haas wrote:
I don't think this creates any more of a conflict than we've already
got. In fact, I'd go so far as to say it resolves a problem that we
currently have. As far as I can see, we are stuck with a situation
where we have to support both the INHERIT behavior and
Hi all!
The motivation behind this is that incrementally building up a GiST
index for certain input data can create a terrible tree structure.
Furthermore, exclusion constraints are commonly implemented using GiST
indices and for that use case, data is mostly orderable.
By sorting the data be
Two fixes (bad comment and fixed Latin-ASCII.xml).
Michael Paquier wrote on 17.05.2022 09:11:
On Thu, May 05, 2022 at 09:44:15PM +0200, Przemysław Sztoch wrote:
Tom, I disagree with you because many similar numerical conversions are
already taking place, e.g. 1/2, 1/4...
This part sounds like
Julien Rouhaud wrote:
> Maybe that's just me but I understand "not supported" as "this makes
> sense, but this is currently a limitation that might be lifted
> later".
Looking at ProcessCopyOptions(), there are quite a few invalid
combinations of options that produce
ERRCODE_FEATURE_NOT_
On 2022-06-14 Tu 19:24, Michael Paquier wrote:
> 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
>>> specif
On 2022-06-14 Tu 19:13, Michael Paquier wrote:
> 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. The
On Tue, Jun 14, 2022 at 9:07 AM wangw.f...@fujitsu.com
wrote:
>
>
> Attach the new patches.
> Only changed patches 0001, 0004 and added new separate patch 0005.
>
Few questions/comments on 0001
===
1.
In the commit message, I see: "We also need to allow stream_stop to
comp
On Wed, Jun 15, 2022 at 8:52 AM shiy.f...@fujitsu.com
wrote:
>
> 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 publis
Hi Matthias,
> The bulk of the patch
> should still be usable, but I think that the way it interfaces with
> the CREATE TABLE (column ...) APIs would need reworking to build on
> top of the api's of the "pluggable toaster" patches (so, creating
> toasters instead of types). I think that would allo
On Wed, Jun 15, 2022 at 5:23 AM Peter Eisentraut
wrote:
> > Consider a user who in general prefers the NOINHERIT behavior but also
> > wants to use predefined roles. Perhaps user 'peter' is to be granted
> > both 'paul' and 'pg_execute_server_programs'. If role 'peter' is set
> > to INHERIT, Peter
Hi Christoph!
> On 15 Jun 2022, at 15:45, Christoph Heiss wrote:
>
> By sorting the data before inserting it into the index results in a much
> better index structure, leading to significant performance improvements.
Here's my version of the very similar idea [0]. It lacks range types support.
Hi hackers,
I noticed that cfbot is not entirely happy with the patch, so I rebased it.
> I see that COMPRESSION and STORAGE now are handled slightly
> differently in the grammar. Maybe we could standardize that a bit
> more; so that we have only one `STORAGE [kind]` definition in the
> grammar?
Pushed this. I noticed that the paragraph that described MERGE in the
read-committed subsection had been put in the middle of some other paras
that describe interactions with other transactions, so I moved it up so
that it appears together with all the other paras that describe the
behavior of spe
Kyotaro Horiguchi writes:
> Also leading newlines and just "\n" bug me when I edit message
> catalogues with poedit. I might want a line-spacing function like
> pg_log_newline(PG_REPORT) if we need line-breaks in the ends of a
> message.
Yeah, that is sort of the inverse problem. I think those a
On Wed, Jun 15, 2022 at 4:54 AM Peter Eisentraut
wrote:
> It's hard to get any definite information about what size of checksum is
> "good enough", since after all it depends on what kinds of errors you
> expect and what kinds of probabilities you want to accept. But the best
> I could gather so
On Wed, Jun 15, 2022 at 1:51 AM Michael Paquier wrote:
> Handle is more consistent with the other types of interruptions in the
> SIGUSR1 handler, so the name proposed in the patch in not that
> confusing to me. And so does Process, in spirit with
> ProcessProcSignalBarrier() and ProcessLogMemory
On Wed, Jun 15, 2022 at 2:51 AM Peter Eisentraut
wrote:
> We have this problem of long file names being silently truncated all
> over the source code. Instead of equipping each one of them with a
> length check, why don't we get rid of the fixed-size buffers and
> allocate dynamically, as in the
On Tue, Jun 14, 2022 at 3:54 AM Masahiko Sawada wrote:
> > AFAICS, we could do that by:
> >
> > 1. De-supporting platforms that have this problem, or
> > 2. Introducing new typalign values, as Noah proposed back on April 2, or
> > 3. Somehow forcing values that are sometimes 4-byte aligned and
> >
On Tue, Jun 07, 2022 at 10:08:21PM +0900, Ian Lawrence Barwick wrote:
> A little late to the party, but as an alternative suggestion for the last
> part:
>
> "... and users who either own the session being reported on, or who have
> privileges of the role to which the session belongs,"
>
> so
Robert Haas writes:
> On Wed, Jun 15, 2022 at 2:51 AM Peter Eisentraut
> wrote:
>> We have this problem of long file names being silently truncated all
>> over the source code. Instead of equipping each one of them with a
>> length check, why don't we get rid of the fixed-size buffers and
>> all
On 2022-Jun-10, Kyotaro Horiguchi wrote:
> (Moved to -hackers)
>
> At Wed, 8 Jun 2022 17:08:47 +0200, Alvaro Herrera
> wrote in
> > What that Close message is doing is closing the unnamed portal, which
> > is otherwise closed implicitly when the next one is opened. That's how
> > single-query
Alvaro Herrera writes:
> So, git archaeology led me to this thread
> https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql
> which is why we added that message in the first place.
Um. Good thing you looked. I doubt we want to revert that change now.
> Alternatives:
> - Have the client n
Justin Pryzby writes:
> But Petr has a point - pg_upgrade should aspire to catch errors in --check,
> rather than starting and then leaving a mess behind for the user to clean up
Agreed; pg_upgrade has historically tried to find problems similar to
this. However, it's not just aggregates that ar
On Tue, Jun 14, 2022 at 10:30 PM Peter Geoghegan wrote:
> Basically I think that this is giving up rather a lot. For example,
> isn't it possible that we'd have corruption that could be a bug in
> either the checksum code, or in recovery?
>
> I'd feel a lot better about it if there was some sense
On Wed, Jun 15, 2022 at 1:27 PM Robert Haas wrote:
> I think what will happen, depending on
> the encryption mode, is probably that either (a) the page will decrypt
> to complete garbage or (b) the page will fail some kind of
> verification and you won't be able to decrypt it at all. Either way,
>
On Wed, Jun 15, 2022 at 02:02:03PM -0400, Tom Lane wrote:
> Yeah, that was what was bugging me about this proposal. Removing
> one function's dependency on MAXPGPATH isn't much of a step forward.
This comes down to out-of-memory vs path length at the end. Changing
only the paths of make_outputdi
On Wed, Jun 15, 2022 at 07:59:10AM -0400, Andrew Dunstan wrote:
> My would we do that? If you want a map don't pass any switches. But as
> written you could do:
>
> my ($incdir, $localedir, $sharedir) = $node->config_data(qw(--includedir
> --localedir --sharedir));
>
> No map needed to get what
Hackers,
While developing various Table Access Methods, I have wanted a callback for
determining if CLUSTER (and VACUUM FULL) should be run against a table backed
by a given TAM. The current API contains a callback for doing the guts of the
cluster, but by that time, it's a bit too late to cle
On Wed, Jun 15, 2022 at 5:05 PM shiy.f...@fujitsu.com
wrote:
>
...
> Thanks for updating the patch. Two comments:
>
> 1.
> + it means the copied table t3 contains all rows even
> when
> + they do not patch the row filter of publication
> pub3b.
>
> Typo. I think "they do not patch the ro
On Thu, Jun 9, 2022 at 11:50 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > Initially, that chapter did not document any system views.
>
> Maybe we could make the system views a separate chapter?
+1
--
Kind Regards,
Peter Smith.
Fujitsu Australia
Hi,
On 2022-06-15 17:21:56 -0700, Mark Dilger wrote:
> While developing various Table Access Methods, I have wanted a callback for
> determining if CLUSTER (and VACUUM FULL) should be run against a table
> backed by a given TAM. The current API contains a callback for doing the
> guts of the clus
Hackers,
I have extended the grammar to allow "USING NOT method [, ...]" to exclude one
or more TAMs in a CREATE TABLE statement. This may sound like a weird thing to
do, but it is surprisingly useful when developing new Table Access Methods,
particularly when you are developing two or more, n
> On Jun 15, 2022, at 6:01 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 17:21:56 -0700, Mark Dilger wrote:
>> While developing various Table Access Methods, I have wanted a callback for
>> determining if CLUSTER (and VACUUM FULL) should be run against a table
>> backed by a given TAM.
At Wed, 15 Jun 2022 14:56:42 -0400, Tom Lane wrote in
> Alvaro Herrera writes:
> > So, git archaeology led me to this thread
> > https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql
> > which is why we added that message in the first place.
>
> Um. Good thing you looked. I doubt we wa
At Thu, 16 Jun 2022 10:34:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 15 Jun 2022 14:56:42 -0400, Tom Lane wrote in
> > Alvaro Herrera writes:
> > > So, git archaeology led me to this thread
> > > https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql
> > > which is why we adde
Hi,
On 2022-06-15 18:24:45 -0700, Mark Dilger wrote:
> > On Jun 15, 2022, at 6:01 PM, Andres Freund wrote:
> > On 2022-06-15 17:21:56 -0700, Mark Dilger wrote:
> >> While developing various Table Access Methods, I have wanted a callback for
> >> determining if CLUSTER (and VACUUM FULL) should be
> On Jun 15, 2022, at 6:55 PM, Andres Freund wrote:
>
> I think nothing would happen in this case - only pre-clustered tables get
> clustered in an argumentless CLUSTER. What am I missing?
The "VACUUM FULL" synonym of "CLUSTER" doesn't depend on whether the target is
pre-clustered, and both
Hi,
On 2022-06-15 19:07:50 -0700, Mark Dilger wrote:
> > On Jun 15, 2022, at 6:55 PM, Andres Freund wrote:
> >
> > I think nothing would happen in this case - only pre-clustered tables get
> > clustered in an argumentless CLUSTER. What am I missing?
>
> The "VACUUM FULL" synonym of "CLUSTER" do
> On Jun 15, 2022, at 7:14 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 19:07:50 -0700, Mark Dilger wrote:
>>> On Jun 15, 2022, at 6:55 PM, Andres Freund wrote:
>>>
>>> I think nothing would happen in this case - only pre-clustered tables get
>>> clustered in an argumentless CLUSTER.
> On Jun 15, 2022, at 7:21 PM, Mark Dilger wrote:
>
>> If a user does that for a table that doesn't support clustering, well, I
>> don't
>> see what's gained by not erroring out.
>
> Perhaps they want to give the TAM information about which index to use for
> sorting, on those occasions whe
Hi,
On 2022-06-15 19:21:42 -0700, Mark Dilger wrote:
> > On Jun 15, 2022, at 7:14 PM, Andres Freund wrote:
> > On 2022-06-15 19:07:50 -0700, Mark Dilger wrote:
> >>> On Jun 15, 2022, at 6:55 PM, Andres Freund wrote:
> >>>
> >>> I think nothing would happen in this case - only pre-clustered tabl
On Sat, Jun 11, 2022 at 09:41:37AM -0500, Justin Pryzby wrote:
> Note that this gives:
>
> guc.c:7573:9: warning: ‘dst’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>
> with gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
>
> I wonder whether you'd consider renaming p
At Thu, 16 Jun 2022 10:34:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> PQgetResult() resets the state to IDLE while in pipeline mode.
>
> fe-exec.c:2171
>
> > if (conn->pipelineStatus != PQ_PIPELINE_OFF)
> > {
> > /*
> >
> On Jun 15, 2022, at 7:30 PM, Andres Freund wrote:
>
>> It's effectively a synonym which determines whether the "bool use_sort"
>> parameter of the table AM's relation_copy_for_cluster will be set. Heap-AM
>> plays along and sorts or not based on that.
>
> Hardly a synonym if it behaves dif
On Wed, Mar 23, 2022 at 03:02:23PM -0400, Tom Lane wrote:
> I agree with Maciek's concerns about these HINTs being emitted
> inappropriately, but I also have a stylistic gripe: they're only
> halfway hints. Given that we fix things so they only print when they
> should, the complaint about the ser
Hi,
On 2022-06-15 20:10:30 -0700, Mark Dilger wrote:
> > On Jun 15, 2022, at 7:30 PM, Andres Freund wrote:
> >> But it's up to the TAM what it wants to do with that boolean, if in fact it
> >> does anything at all based on that. A TAM could decide to do the exact
> >> opposite of what Heap-AM do
On Wed, Mar 23, 2022 at 05:13:47PM +0530, RKN Sai Krishna wrote:
> Considering the scenarios where primary is ahead of sync standbys, upon
> promotion of a standby, pg_rewind is needed on the old primary if it has to
> be up as a standby. Similarly in the scenarios where async standbys(in
> physica
I've started to think that we should really WARN whenever a (set of) GUC is set
in a manner that the server will fail to start - not just for shared libraries.
In particular, I think the server should also warn if it's going to fail to
start like this:
2022-06-15 22:48:34.279 CDT postmaster[20782
On Wed, Jun 15, 2022 at 8:18 PM Andres Freund wrote:
> > If a simple callback like
> > relation_supports_cluster(Relation rel) is too simplistic
>
Seems like it should be called:
relation_supports_compaction[_by_removal_of_interspersed_dead_tuples]
Basically, if the user tells the table to make
On Wed, Jun 15, 2022 at 06:16:21PM -0700, Mark Dilger wrote:
> When developing two or more TAMs, this falls apart. Some tests may
> be worth fixing up (perhaps with alternate output files) for
> "mytam", but not for "columnar_tam". That might be because the test
> is checking fundamentally row-st
On Tue, Jun 14, 2022 at 9:10 AM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, June 8, 2022 7:04 PM Amit Kapila
> wrote:
> >
> > On Fri, Jun 3, 2022 at 3:37 PM vignesh C wrote:
> > >
> > > Thanks for the comments, the attached v8 patch has the changes for the
> > same.
> > >
> >
> > AFAICS, th
On Mon, Jun 13, 2022 at 8:54 AM Amit Kapila wrote:
>
> I would like to close the Open item listed corresponding to this
> thread [1] as the fix for the reported issue is committed
> (fd0b9dcebd). Do let me know if you or others think otherwise?
>
Seeing no objections, I have closed this item.
--
On Wed, Jun 15, 2022 at 8:51 PM Michael Paquier wrote:
> On top of that
> default_table_access_method is user-settable.
>
>
FWIW this proposal acknowledges that and basically leverages it to the
hilt, turning it into something like search_path. I strongly dislike the
idea of any workflow that de
On Wed, May 25, 2022 at 11:48 AM Masahiko Sawada wrote:
>
> On Tue, May 10, 2022 at 6:58 PM John Naylor
> wrote:
> >
> > On Tue, May 10, 2022 at 8:52 AM Masahiko Sawada
> > wrote:
> > >
> > > Overall, radix tree implementations have good numbers. Once we got an
> > > agreement on moving in this
On Wed, Jun 15, 2022 8:30 PM Amit Kapila wrote:
>
> I have pushed the first bug-fix patch today.
>
Thanks.
Attached the remaining patches which are rebased.
Regards,
Shi yu
v9-0002-fix-memory-leak-about-attrmap.patch
Description: v9-0002-fix-memory-leak-about-attrmap.patch
v9-0001-Check-
> On Jun 15, 2022, at 8:51 PM, Michael Paquier wrote:
>
> However,
> your problem is basically that you develop multiple AMs, but you want
> to have regression tests that do checks across more than one table AM
> at the same time.
It is true that I test multiple table AMs at the same time, bu
Hi,
On Wed, Jun 15, 2022 at 06:45:38PM +, Imseih (AWS), Sami wrote:
> Adding a plan_id to pg_stat_activity allows users
> to determine if a plan for a particular statement
> has changed and if the new plan is performing better
> or worse for a particular statement.
> [...]
> Attached is a POC
> On Jun 15, 2022, at 8:18 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 20:10:30 -0700, Mark Dilger wrote:
>>> On Jun 15, 2022, at 7:30 PM, Andres Freund wrote:
But it's up to the TAM what it wants to do with that boolean, if in fact it
does anything at all based on that. A
On 15/6/2022 21:45, Imseih (AWS), Sami wrote:
Adding a plan_id to pg_stat_activity allows users
to determine if a plan for a particular statement
has changed and if the new plan is performing better
or worse for a particular statement.
There are several ways the plan_id in pg_stat_activity
In ge
> On Jun 15, 2022, at 8:51 PM, Michael Paquier wrote:
>
> I am not sure to see why this would be something users would actually
> use in prod. That means to pick up something else than what the
> server thinks is the best default AM but where somebody does not want
> to trust the default, whi
Hi,
On Thu, Jun 16, 2022 at 2:07 PM shiy.f...@fujitsu.com
wrote:
> On Wed, Jun 15, 2022 8:30 PM Amit Kapila wrote:
> > I have pushed the first bug-fix patch today.
>
> Attached the remaining patches which are rebased.
Thanks.
Comments on v9-0001:
+ * Don't throw any error here just mark the r
On Thu, Jun 09, 2022 at 02:47:36PM +0900, Michael Paquier wrote:
> On Thu, Jun 09, 2022 at 04:55:45PM +1200, Thomas Munro wrote:
>> I think we can drop mention of Itanium (RIP): the ancient versions of
>> Windows that could run on that arch are desupported with your patch.
>> It might be more relev
> On Jun 15, 2022, at 8:50 PM, David G. Johnston
> wrote:
>
> On Wed, Jun 15, 2022 at 8:18 PM Andres Freund wrote:
> > If a simple callback like
> > relation_supports_cluster(Relation rel) is too simplistic
>
> Seems like it should be called:
> relation_supports_compaction[_by_removal_of_i
On Thu, 2 Jun 2022 07:43:06 +0900
Michael Paquier wrote:
> On Wed, Jun 01, 2022 at 10:15:17AM -0400, Tom Lane wrote:
> > It's always appropriate to consider backwards compatibility, and we
> > frequently don't back-patch a change because of worries about that.
> > However, if someone complains be
On Thu, Jun 16, 2022 at 11:43 AM Amit Langote wrote:
>
> On Thu, Jun 16, 2022 at 2:07 PM shiy.f...@fujitsu.com
> wrote:
> > On Wed, Jun 15, 2022 8:30 PM Amit Kapila wrote:
> > > I have pushed the first bug-fix patch today.
> >
> > Attached the remaining patches which are rebased.
>
> Thanks.
>
>
70 matches
Mail list logo
