Hey Michael,
Really appreciate the review!
On Wed, Aug 11, 2021 at 12:40 AM Michael Paquier wrote:
> Agreed that the current behavior is confusing. As you are using the
> commit timestamp for the comparison, this is right. One small-ish
> comment I have about the code is that we should mentio
Hi Drouvot,
I don't see extra data in your output and it looks like your
copy/paste is missing some content, no?
On my side, that looks good and here is what i get with the patch applied:
I ran the test again, now I got the same output as yours, and it looks
good for me. (The issue I mention
Here is a proposal for 14. This patch has four main changes:
* The mod counts are only propagated to the topmost parent, not to each
ancestor. This means that we'll only analyze the topmost partitioned table and
not each intermediate partitioned table; seems a good compromise to avoid
samplin
On Friday, August 13, 2021, Tom Lane wrote:
>
> The one thing I could potentially see us doing is more strongly
> encouraging the use of the names "timestamp" and "timestamptz",
> up to and including changing what format_type() et al. put out.
+1. Having the canonical form be timestamptz would
Andres Freund writes:
> On 2021-08-13 13:37:02 -0400, Tom Lane wrote:
>> so it seems like someday we might want to expend some effort on native
>> atomics. I agree that that day need not be today, though. This patch
>> seems sufficient until we get to the point of (at least) having some
>> RISC-
Hi,
On 2021-08-13 13:37:02 -0400, Tom Lane wrote:
> "Andres Freund" writes:
> > On Fri, Aug 13, 2021, at 19:25, Tom Lane wrote:
> >> I now have looked at the patch, and it seems good as far as it goes,
> >> but I wonder whether some effort ought to be expended in
> >> src/include/port/atomics/.
>
"Andres Freund" writes:
> On Fri, Aug 13, 2021, at 19:25, Tom Lane wrote:
>> I now have looked at the patch, and it seems good as far as it goes,
>> but I wonder whether some effort ought to be expended in
>> src/include/port/atomics/.
> That should automatically pick up the intrinsic. I think we
Hi,
On Fri, Aug 13, 2021, at 19:25, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> Should we backpatch this? It's not like we're going to break existing
> >> risc-v systems by enabling spinlock support...
>
> > Yeah, why not? If you were building with --disable-spinlocks before,
> >
I wrote:
> Andres Freund writes:
>> Should we backpatch this? It's not like we're going to break existing
>> risc-v systems by enabling spinlock support...
> Yeah, why not? If you were building with --disable-spinlocks before,
> this shouldn't change anything for you.
> (I haven't actually looke
"David G. Johnston" writes:
> On Fri, Aug 13, 2021 at 9:28 AM Simon Riggs
> wrote:
>> The only hope is to eventually change the default, so probably
>> the best thing is to apply pressure via the SQL Std process.
> Then there is no hope because this makes the situation worse.
Agreed; the points
On Fri, Aug 13, 2021 at 9:28 AM Simon Riggs
wrote:
>
> The only hope is to eventually change the default, so probably
> the best thing is to apply pressure via the SQL Std process.
>
>
Then there is no hope because this makes the situation worse.
If anything I'd suggest the SQL standard should p
Em sex., 13 de ago. de 2021 às 11:55, Ram Charan Kallem <
ramcharan.kal...@non.se.com> escreveu:
> Hi,
>
>
>
> We are using Postgres 10 (Single client)and observed that there are
> multiple PostgreSQL Server process are running in background.
>
> Why these additional process are created or is thi
On Fri, 13 Aug 2021 at 17:23, Andrew Dunstan wrote:
> What do other DBMSs do?
I think MySQL defaults to WITH TIME ZONE, not sure, but I would bet a
few others follow the standard.
> This strikes me as primarily an education issue
> (I did a webinar on it not that long ago)
Yes, agreed.
> If y
On 8/12/21 7:25 PM, Simon Riggs wrote:
> I thought we found that changing behavior via GUC usually ends badly.
>> Yeah. Changing from SQL-spec to not-SQL-spec behavior is going to be
>> one tough sell to begin with, even without the point that that's been
>> our behavior for over two decades. B
Both bugs #16676[1] and #17141[2] illustrate that the combination of SKIP
LOCKED and FETCH FIRST
WITH TIES break expectations when it comes to rows returned to other
sessions accessing the same
row. Since this situation is detectable from the syntax and hard to fix
otherwise, forbid for now,
with
Andres Freund writes:
> On 2021-08-13 11:09:04 -0400, Tom Lane wrote:
>> Marek Szuba writes:
>>> Tested against PostgreSQL 13.3 on a physical rv64gc system (BeagleV
>>> Starlight beta board) - builds and installs fine, all tests pass.
> Should we backpatch this? It's not like we're going to brea
Hi,
(dropping -committers to avoid moderation stalls due xposting to multiple lists
-
I find that more annoying than helpful)
On 2021-08-13 14:38:37 +0530, Amit Kapila wrote:
> > What I'm wondering is why it is a good idea to have a SharedFileSet specific
> > cleanup mechanism. One that only ope
On Fri, Aug 13, 2021 at 07:09:15AM -0700, David G. Johnston wrote:
> On Fri, Aug 13, 2021 at 12:33 AM Gavin Flower
> wrote:
>
>
> I always use the tz version, except when I forget.
>
>
> I find it nearly impossible for me to forget how this works. But that is
> probably because I just pre
Hi,
On 2021-08-13 11:09:04 -0400, Tom Lane wrote:
> Marek Szuba writes:
> > Tested against PostgreSQL 13.3 on a physical rv64gc system (BeagleV
> > Starlight beta board) - builds and installs fine, all tests pass.
Seems like a good idea to me.
> Cool ... I had hoped to acquire one of those myse
Marek Szuba writes:
> Tested against PostgreSQL 13.3 on a physical rv64gc system (BeagleV
> Starlight beta board) - builds and installs fine, all tests pass.
Cool ... I had hoped to acquire one of those myself, but I didn't
make the cut.
regards, tom lane
Hello,
The attached patch adds native spinlock support to PostgreSQL on RISC-V
systems. As suspected by Richard W.M. Jones of Red Hat back in 2016, the
__sync_lock_test_and_set() approach applied on arm and arm64 works here
as well.
Tested against PostgreSQL 13.3 on a physical rv64gc system
Hi,
We are using Postgres 10 (Single client)and observed that there are multiple
PostgreSQL Server process are running in background.
Why these additional process are created or is this an expected behavior.
[cid:image001.png@01D7905A.F629F440]
Regards,
RamCharan
On Thu, Aug 12, 2021 at 6:24 PM Andres Freund wrote:
>
> On 2021-08-12 05:48:19 -0700, Andres Freund wrote:
> > I think SharedFileSetInit() needs a comment explaining that it needs to be
> > called in a process-lifetime memory context if used without dsm
> > segments. Because otherwise SharedFileS
On Thu, Aug 12, 2021 at 6:18 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-08-12 15:06:23 +0530, Amit Kapila wrote:
> > On Thu, Aug 12, 2021 at 1:52 PM Andres Freund wrote:
> > > I'm not so sure. Why does sharedfileset have its own proc exit hook in the
> > > first place? ISTM that this should be d
Alexander Kukushkin writes:
> IMO is totally wrong, because the actual value didn't change: it was an
> empty string in the config and now it remains an empty string due to the
> default value in the guc.c
I can't get very excited about that. The existing message about
"parameter \"%s\" cannot b
Hi Alvaro,
On Tue, 27 Jul 2021 at 22:17, Alvaro Herrera
wrote:
> I tested this -- it works correctly AFAICS.
>
Nope, IMO it doesn't work correctly.
Lets say we have recovery_target = '' in the config:
localhost/postgres=# select name, setting, setting is null, pending_restart
from pg_settings
On Fri, Aug 13, 2021 at 12:33 AM Gavin Flower
wrote:
>
> I always use the tz version, except when I forget.
I find it nearly impossible for me to forget how this works. But that is
probably because I just pretend that the standard, multi-word, data types
don't even exist. It's not that "times
Hello,
The logging system already captures a lot of information in the ErrorData. But
at present there is no way for a log message authors to include more metadata
about the log outside of the log message itself. For example, including the
extension name which can be useful for filtering / disp
Hi,
Magnus, Michael, Anyone - I'd appreciate a look.
On 2021-03-05 12:55:37 -0800, Andres Freund wrote:
> > After fighting with a windows VM for a bit (ugh), it turns out that yes,
> > there is stderr, but that fileno(stderr) returns -2, and
> > GetStdHandle(STD_ERROR_HANDLE) returns NULL (not IN
On 2021-08-05 19:56:49 -0700, Andres Freund wrote:
> Done in the attached patch. I don't think we need to add more to the docs than
> the flag being required?
Pushed that patch now. If we want further additions to the docs we can
do so separately.
On Wed, Aug 11, 2021 at 03:14:11PM +0900, Michael Paquier wrote:
> I would just tweak the comment block at the top of what's being
> changed, as per the attached. Please let me know if there are any
> objections.
And applied as of 710796f.
--
Michael
signature.asc
Description: PGP signature
Le 13/08/2021 à 11:58, Andres Freund a écrit :
> Hi,
>
> On 2021-08-10 10:12:26 +0200, Gilles Darold wrote:
>> Sorry for the response delay. I have though about adding this odd hook to be
>> able to implement this feature through an extension because I don't think
>> this is something that should b
On Fri, Aug 13, 2021 at 10:52:50AM +0200, Peter Eisentraut wrote:
> On 12.08.21 16:18, Julien Rouhaud wrote:
> >
> > But changing RequestAddinShmemSpace() to apply CACHELINEALIGN() would
> > only really work for that specific usage only? If an extension does
> > multiple allocations you can't rel
On 2021-08-13 14:40:08 +0300, Yura Sokolov wrote:
> Ranier Vilela писал 2021-08-13 14:12:
> > Em sex., 13 de ago. de 2021 às 07:15, Andres Freund
> > escreveu:
> > > Personally I find it more obvious to understand the intended
> > > behaviour
> > > with ~0 (i.e. all bits set) than with a width t
Ranier Vilela писал 2021-08-13 14:12:
Em sex., 13 de ago. de 2021 às 07:15, Andres Freund
escreveu:
Hi,
On 2021-08-13 12:44:17 +0300, Yura Sokolov wrote:
Andres Freund писал 2021-08-13 12:21:
Any chance you'd write a test for simplehash with such huge
amount of
values? It'd require a smal
Em sex., 13 de ago. de 2021 às 07:15, Andres Freund
escreveu:
> Hi,
>
> On 2021-08-13 12:44:17 +0300, Yura Sokolov wrote:
> > Andres Freund писал 2021-08-13 12:21:
> > > Any chance you'd write a test for simplehash with such huge amount of
> > > values? It'd require a small bit of trickery to be
On Mon, Aug 2, 2021 at 7:20 PM Amit Kapila wrote:
>
> On Fri, Jul 23, 2021 at 3:39 PM Ajin Cherian wrote:
> >
>
> Let's first split the patch for prepared and non-prepared cases as
> that will help to focus on each of them separately. BTW, why haven't
> you considered implementing point 1b as exp
Hi,
On 2021-08-13 12:44:17 +0300, Yura Sokolov wrote:
> Andres Freund писал 2021-08-13 12:21:
> > Any chance you'd write a test for simplehash with such huge amount of
> > values? It'd require a small bit of trickery to be practical. On systems
> > with MAP_NORESERVE it should be feasible.
>
> Wh
Hi,
On 2021-08-11 16:11:34 -0400, Melanie Plageman wrote:
> On Tue, Aug 3, 2021 at 2:13 PM Andres Freund wrote:
> > > Also, I'm unsure how writing the buffer action stats out in
> > > pgstat_write_statsfiles() will work, since I think that backends can
> > > update their buffer action stats after
Hi,
On 2021-08-10 10:12:26 +0200, Gilles Darold wrote:
> Sorry for the response delay. I have though about adding this odd hook to be
> able to implement this feature through an extension because I don't think
> this is something that should be implemented in core. There were also
> patches propos
Andres Freund писал 2021-08-13 12:21:
Hi,
On 2021-08-10 11:52:59 +0300, Yura Sokolov wrote:
- sizemask is set only in SH_COMPUTE_PARAMETERS . And it is set in
this way:
/* now set size */
tb->size = size;
if (tb->size == SH_MAX_SIZE)
tb->sizemask = 0;
Hi,
On 2021-08-11 18:33:07 -0400, Alvaro Herrera wrote:
> After thinking about the described issues for a while, my proposal is to
> completely revamp the way this feature works. See below.
>
> Now, the proposal seems awfully invasive, but it's *the* way I see to
> avoid the pgstat traffic. For
Hi,
On 2021-08-10 11:52:59 +0300, Yura Sokolov wrote:
> - sizemask is set only in SH_COMPUTE_PARAMETERS . And it is set in this way:
>
> /* now set size */
> tb->size = size;
>
> if (tb->size == SH_MAX_SIZE)
> tb->sizemask = 0;
> else
>
On Fri, Aug 13, 2021 at 11:47 AM Drouvot, Bertrand wrote:
>
> On 8/12/21 1:00 PM, Amit Kapila wrote:
> >>
> >> - sets "relwrewrite" for the toast.
> >>
> > --- a/src/backend/commands/tablecmds.c
> > +++ b/src/backend/commands/tablecmds.c
> > @@ -3861,6 +3861,10 @@ RenameRelationInternal(Oid myreli
On 12.08.21 16:18, Julien Rouhaud wrote:
On Thu, Aug 12, 2021 at 9:34 PM Peter Eisentraut
wrote:
On 27.02.21 09:08, Julien Rouhaud wrote:
PFA a patch that fixes pg_prewarm and pg_stat_statements explicit alignment to
CACHELINEALIGN, and also update the alignment in hash_estimate_size() to wha
On 13/08/21 5:14 pm, Greg Stark wrote:
I think having a GUC to change to a different set of semantics is not workable.
However that doesn't mean we can't do anything. We could have a GUC
that just disables allowing creating columns of type timestamp without
tz. That could print an error with a h
On 8/12/21 4:26 AM, Tomas Vondra wrote:
On 8/11/21 2:48 AM, Peter Geoghegan wrote:
On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
wrote:
Ivan Frolkov reported a problem with choosing a non-optimal index during
a query optimization. This problem appeared after building of an
extended statis
47 matches
Mail list logo
