At Sun, 29 Mar 2020 21:41:01 -0700, Noah Misch wrote in
> I think attached v41nm is ready for commit. Would anyone like to vote against
> back-patching this? It's hard to justify lack of back-patch for a data-loss
> bug, but this is atypically invasive. (I'm repeating the question, since some
On Wed, Mar 25, 2020 at 04:42:31PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Mar 19, 2020 at 06:04:52PM -0400, Tom Lane wrote:
> >> 3. It feels like the proposed test of cutoff position against both
> >> ends of a segment is a roundabout way of fixing the problem. I
> >> wonder
Hello Justin,
Well, the following comment says "ignore anything but regular files",
so I'm supposing that that is the behavior that we actually want here
and failed to implement correctly. There might be scope for
additional directory-reading functions, but I'd think you'd want
more
At Fri, 13 Mar 2020 16:21:13 +0900 (JST), Kyotaro Horiguchi
wrote in
> > 0007: "Use a WaitEventSet for postgres_fdw."
>
> Continues..
At Thu, 27 Feb 2020 12:17:45 +1300, Thomas Munro wrote
in
> 0007: "Use a WaitEventSet for postgres_fdw."
>
> Create a single WaitEventSet and use it for
On Sun, 2020-03-29 at 23:31 +0200, Shay Rojansky wrote:
> While working on first-class support for PG collations in the Entity
> Framework Core ORM,
> I've come across an interesting problem: it doesn't seem to be possible to
> create a
> database with a collation that isn't predefined, and
On Sat, 2020-03-28 at 19:21 +1300, David Rowley wrote:
> Thank you. Pushed.
Thanks for your efforts on this, and thanks for working on the fallout.
How can it be that even after an explicit VACUUM, this patch can cause
unstable regression test results?
Yours,
Laurenz Albe
On 2020/03/29 15:15, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote:
On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao wrote:
So what I'd like to say is that the information that users are interested
in would vary on each situation and case. At least for
Amit Kapila writes:
> On Sat, Mar 28, 2020 at 8:02 PM James Coleman wrote:
>> I'm curious if Tom's objection is mostly on the grounds that we should
>> be consistent in what's displayed, or that he thinks the information
>> is likely to be useless.
> Yeah, it would be good if he clarifies his
I wrote:
> I'm forced to the conclusion that the important difference between
> snapper and skate is that the latter uses --enable-cassert and the
> former doesn't, because that's the only remaining difference between
> how I built a working version before and the not-working version
> I have
On Sat, Mar 28, 2020 at 8:02 PM James Coleman wrote:
>
> On Fri, Mar 27, 2020 at 9:24 PM Amit Kapila wrote:
> >
> > Yeah, I also see this information could be useful. It seems Tom Lane
> > is not entirely convinced of this. I am not sure if this is the right
> > time to seek more opinions as
Hi,
On 2020-03-30 11:54:03 +0800, Craig Ringer wrote:
> On Fri, 20 Mar 2020, 01:59 Andres Freund, wrote:
> > On 2020-03-17 10:09:18 -0400, Tom Lane wrote:
> > > We might want to spend some effort thinking how to find or prevent
> > > additional bugs of the same ilk ...
> >
> > Yea, that'd be
Craig Ringer writes:
> I'd have found it helpful to just have the docs explain clearly how it
> works by chaining the comma operator using functions with ignored return
> values.
Want to write some text?
> That would also help people understand how they can make parts of an
> ereport
On Fri, 20 Mar 2020, 01:59 Andres Freund, wrote:
> Hi,
>
> On 2020-03-17 10:09:18 -0400, Tom Lane wrote:
> > We might want to spend some effort thinking how to find or prevent
> > additional bugs of the same ilk ...
>
> Yea, that'd be good. Trying to help people new to postgres write their
>
On Mon, 9 Mar 2020, 17:27 Peter Eisentraut, <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-02-07 04:14, Craig Ringer wrote:
> > The attached patch fixes this by having PGXS resolve
> > $(EXTENSION).control along the VPATH.
>
> Simpler patch:
>
> diff --git a/src/makefiles/pgxs.mk
Amit Kapila writes:
> On Mon, Mar 30, 2020 at 7:47 AM Tom Lane wrote:
>> But the ones that were seemingly due to that were intermittent,
>> so we'll have to watch for awhile.
> Today, stats_ext failed on petalura [1]. Can it be due to this? I
> have also committed a patch but immediately I
On Sun, Mar 29, 2020 at 11:35 AM Amit Kapila wrote:
>
> On Sun, Mar 29, 2020 at 9:04 AM Masahiko Sawada
> wrote:
> >
> > On Sat, 28 Mar 2020 at 13:23, Amit Kapila wrote:
> > >
> > >
> > > Please find attached the updated patch with all the changes discussed.
> > > Let me know if I have missed
On Mon, Mar 30, 2020 at 7:47 AM Tom Lane wrote:
>
> David Rowley writes:
> > I don't believe any of the current buildfarm failures can be
> > attributed to any of the recent changes to autovacuum, but I'll
> > continue to monitor the farm to see if anything is suspect.
>
> I agree none of the
On Sun, Mar 29, 2020 at 9:44 PM Tomas Vondra
wrote:
>
> Hi,
>
> Attached is a slightly reorganized patch series. I've merged the fixes
> into the appropriate matches, and I've also combined the two patches
> adding incremental sort paths to additional places in planner.
>
> A couple more
David Rowley writes:
> I don't believe any of the current buildfarm failures can be
> attributed to any of the recent changes to autovacuum, but I'll
> continue to monitor the farm to see if anything is suspect.
I agree none of the failures I see right now are related to that
(there's some "No
Andres Freund writes:
> On 2020-03-29 20:25:32 -0400, Tom Lane wrote:
>> I could, but it's mighty slow, so I don't especially want to try all 2^N
>> combinations. Do you have any specific cases in mind?
> I'd be most suspicious of -fstack-protector --param=ssp-buffer-size=4
> and
Hi,
On 2020-03-29 21:23:06 -0400, David Steele wrote:
> On 3/29/20 9:07 PM, Andres Freund wrote:
> > On 2020-03-29 20:42:35 -0400, Robert Haas wrote:
> > > > What do you think of having the verification process also call
> > > > pg_waldump to
> > > > validate the WAL CRCs (shown upthread)? That
On Sun, 29 Mar 2020 at 15:29, David Rowley wrote:
> I'm considering pushing the attached to try to get some confirmation
> that additional autovacuums are the issue. However, I'm not too sure
> it's a wise idea to as I can trigger an additional auto-vacuum and
> have these new tests fail with
On Fri, Mar 27, 2020 at 07:47:29AM +0900, Michael Paquier wrote:
> On Thu, Mar 26, 2020 at 06:56:36PM -0300, Alvaro Herrera wrote:
>> I don't think any such cleanup should hamper the patch at hand anyway.
>
> I don't think either, so I would do the split for the archive routines
> at least. It
On 3/29/20 9:07 PM, Andres Freund wrote:
On 2020-03-29 20:42:35 -0400, Robert Haas wrote:
What do you think of having the verification process also call pg_waldump to
validate the WAL CRCs (shown upthread)? That looked helpful and simple.
I don't love calls to external binaries, but I think
Andres Freund writes:
> Is it visibly bad when looking at the .s of gistget.c "directly", or
> when disassembling the fiinal binary? Because I've seen linkers screw up
> on a larger scale than I'd have expected in the past.
Yes, the bogus asm that I showed was from gistget.s, not from
Hi,
On 2020-03-29 20:42:35 -0400, Robert Haas wrote:
> > What do you think of having the verification process also call pg_waldump to
> > validate the WAL CRCs (shown upthread)? That looked helpful and simple.
>
> I don't love calls to external binaries, but I think the thing that
> really
On 3/29/20 8:47 PM, Robert Haas wrote:
On Fri, Mar 27, 2020 at 4:02 PM David Steele wrote:
I prefer to validate the size and checksum in the same pass, but I'm not
sure it's that big a deal. If the backup is being corrupted under the
validate process that would also apply to files that had
Hi,
On 2020-03-29 20:47:40 -0400, Robert Haas wrote:
> Maybe that was the wrong idea, but I thought people would like the
> idea of running cheaper checks first. I wasn't worried about
> concurrent modification of the backup because then you're super-hosed
> no matter what.
I do like that
Hello.
At Sat, 28 Mar 2020 19:04:00 -0300, Ranier Vilela wrote
in
> Hi,
> This patch fixes some redundant initilization, that are safe to remove.
> diff --git a/src/backend/access/gist/gistxlog.c
> b/src/backend/access/gist/gistxlog.c
> index d3f3a7b803..ffaa2b1ab4 100644
> ---
Hi,
On 2020-03-29 20:25:32 -0400, Tom Lane wrote:
> Andres Freund writes:
> > If you still have the environment it might make sense to check wether
> > it's related to one of the other options. But otherwise I wouldn't be
> > against the proposal.
>
> I could, but it's mighty slow, so I don't
On 3/29/20 8:42 PM, Robert Haas wrote:
On Sat, Mar 28, 2020 at 11:40 PM Noah Misch wrote:
I don't see this freed anywhere; is it? (It's useful to make peak memory
consumption not grow in proportion to the number of files backed up.)
We need the hash table to remain populated for the whole
I wrote:
> My main complaint about it remains the same, that it changes a
> disturbingly large number of existing regression-test results,
> suggesting that there's not a meeting of the minds about what
> this logic is supposed to do. Maybe it's okay or maybe it's
> not, but who's going to
On 3/29/20 8:33 PM, Robert Haas wrote:
On Fri, Mar 27, 2020 at 4:32 PM Andres Freund wrote:
FWIW, I was thinking of backup_manifest.checksum potentially being
desirable for another reason: The need to embed the checksum inside the
document imo adds a fair bit of rigidity to the file format.
On Fri, Mar 27, 2020 at 4:02 PM David Steele wrote:
> I prefer to validate the size and checksum in the same pass, but I'm not
> sure it's that big a deal. If the backup is being corrupted under the
> validate process that would also apply to files that had already been
> validated.
I did it
On Sat, Mar 28, 2020 at 11:40 PM Noah Misch wrote:
> Stephen Frost mentioned that a backup could pass validation even if
> pg_basebackup were killed after writing the base backup and before finishing
> the writing of pg_wal. One might avoid that by simply writing the manifest to
> a temporary
On Fri, Mar 27, 2020 at 4:32 PM Andres Freund wrote:
> I don't like having a file format that's intended to be used by external
> tools too that's undocumented except for code that assembles it in a
> piecemeal fashion. Do you mean in a follow-on patch this release, or
> later? I don't have a
Andres Freund writes:
> On 2020-03-28 23:50:32 -0400, Tom Lane wrote:
>> ... Curiously, its sibling
>> skate is *not* failing, despite being on the same machine and compiler.
> Hm. There's some difference in code-gen specific options.
Yeah, I confirmed that on my VM install too: using our
Hi,
On 2018-10-03 15:37:25 -0700, Andres Freund wrote:
> Joerg reported on IRC that after a DROP DATABASE the space of the
> dropped database wasn't available to the OS until he killed a session
> that was active from before the drop. I was kinda incredulous at first,
> the code looks sane...
Hi,
On 2020-03-28 23:50:32 -0400, Tom Lane wrote:
> Buildfarm member snapper has been crashing in the core regression tests
> since commit 17a28b0364 (well, there's a bit of a range of uncertainty
> there, but 17a28b0364 looks to be the only such commit that could have
> affected code in
On Sun, Mar 29, 2020 at 11:50:10AM -0700, Andres Freund wrote:
Hi,
On March 29, 2020 11:24:32 AM PDT, Alexander Korotkov
wrote:
clearly a big win on majority
of workloads, I think we still need to investigate different workloads
on different hardware to ensure there is no regression.
Hi,
On 2020-03-29 15:20:01 -0700, Peter Geoghegan wrote:
> On Sat, Mar 28, 2020 at 2:30 PM Andres Freund wrote:
> > Unless somebody has a better idea for how to solve this in a
> > back-paptchable way, I think it'd be best to replace RecentGlobalXmin
> > with RecentXmin. That'd be safe as far as
On Sat, Mar 28, 2020 at 2:30 PM Andres Freund wrote:
> Unless somebody has a better idea for how to solve this in a
> back-paptchable way, I think it'd be best to replace RecentGlobalXmin
> with RecentXmin. That'd be safe as far as I can see.
As far as I can tell, the worst consequence of this
On 03/29/20 15:18, Kartik Ohri wrote:
> Hi! I have shared the proposal with him directly. But as I was made aware
> that the project's prospective mentors are not at much liberty to give
> feedback on the proposal due to mentor guidelines, I wished if someone else
I'll add to that in case I could
Greetings hackers.
While working on first-class support for PG collations in the Entity
Framework Core ORM, I've come across an interesting problem: it doesn't
seem to be possible to create a database with a collation that isn't
predefined, and there doesn't seem to be a way to add to that list.
On Sun, Mar 29, 2020 at 01:22:04PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > On Sun, Mar 29, 2020 at 12:37:05PM -0400, Tom Lane wrote:
> >> After looking at the callers of pg_ls_dir_files, and noticing that
> >> it's already defined to ignore anything that's not a regular file,
> >> I
Hi! I have shared the proposal with him directly. But as I was made aware
that the project's prospective mentors are not at much liberty to give
feedback on the proposal due to mentor guidelines, I wished if someone else
could give some feedback (even some general feedback for submitting a
Greetings,
* Kartik Ohri (kartikohr...@gmail.com) wrote:
> Hi! Can I get some review on my GSoC proposal ?
>
> https://docs.google.com/document/d/1EiIHZjOjf6yWfGzKeHCbu8bJ6K1tCEcmPsD3i8lPXbg/edit?usp=sharing
>
Greetings,
* Denis Volkov (volkov.denis@yandex.ru) wrote:
> I want to apply to GSoC and this is my proposal draft. Please give me a
> feedback.
Great, thanks! I'd suggest you reach out to the mentors listed for this
proposal directly also to make sure they see your interest, and to chat
Hi,
On March 29, 2020 11:24:32 AM PDT, Alexander Korotkov
wrote:
> clearly a big win on majority
>of workloads, I think we still need to investigate different workloads
>on different hardware to ensure there is no regression.
Definitely. Which workloads are you thinking of? I can think of
On Sun, Mar 29, 2020 at 4:40 AM Peter Geoghegan wrote:
> On Sun, Mar 1, 2020 at 12:36 AM Andres Freund wrote:
> > The workload is a pgbench readonly, with pgbench -M prepared -c $conns
> > -j $conns -S -n for each client count. This is on a machine with 2
> > Intel(R) Xeon(R) Platinum 8168, but
On Sun, Mar 29, 2020 at 7:00 PM Tom Lane wrote:
>
> In general, I think the problem is that we might be dealing with a
> Unix-style locale string, in which the encoding name might be quite
> a few other things besides "utf8". But actually your patch works
> for that too, since what's going to
Hi,
I want to apply to GSoC and this is my proposal draft. Please give me a
feedback.
---
I am a 4-year undergraduate CS student at Ural Federal University. This fall I
met PostgreSQL and posted the first PR to WAL-G. I liked it so much that I
decided to do the graduate work related to WAL-G -
Hi,I want to apply to GSoC and this is my proposal draft. Please give me a feedback.---I am a 4-year undergraduate CS student at Ural Federal University. This fall I met PostgreSQL and posted the first PR to WAL-G. I liked it so much that I decided to do the graduate work related to WAL-G - to
Justin Pryzby writes:
> On Sun, Mar 29, 2020 at 12:37:05PM -0400, Tom Lane wrote:
>> After looking at the callers of pg_ls_dir_files, and noticing that
>> it's already defined to ignore anything that's not a regular file,
>> I think switching to lstat makes sense.
> Yea, only pg_ls_dir() shows
On Sun, Mar 29, 2020 at 12:37:05PM -0400, Tom Lane wrote:
> I wrote:
> > Justin Pryzby writes:
> >> Maybe we should lstat() the file to determine if it's a dangling link; if
> >> lstat() fails, then skip it. Currently, we use stat(), which shows
> >> metdata of
> >> a link's *target*. Maybe
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> On Sun, Mar 29, 2020 at 3:29 AM Tom Lane wrote:
>> The reason for the hack, per the comments, is that VS2015
>> omits a codepage field from the result of _create_locale();
>> and some optimism is expressed therein that Microsoft might
I wrote:
> Justin Pryzby writes:
>> Maybe we should lstat() the file to determine if it's a dangling link; if
>> lstat() fails, then skip it. Currently, we use stat(), which shows metdata
>> of
>> a link's *target*. Maybe we'd change that.
> Hm, good point that ENOENT could refer to a
On Sun, Mar 29, 2020 at 11:19:21AM +0530, Amit Kapila wrote:
On Sun, Mar 29, 2020 at 6:29 AM Tomas Vondra
wrote:
On Sat, Mar 28, 2020 at 03:29:34PM +0530, Amit Kapila wrote:
>On Sat, Mar 28, 2020 at 2:19 PM Dilip Kumar wrote:
>
>How about if instead of writing an XLOG_XACT_ASSIGNMENT WAL, we
On Sun, Mar 29, 2020 at 10:22:25AM +0100, Dean Rasheed wrote:
On Sat, 28 Mar 2020 at 13:18, Dean Rasheed wrote:
OK, I've pushed that with your recommendation for that function name.
Does this now complete everything that you wanted to do for functional
dependency stats for PG13? Re-reading
Hi All,
I've took some time today to rebase the patch with master. Follows attached.
I'm still not sure if the chosen path is the best way. But I'd be glad to
follow any directions we all see fit.
For now, this patch applies two methods:
1. Changes full constraint definition (which keeps
On Sun, Mar 29, 2020 at 11:56 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-03-24 15:34, Juan José Santamaría Flecha wrote:
> > I think there is also some value in adding the functionality proposed in
> > terminal_supports_color().
>
> What do you want to do with that
Hi Amit,
Sorry I just noticed your mail.
On Sun, Mar 29, 2020 at 05:12:16PM +0530, Amit Kapila wrote:
> On Sun, Mar 29, 2020 at 1:26 PM Julien Rouhaud wrote:
> >
> > I'm not sure that I get your point. I'm assuming that you meant
> > parallel-read-only queries, but surely buffer usage
On Mon, Mar 23, 2020 at 11:24:50PM +0900, Fujii Masao wrote:
>
> > Here are the comments for 0001 patch.
> >
> > + /*
> > + * Report a full page image constructed for the WAL record
> > + */
> > + pgWalUsage.wal_fp_records++;
> >
> > Isn't it better
On Sun, 29 Mar 2020 at 20:15, Amit Kapila wrote:
>
> On Sun, Mar 29, 2020 at 1:44 PM Julien Rouhaud wrote:
> >
> > On Sun, Mar 29, 2020 at 9:52 AM Masahiko Sawada
> > wrote:
> > >
> > > I've run vacuum with/without parallel workers on the table having 5
> > > indexes. The vacuum reads all
On Sun, Mar 29, 2020 at 1:26 PM Julien Rouhaud wrote:
>
> I'm not sure that I get your point. I'm assuming that you meant
> parallel-read-only queries, but surely buffer usage infrastructure for
> parallel query relies on the same approach as non-parallel one (each node
> computes the
On Sun, Mar 29, 2020 at 1:44 PM Julien Rouhaud wrote:
>
> On Sun, Mar 29, 2020 at 9:52 AM Masahiko Sawada
> wrote:
> >
> > I've run vacuum with/without parallel workers on the table having 5
> > indexes. The vacuum reads all blocks of table and indexes.
> >
> > * VACUUM command with no parallel
On 2020-03-24 15:34, Juan José Santamaría Flecha wrote:
I think there is also some value in adding the functionality proposed in
terminal_supports_color().
What do you want to do with that functionality?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 2020-03-26 07:36, Michael Paquier wrote:
I am not sure that deleting all the mentions would be a good idea, as
we'd lose track of which tool supports coloring or not, and that could
confuse users. What about switching the existing paragraph to a
simple sentence with a link to the new
On 27.03.20 21:12, Justin Pryzby wrote:
On Fri, Mar 20, 2020 at 11:32:25PM +0100, Jürgen Purtz wrote:
+Archiver
Can you change that to archiver process ?
I prefer the short term without the addition of 'process' - concerning
'Archiver' as well as the other cases. But I'm not an native
On Sat, 28 Mar 2020 at 13:18, Dean Rasheed wrote:
>
> OK, I've pushed that with your recommendation for that function name.
>
Does this now complete everything that you wanted to do for functional
dependency stats for PG13? Re-reading the thread, I couldn't see
anything else that needed looking
On Sun, Mar 29, 2020 at 3:29 AM Tom Lane wrote:
>
> The reason for the hack, per the comments, is that VS2015
> omits a codepage field from the result of _create_locale();
> and some optimism is expressed therein that Microsoft might
> undo that oversight in future. Has this been fixed in more
On Sun, Mar 29, 2020 at 9:52 AM Masahiko Sawada
wrote:
>
> On Sun, 29 Mar 2020 at 15:19, Masahiko Sawada
> wrote:
> >
> > On Sun, 29 Mar 2020 at 14:23, Amit Kapila wrote:
> > >
> > > On Sat, Mar 28, 2020 at 8:47 PM Julien Rouhaud wrote:
> > > >
> > > > On Sat, Mar 28, 2020 at 02:38:27PM +0100,
On Sun, Mar 29, 2020 at 11:03:50AM +0530, Amit Kapila wrote:
> On Sat, Mar 28, 2020 at 7:08 PM Julien Rouhaud wrote:
> >
> > On Sat, Mar 28, 2020 at 04:14:04PM +0530, Amit Kapila wrote:
> > >
> > > Basically,
> > > I don't know changes done in ExecInitParallelPlan and friends allow us
> > > to
On Sun, 29 Mar 2020 at 15:19, Masahiko Sawada
wrote:
>
> On Sun, 29 Mar 2020 at 14:23, Amit Kapila wrote:
> >
> > On Sat, Mar 28, 2020 at 8:47 PM Julien Rouhaud wrote:
> > >
> > > On Sat, Mar 28, 2020 at 02:38:27PM +0100, Julien Rouhaud wrote:
> > > > On Sat, Mar 28, 2020 at 04:14:04PM +0530,
>
>
>> Just update the patch which do some test case changes.
> 1.add "ANALYZE" command before running the explain.
> 2.order by with an explicit collate settings.
>
Thanks Rushabh for pointing this out, or else I'd spend much more time to
figure
out why I get a different order on
On Sun, 29 Mar 2020 at 14:23, Amit Kapila wrote:
>
> On Sat, Mar 28, 2020 at 8:47 PM Julien Rouhaud wrote:
> >
> > On Sat, Mar 28, 2020 at 02:38:27PM +0100, Julien Rouhaud wrote:
> > > On Sat, Mar 28, 2020 at 04:14:04PM +0530, Amit Kapila wrote:
> > > >
> > > > I see some basic problems with the
On Fri, Mar 27, 2020 at 03:42:50PM +0100, Julien Rouhaud wrote:
> On Fri, Mar 27, 2020 at 2:01 PM Fujii Masao
> wrote:
> >
>
> > So what I'd like to say is that the information that users are interested
> > in would vary on each situation and case. At least for me it seems
> > enough for pgss
On Sun, Mar 29, 2020 at 9:04 AM Masahiko Sawada
wrote:
>
> On Sat, 28 Mar 2020 at 13:23, Amit Kapila wrote:
> >
> >
> > Please find attached the updated patch with all the changes discussed.
> > Let me know if I have missed anything?
> >
>
> Thank you for updating the patch! Looks good to me.
>
78 matches
Mail list logo
