On Wed, Oct 14, 2020 at 10:29:44AM +0900, Kyotaro Horiguchi wrote:
> The reason is the function XLogDumpRecordLen is a common function
> among all kind of LOG records, not belongs only to XLOG_SWICH. And the
> junk_len is not useful for other than XLOG_SWITCH. Descriptions
> specifc to XLOG_SWITCH
On Wed, Oct 14, 2020 at 1:30 AM Heikki Linnakangas wrote:
> On 13/10/2020 19:09, Heikki Linnakangas wrote:
> > One little idea I had:
> >
> > I think all FDWs that support direct modify will have to carry the
> > resultRelaton index or the ResultRelInfo pointer from BeginDirectModify
> > to Iterat
At Wed, 14 Oct 2020 11:26:33 +0800, Andy Fan wrote
in
> On Mon, Oct 12, 2020 at 4:37 PM Amit Langote
> wrote:
> > I think we should remove this duplicative logic and return the
> > generated steps in a list from this function, which the code in
> > gen_partprune_steps_internal() then "combines"
Hi all,
Since 510b8cbf, we have in-core equivalents for htonl(), ntohl() & co
through pg_bswap.h that allows to compile with a built-in function if
the compiler used has one.
All the existing calls in the code tree have been changed with
0ba99c84 for performance reasons (except the libpq examples
Justin Pryzby wrote:
> I'm interested in testing this patch, however there's a lot of internals to
> digest.
>
> Are there any documentation updates or regression tests to add ?
I'm not sure if user documentation should be changed unless a new GUC or
statistics information is added. As for regr
On Wed, Oct 14, 2020 at 10:18:38AM +0900, Kyotaro Horiguchi wrote:
> At Fri, 9 Oct 2020 11:48:59 -0300, Alvaro Herrera
> wrote in
>> Doesn't enlargePQExpBuffer() include room for the trailing zero? I
>> think it does.
>
> Right. I faintly recall I said the same thing before..
FWIW, as pqexpbu
On Wed, Oct 14, 2020 at 02:48:18PM +1300, Thomas Munro wrote:
> On Wed, Oct 14, 2020 at 12:53 AM Michael Banck
> wrote:
>> One question about this: Did you consider the case of a basebackup being
>> copied/restored somewhere and the restore/PITR being started? Shouldn't
>> Postgres then sync the w
On Wed, 14 Oct 2020 at 13:19, Kyotaro Horiguchi wrote:
>
> At Wed, 14 Oct 2020 12:09:34 +0900, Masahiko Sawada
> wrote in
> > On Wed, 14 Oct 2020 at 10:16, Kyotaro Horiguchi
> > wrot> > There are cases of commit-failure of a local transaction caused by
> > > too-many notifications or by serial
At Wed, 14 Oct 2020 12:09:34 +0900, Masahiko Sawada
wrote in
> On Wed, 14 Oct 2020 at 10:16, Kyotaro Horiguchi
> wrot> > There are cases of commit-failure of a local transaction caused by
> > too-many notifications or by serialization failure.
>
> Yes, even if that happens we are still able t
Commit 464824323e has added the support of the streaming of
in-progress transactions into the built-in logical replication. The
attached patch adds the statistics about transactions streamed to the
decoding output plugin from ReorderBuffer. Users can query the
pg_stat_replication_slots view to chec
On Mon, Sep 28, 2020 at 12:55:06PM +0900, Michael Paquier wrote:
> Thanks. I have done more tests with the range of OpenSSL versions we
> support on HEAD, and applied this one. I have noticed that the
> previous patch forgot two fail-and-abort code paths as of
> EVP_DigestInit_ex() and EVP_Digest
On Mon, Oct 12, 2020 at 4:37 PM Amit Langote
wrote:
> Hi,
>
> On Thu, Oct 8, 2020 at 6:56 PM Andy Fan wrote:
> >
> > Hi:
> >
> > I found the following code in gen_partprune_steps_internal, which
> > looks the if-statement to be always true since list_length(results) > 1;
> > I added an Assert
David Rowley writes:
> On Wed, 14 Oct 2020 at 04:16, Tom Lane wrote:
>> So now I'm imagining something like
>> #define MAXIMUM_ROWCOUNT 1e100
> That seems more reasonable. We likely could push it a bit higher, but
> I'm not all that motivated to since if that was true, then you could
> expect th
On Wed, 14 Oct 2020 at 10:16, Kyotaro Horiguchi wrote:
>
> At Tue, 13 Oct 2020 11:56:51 +0900, Masahiko Sawada
> wrote in
> > On Tue, 13 Oct 2020 at 10:00, Kyotaro Horiguchi
> > wrote:
> > >
> > > At Fri, 9 Oct 2020 21:45:57 +0900, Masahiko Sawada
> > > wrote in
> > > > On Fri, 9 Oct 2020 at
Thanks for your comment.
> 8.3. Character Types:
> The name type exists only for the storage of identifiers in the internal
> system catalogs
I didn't know the policy about data types. Thank you.
But I think the column names should match pg_replication_slots.
The attached patch changes only the
Thanks for having a look at this.
On Wed, 14 Oct 2020 at 04:16, Tom Lane wrote:
> I'm on board with trying to get rid of NaN rowcount estimates more
> centrally. I do not think it is a good idea to try to wire in a
> prohibition against zero rowcounts. That is actually the correct
> thing in as
On Wed, Mar 07, 2018 at 05:53:18PM -0800, Peter Geoghegan wrote:
> On Thu, Mar 1, 2018 at 2:47 PM, Peter Geoghegan wrote:
> > No. Just an oversight. Looks like _bt_parallel_build_main() should
> > call pgstat_report_activity(), just like ParallelQueryMain().
> >
> > I'll come up with a patch soon.
On Wed, Oct 14, 2020 at 12:53 AM Michael Banck
wrote:
> Am Mittwoch, den 07.10.2020, 18:17 +1300 schrieb Thomas Munro:
> > ... and for comparison/discussion, here is an alternative patch that
> > figures out precisely which files need to be fsync'd using information
> > in the WAL.
>
> One questio
At Mon, 12 Oct 2020 09:46:37 +0800, "movead...@highgo.ca"
wrote in
>
> Thanks for reply.
>
> >If you wish to add more information about a XLOG_SWITCH record, I
> >don't think that changing the signature of XLogDumpRecordLen() is
> >adapted because the record length of this record is defined as
At Fri, 9 Oct 2020 11:48:59 -0300, Alvaro Herrera
wrote in
> > +pqLogMsgString(PGconn *conn, const char *v, int length, PGCommSource
> > commsource)
> > +{
> > + if (length < 0)
> > + length = strlen(v) + 1;
> > +
>
> > pqLogMsgString(conn, str, -1, FROM_*) means actual length may
At Tue, 13 Oct 2020 11:56:51 +0900, Masahiko Sawada
wrote in
> On Tue, 13 Oct 2020 at 10:00, Kyotaro Horiguchi
> wrote:
> >
> > At Fri, 9 Oct 2020 21:45:57 +0900, Masahiko Sawada
> > wrote in
> > > On Fri, 9 Oct 2020 at 14:55, Kyotaro Horiguchi
> > > wrote:
> > > >
> > > > At Fri, 9 Oct 20
On Tue, Oct 13, 2020 at 3:48 PM Amit Langote
wrote:
> On Thu, Oct 8, 2020 at 8:25 PM Ashutosh Bapat
> wrote:
> > On Wed, Oct 7, 2020 at 7:00 PM Andy Fan
> wrote:
> > > I can understand Robert's idea now, he intended to resolve both the
> > > "initial-partition-prune" case and "runtime partitio
Thanks for visiting this thread.
At Mon, 12 Oct 2020 15:04:40 +0300, Heikki Linnakangas wrote
in
> On 07/07/2020 12:02, matsumura@fujitsu.com wrote:
> > At Monday, July 6, 2020 05:13:40 +, "Kyotaro Horiguchi
> > " wrote in
> after WAL buffer is filled up to the requested position.
On Tue, Oct 13, 2020 at 01:44:41PM +0200, Laurenz Albe wrote:
> Attached is v3 with improvements.
+
+ Time spent in database sessions in this database, in milliseconds.
+
Should say "Total time spent *by* DB sessions..." ?
I think these counters are only accurate as of the last
On 2020-Oct-14, Masahiko Sawada wrote:
> I've attached the patch as an idea of fixing the above comments as
> well as the comment from Alvaro. I can be applied on top of v4 patch.
One note about the translation stuff. Currently you have _("...") where
the string is produced, and then ereport(..,
On Sun, 4 Oct 2020 at 20:48, Drouvot, Bertrand wrote:
>
>
> On 8/28/20 4:14 PM, Drouvot, Bertrand wrote:
> >
> > On 8/28/20 7:03 AM, Masahiko Sawada wrote:
> >> CAUTION: This email originated from outside of the organization. Do
> >> not click links or open attachments unless you can confirm the s
Re: Andres Freund
> > clang-10 [!alpha !hppa !hurd-i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386
> > !m68k !powerpc !riscv64 !s390x !sh4 !sparc64 !x32],
>
> !powerpc doesn't exclude ppc64, I assume?
That's direct matches only, there's no architecture-family logic in
there.
> > [*] apparently pgbenc
On Tue, Oct 13, 2020 at 11:34:27PM +0200, Peter Eisentraut wrote:
> On 2020-10-13 19:23, Pavel Stehule wrote:
> > no, I just missi note, so after upgrade by pg_upgrade I have to recreate
> > replication slots. Some like
> >
> > after pg_upgrade you should to do:
> >
> > a) run analyze (it is
On 2020-10-13 19:23, Pavel Stehule wrote:
no, I just missi note, so after upgrade by pg_upgrade I have to recreate
replication slots. Some like
after pg_upgrade you should to do:
a) run analyze (it is a known case)
b) recreate replication slots - these slots are not removed in the
upgrad
On Fri, Feb 7, 2020 at 05:24:12PM +0900, Fujii Masao wrote:
> On Fri, Apr 12, 2019 at 1:44 PM Michael Paquier wrote:
> >
> > On Thu, Apr 11, 2019 at 02:06:13PM -0400, Tom Lane wrote:
> > > Yeah, if we could simplify the tableam API, that would be sufficient
> > > reason to remove the stuff in v12
Going to take a guess at what you mean by:
I do object to using syntax that makes random assumptions about what a
user name can or can't be.
Are you referring to the "+" syntax in the ident file? I chose that because
somewhere else (hba?) using the same syntax for groups. The quotes are just
ther
Russell Foster writes:
> I understand your concerns overall, and the solution you propose seems
> reasonable. But are we just using "windows-group" because the code is not
> there today to check for a user in another OS group?
It's not clear to me whether Windows groups have exact equivalents in
On Wed, Sep 30, 2020 at 04:52:02PM -0700, Soumyadeep Chakraborty wrote:
> Hi Justin,
>
> Attached is a minimal patch that is rebased and removes the
> dependency on Konstantin's earlier patch[1], making it enough to remove
> the extraneous index scans as Justin brought up. Is this the direction we
Russell Foster writes:
> Going to take a guess at what you mean by:
>> I do object to using syntax that makes random assumptions about what a
>> user name can or can't be.
> Are you referring to the "+" syntax in the ident file? I chose that because
> somewhere else (hba?) using the same syntax f
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Hi
I applied the patch to PG master branch successfully and the
Hi,
On 2020-09-28 14:22:01 +0200, Christoph Berg wrote:
> Re: Andres Freund
> > > > Ok, but given that Debian is currently targeting 22 architectures, I
> > > > doubt the PostgreSQL buildfarm covers all of them with the extra JIT
> > > > option, so I should probably make sure to do that here whe
Hi there, it's my first email, so I’d like to first thanks everyone working on
this, using pgadmin had made a huge difference for me! I’m using it with
serverless PostgreSQL databases on AWS, and for at the first one I went through
the work of creating an EC2 instance I could ssh tunnel to so I
út 13. 10. 2020 v 18:57 odesílatel Bruce Momjian napsal:
> On Tue, Oct 13, 2020 at 06:37:14PM +0200, Pavel Stehule wrote:
> >
> >
> > út 13. 10. 2020 v 18:33 odesílatel Bruce Momjian
> napsal:
> >
> > On Tue, Oct 13, 2020 at 06:20:41PM +0200, Pavel Stehule wrote:
> > > Hi
> > >
> >
Russell Foster writes:
> I have some code that I've been using that supports adding and
> authenticating Windows groups via the pg_ident file. This is useful for
> sysadmins as it lets them control database access outside the database
> using Windows groups. It has a new
> indicator (+), that sign
On Tue, Oct 13, 2020 at 06:37:14PM +0200, Pavel Stehule wrote:
>
>
> út 13. 10. 2020 v 18:33 odesílatel Bruce Momjian napsal:
>
> On Tue, Oct 13, 2020 at 06:20:41PM +0200, Pavel Stehule wrote:
> > Hi
> >
> > One customer reports issue related to pg_upgrade.
> >
> > I fou
I have some code that I've been using that supports adding and
authenticating Windows groups via the pg_ident file. This is useful for
sysadmins as it lets them control database access outside the database
using Windows groups. It has a new
indicator (+), that signifies the identifier is a Windows
I grow quite weary of the number of buildfarm failures we see as a
consequence of the Linux PPC64 bug discussed in [1]. Although we can
anticipate that the fix will roll out into new kernel builds before much
longer, that will have very little effect on the buildfarm situation,
given that a lot of
út 13. 10. 2020 v 18:33 odesílatel Bruce Momjian napsal:
> On Tue, Oct 13, 2020 at 06:20:41PM +0200, Pavel Stehule wrote:
> > Hi
> >
> > One customer reports issue related to pg_upgrade.
> >
> > I found a thread https://www.postgresql-archive.org/
> >
> Upgrade-and-re-synchronization-with-logical
On Tue, Oct 13, 2020 at 06:20:41PM +0200, Pavel Stehule wrote:
> Hi
>
> One customer reports issue related to pg_upgrade.
>
> I found a thread https://www.postgresql-archive.org/
> Upgrade-and-re-synchronization-with-logical-replication-pglogical-and-PG-10-td6001990.html
>
> But I didn't find do
On 2020/10/13 10:40, Kasahara Tatsuhito wrote:
Hi,
On Fri, Oct 9, 2020 at 5:44 PM Shinya Okano wrote:
Hi,
Regarding the toast_tuple_target parameter of CREATE TABLE, the
documentation says that it only affects External or Extended, but it
actually affects the compression of Main as well.
On 13/10/2020 19:09, Heikki Linnakangas wrote:
One little idea I had:
I think all FDWs that support direct modify will have to carry the
resultRelaton index or the ResultRelInfo pointer from BeginDirectModify
to IterateDirectModify in the FDW's private struct. It's not
complicated, but should we
Hi
One customer reports issue related to pg_upgrade.
I found a thread
https://www.postgresql-archive.org/Upgrade-and-re-synchronization-with-logical-replication-pglogical-and-PG-10-td6001990.html
But I didn't find documentation of this limitation?
Regards
Pavel
On 13/10/2020 15:03, Amit Langote wrote:
On Tue, Oct 13, 2020 at 7:13 PM Heikki Linnakangas wrote:
Ok, committed. I'll continue to look at the rest of the patches in this
patch series now.
I've reviewed the next two patches in the series, they are pretty much
ready for commit now. I made jus
Li Japin writes:
> I agree with Heikki from the code execution point of view.
> In code execution point of view they are same, however, the code is for user,
> i think the readability is also important.
There is another consideration here, which is avoiding creating
back-patching hazards from g
David Rowley writes:
> Because there's been quite a few of these, and this report is yet
> another one, I wonder if it's time to try and stamp these out at the
> source rather than where the row counts are being used.
I'm on board with trying to get rid of NaN rowcount estimates more
centrally.
On Oct 13, 2020, at 9:59 PM, Hamid Akhtar
mailto:hamid.akh...@gmail.com>> wrote:
On Tue, Oct 13, 2020 at 6:37 PM Heikki Linnakangas
mailto:hlinn...@iki.fi>> wrote:
On 13/10/2020 16:30, Li Japin wrote:
> Hi,
>
> I found in guc-file.l we can omit the else branch in AbsoluteConfigLocation().
It
On Oct 13, 2020, at 9:59 PM, Hamid Akhtar
mailto:hamid.akh...@gmail.com>> wrote:
On Tue, Oct 13, 2020 at 6:37 PM Heikki Linnakangas
mailto:hlinn...@iki.fi>> wrote:
On 13/10/2020 16:30, Li Japin wrote:
> Hi,
>
> I found in guc-file.l we can omit the else branch in AbsoluteConfigLocation().
It
On Tue, Oct 13, 2020 at 7:57 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > I am able to reproduce this problem via debugger. Basically, execute
> > the Insert mentioned above from one the psql sessions and in
> > ExecInsert() stop the execution once 'estate->es_processed > 4000' and
> > then fro
Amit Kapila writes:
> I am able to reproduce this problem via debugger. Basically, execute
> the Insert mentioned above from one the psql sessions and in
> ExecInsert() stop the execution once 'estate->es_processed > 4000' and
> then from another psql terminal execute some DDL which will be ignore
On Tue, Oct 13, 2020 at 6:37 PM Heikki Linnakangas wrote:
> On 13/10/2020 16:30, Li Japin wrote:
> > Hi,
> >
> > I found in guc-file.l we can omit the else branch in
> AbsoluteConfigLocation().
>
> It will compile the same, so it's just a matter of code readability or
> taste which style is bette
On 13/10/2020 16:30, Li Japin wrote:
Hi,
I found in guc-file.l we can omit the else branch in AbsoluteConfigLocation().
It will compile the same, so it's just a matter of code readability or
taste which style is better here. I think we should leave it alone, it's
fine as it is.
- Heikki
Hi,
I found in guc-file.l we can omit the else branch in AbsoluteConfigLocation().
diff --git a/src/backend/utils/misc/guc-file.l
b/src/backend/utils/misc/guc-file.l
index c98e220295..9d4b3d7236 100644
--- a/src/backend/utils/misc/guc-file.l
+++ b/src/backend/utils/misc/guc-file.l
@@ -522,23 +52
‐‐‐ Original Message ‐‐‐
On Thursday, September 10, 2020 12:51 PM, Daniel Gustafsson
wrote:
[snip]
> Since we have introduced the table AM api I support going throug it for all
> table accesses, so +1 on the overall idea.
>
Thank you for reviewing! Please find v2 of the patch atta
On Mon, Oct 12, 2020 at 3:46 PM Hamid Akhtar wrote:
>
>
> On Tue, Sep 29, 2020 at 2:57 PM Heikki Linnakangas
> wrote:
>
>> On 29/09/2020 11:49, Hamid Akhtar wrote:
>> > So, not actually random replacement here, rather a change with
>> > baserel->allvisfrac taken into consideration (as given belo
Thanks Michael for taking care of that!
Here’s the rebased patches with the last one dropped.
Regards,
Rémi
v6-0001-Add-header-support-to-COPY-TO-text-format.patch
Description: Binary data
v6-0002-Add-header-matching-mode-to-COPY-FROM.patch
Description: Binary data
> Le 5 oct. 2020 à 03:0
On Tue, Oct 13, 2020 at 7:13 PM Heikki Linnakangas wrote:
> On 13/10/2020 07:32, Amit Langote wrote:
> > On Tue, Oct 13, 2020 at 1:57 AM Heikki Linnakangas wrote:
> >> It occurred to me that if we do that (initialize the array lazily),
> >> there's very little need for the PlannedStmt->resultRela
Hi,
Am Mittwoch, den 07.10.2020, 18:17 +1300 schrieb Thomas Munro:
> ... and for comparison/discussion, here is an alternative patch that
> figures out precisely which files need to be fsync'd using information
> in the WAL.
One question about this: Did you consider the case of a basebackup bein
On Fri, 2020-10-02 at 15:10 -0700, Soumyadeep Chakraborty wrote:
> On Tue, Sep 29, 2020 at 2:44 AM Laurenz Albe wrote:
> > > * Are we trying to capture ONLY client initiated disconnects in
> > > m_aborted (we are not handling other disconnects by not accounting for
> > > EOF..like if psql was kill
On 13/10/2020 07:32, Amit Langote wrote:
On Tue, Oct 13, 2020 at 1:57 AM Heikki Linnakangas wrote:
It occurred to me that if we do that (initialize the array lazily),
there's very little need for the PlannedStmt->resultRelations list
anymore. It's only used in ExecRelationIsTargetRelation(), bu
On Fri, Sep 04, 2020 at 09:49:16PM -0400, Tom Lane wrote:
> There are a couple different ways we might think about fixing
> this. Maybe this specific rule is broken and needs to be fixed to
> not assume that '$(dir $<)' is the same for all its dependencies.
> Alternatively, maybe the problem is th
On Sat, 10 Oct 2020 at 02:19, Tom Lane wrote:
> I'm fairly certain that every one of the existing NaN checks was put
> there on the basis of hard experience. Possibly digging in the git
> history would offer more info about exactly where the NaNs came from.
I had a look at this and found there'
Hi,
While developing some improvements for TPC-DS queries I found out that with
UNION ALL partial paths are not emitted. Whilst fixing that I also came across
the subquery costing which does not seem to consider parallelism when doing
the costing.
I added a simplified testcase in pg-regress to sh
> I found some code path use list_delete_ptr while the loop of foreach() is
> iterating.
>
> List_delete_ptr seems search the list again to find the target cell and
> delete it.
> > foreach(cell, list)
> > {
> > if (lfirst(cell) == datum)
> > return list_del
On Tue, Oct 13, 2020 at 12:51 PM Masahiko Sawada
wrote:
>
>
> > I'll push the patch as I am more
> > confident now.
>
> +1. Let's check how the tests are going to be.
>
Okay, thanks. I have pushed it.
--
With Regards,
Amit Kapila.
On Thu, Oct 8, 2020 at 8:25 PM Ashutosh Bapat
wrote:
> On Wed, Oct 7, 2020 at 7:00 PM Andy Fan wrote:
> > I can understand Robert's idea now, he intended to resolve both the
> > "initial-partition-prune" case and "runtime partition prune" case while I
> > always think
> > about the former case
On Tue, 13 Oct 2020 at 16:12, Amit Kapila wrote:
>
> On Tue, Oct 13, 2020 at 12:17 PM Masahiko Sawada
> wrote:
> >
> > On Tue, 13 Oct 2020 at 15:27, Amit Kapila wrote:
> > >
> > > On Tue, Oct 13, 2020 at 11:49 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Tue, 13 Oct 2020 at 14:53, Amit Ka
On Tue, Oct 13, 2020 at 12:42 PM Amit Kapila wrote:
>
> On Tue, Oct 13, 2020 at 12:17 PM Masahiko Sawada
> wrote:
> >
> > I agree to check if the spill_counts and spill_txns are positive.
> >
>
> I am able to reproduce this problem via debugger. Basically, execute
> the Insert mentioned above fro
On Tue, Oct 13, 2020 at 12:17 PM Masahiko Sawada
wrote:
>
> On Tue, 13 Oct 2020 at 15:27, Amit Kapila wrote:
> >
> > On Tue, Oct 13, 2020 at 11:49 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, 13 Oct 2020 at 14:53, Amit Kapila wrote:
> > > >
> > > > The original theory I have given above [1
73 matches
Mail list logo
