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 hint suggesting you can change
the
On Wed, 11 Aug 2021 at 00:10, Yura Sokolov wrote:
> Attached v2.
Eyeballing this it looks fine, but I was a little nervous backpatching
without testing it properly, so I ended up provisioning a machine with
256GB and doing a round of testing.
I just created the most simple table I could:
On Thu, Aug 12, 2021 at 5:41 PM Greg Nancarrow wrote:
>
> On Thu, Aug 12, 2021 at 9:18 PM Amit Kapila wrote:
> >
> > > A minor comment on the 0001 patch: In the message I think that using
> > > "ID" would look better than lowercase "id" and AFAICS it's more
> > > consistent with existing
On Thu, Aug 12, 2021 at 8:30 PM Robert Haas wrote:
>
> On Thu, Aug 12, 2021 at 12:22 AM Amit Kapila wrote:
> > The design of the patch has changed since the initial proposal. It
> > tries to perform unique inserts by holding a write lock on the bucket
> > page to avoid duplicate inserts.
>
> Do
On Thu, Aug 12, 2021 at 5:54 PM Masahiko Sawada wrote:
>
> On Fri, Aug 6, 2021 at 5:33 PM vignesh C wrote:
> >
>
> ---
> Even if we drop all tables added to the publication from it, 'pubkind'
> doesn't go back to 'empty'. Is that intentional behavior? If we do
> that, we can save the lookup of
Thomas Munro writes:
> Obviously the address may have to be adjusted if Apple moves stuff
> around, or if the initial layout and ASLR slide range turn out to be
> less constrained than I inferred by nosing around the source code and
> testing on a couple of systems.
Sure. But we're no worse off
An idea just occurred to me: a systematic way to provide this feature might
be to support aliases for objects. So I could declare an alternate name for
an object, something like:
CREATE ALIAS timestamp FOR TYPE timestamptz;
Which would mean that [current schema].timestamp would now be an
On Tue, 2021-08-10 at 11:26 -0400, Tom Lane wrote:
> Yeah, I don't like that change either. It would be one thing if
> we had several places in which suppressing .SECONDARY was useful,
> but if there's only one then it seems better to design around it.
Maybe. The current Makefile already tried
On Tue, 2021-08-10 at 16:22 +0900, Michael Paquier wrote:
> Regarding 0002, I am not sure. Even if this reduces a lot of
> duplication, which is really nice, enforcing .SECONDARY to not trigger
> with a change impacting Makefile.global.in does not sound very
> appealing to me in the long-run,
On Fri, Aug 13, 2021 at 9:59 AM Tom Lane wrote:
> Hmm, ok. Small thought: it might be better to put the #if inside
> the "else { }". That way it scales easily to allow other
> platform-specific defaults if we find anything useful. As-is,
> the obvious extension would end up with multiple
On Fri, Aug 13, 2021 at 12:25:00AM +0100, 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
On Thu, 12 Aug 2021 at 20:07, Tom Lane wrote:
>
> Bruce Momjian writes:
> > On Thu, Aug 12, 2021 at 07:24:58PM +0100, Simon Riggs wrote:
> >> I heard the moan about "Why doesn't TIMESTAMP mean TIMESTAMP WITH TIME
> >> ZONE" again today, so here is something concrete to address that.
> >>
> >>
> On Aug 11, 2021, at 3:48 PM, Mark Dilger wrote:
>
> I'm working on a correlated stats test as I write this. I'll get back to you
> when I have results.
Ok, the tests showed no statistically significant regressions. All tests
included the same sorts of whereclause expressions as used in
On Thu, 2021-08-12 at 17:13 -0400, John Naylor wrote:
> The patch looks pretty good to me. I just have a stylistic suggestion
> which I've attached as a text file.
Getting rid of the "clever addition" looks much better to me, thanks. I
haven't verified the changes to the doc comment, but your
Thomas Munro writes:
> On Fri, Aug 13, 2021 at 3:13 AM Tom Lane wrote:
>> I don't see why that approach couldn't be incorporated into pg_ctl,
>> or the postmaster itself. Given Andres' point that Linux ASLR
>> disable probably has to happen in pg_ctl, it seems like doing it
>> in pg_ctl in all
On Fri, Aug 13, 2021 at 3:13 AM Tom Lane wrote:
> Robert Haas writes:
> > Ugh, OK. So, is there a way that we can get an "easy button" committed
> > to the tree?
>
> I don't see why that approach couldn't be incorporated into pg_ctl,
> or the postmaster itself. Given Andres' point that Linux
The patch looks pretty good to me. I just have a stylistic suggestion which
I've attached as a text file. There are also some outdated comments that
are not the responsibility of this patch, but I kind of want to fix them
now:
* - Hangul Jamo medial vowels and final consonants (U+1160-U+11FF)
Bruce Momjian writes:
> On Thu, Aug 12, 2021 at 07:24:58PM +0100, Simon Riggs wrote:
>> I heard the moan about "Why doesn't TIMESTAMP mean TIMESTAMP WITH TIME
>> ZONE" again today, so here is something concrete to address that.
>>
>> AFAIK, SQL Standard requires the default to be WITHOUT TIME
On Thu, Aug 12, 2021 at 07:24:58PM +0100, Simon Riggs wrote:
> I heard the moan about "Why doesn't TIMESTAMP mean TIMESTAMP WITH TIME
> ZONE" again today, so here is something concrete to address that.
>
> AFAIK, SQL Standard requires the default to be WITHOUT TIME ZONE, but
> nobody seems to
I heard the moan about "Why doesn't TIMESTAMP mean TIMESTAMP WITH TIME
ZONE" again today, so here is something concrete to address that.
AFAIK, SQL Standard requires the default to be WITHOUT TIME ZONE, but
nobody seems to think that is useful. We even added a specially
optimized ALTER TABLE
On Thu, Aug 12, 2021 at 12:46 PM Pavel Stehule
wrote:
> did you run make clean?
>
> when I executed just patch & make, it didn't work
I did not, but I always have --enable-depend on. I tried again with make
clean, and ccache -C just in case, and it works now.
On Thu, Aug 12, 2021 at 12:54 PM
On Thu, Aug 12, 2021 at 1:26 AM David Rowley wrote:
> Closer, but I don't see why there's any need to make the fast and slow
> functions external. It should be perfectly fine to keep them static.
>
> I didn't test the performance, but the attached works for me.
Thanks for that! I still get a
> No, you're right, although I think it's implied. Maybe we need a
> statement along these lines:
>
>
> Committers are responsible for the resolution of open items that
> relate
> to commits they have made. Action needs to be taken in a timely
> fashion,
> and if there is any substantial delay
On Thu, 2021-08-12 at 12:36 -0400, John Naylor wrote:
> I tried this patch on and MacOS11/iterm2 and RHEL 7 (ssh'd from the Mac, in
> case that matters) and the example shown at the top of the thread shows no
> difference:
>
> john.naylor=# \pset border 2
> Border style is 2.
> john.naylor=#
čt 12. 8. 2021 v 18:36 odesílatel John Naylor
napsal:
> I tried this patch on and MacOS11/iterm2 and RHEL 7 (ssh'd from the Mac,
> in case that matters) and the example shown at the top of the thread shows
> no difference:
>
> john.naylor=# \pset border 2
> Border style is 2.
> john.naylor=#
I tried this patch on and MacOS11/iterm2 and RHEL 7 (ssh'd from the Mac, in
case that matters) and the example shown at the top of the thread shows no
difference:
john.naylor=# \pset border 2
Border style is 2.
john.naylor=# SELECT U&'\+01F603';
+--+
| ?column? |
+--+
| |
On Tue, 10 Aug 2021 10:50:20 -0400
Greg Sabino Mullane wrote:
> Apologies, just saw this. I found no problems, those "failures" were just
> me missing checkboxes on the commitfest interface. +1 on the patch.
Thank you!
--
Yugo NAGATA
On Wed, Aug 11, 2021 at 8:51 AM John Naylor
wrote:
> (Standard disclaimer that I'm not qualified to design index AMs) I've seen
> one mention in the literature about the possibility of simply having a btree
> index over the hash values. That would require faster search within pages, in
>
On Wed, Aug 11, 2021 at 10:53 PM Wu Haotian wrote:
> Maybe we can add checks like "option --clean requires plain text format"?
> If so, should I start a new mail thread for this?
>
Shrug. To me, that seems related enough it could go into the existing
patch/thread.
Cheers,
Greg
On Wed, Aug 11, 2021 at 10:08 AM Tom Lane wrote:
> You must not have enabled EXEC_BACKEND properly. It's a compile-time
> #define that affects multiple modules, so it's easy to get wrong.
> The way I usually turn it on is
>
Thank you. I was able to get it all working, and withdraw any
Hi,
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 SharedFileSetDeleteOnProcExit() will access
> already freed memory
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 dealt with using resowners, rathers
> > than
> > a sharedfileset
On Thu, Aug 12, 2021 at 1:52 PM Andres Freund wrote:
>
> On 2021-08-12 11:46:09 +0530, Amit Kapila wrote:
> > On Thu, Aug 12, 2021 at 11:38 AM Dilip Kumar wrote:
> > > On Thu, Aug 12, 2021 at 7:39 AM Masahiko Sawada
> > > wrote:
> > > > It seems to me that moving the shared fileset cleanup to
Hi,
On 2021-08-12 11:46:09 +0530, Amit Kapila wrote:
> On Thu, Aug 12, 2021 at 11:38 AM Dilip Kumar wrote:
> > On Thu, Aug 12, 2021 at 7:39 AM Masahiko Sawada
> > wrote:
> > > It seems to me that moving the shared fileset cleanup to
> > > before_shmem_exit() is the right approach to fix this
Jordan Gigov writes:
> A recent thread gave me the idea that it would be convenient to have
> another flag for `regexp_matches` to make it return a singular
> two-dimensional array of matches when performing a global match.
> Why? Well, basically you avoid having to aggregate the rows afterwards
A recent thread gave me the idea that it would be convenient to have
another flag for `regexp_matches` to make it return a singular
two-dimensional array of matches when performing a global match.
Why? Well, basically you avoid having to aggregate the rows afterwards
using by wrapping it in a
Robert Haas writes:
> On Wed, Aug 11, 2021 at 6:24 PM Thomas Munro wrote:
>> ... I think just doing
>> something like (/me rolls dice) export PG_SHMEM_ADDR=0x800 is
>> a good candidate for something that works on both architectures, being
>> many TB away from everything else (above
On Thu, Aug 12, 2021 at 12:22 AM Amit Kapila wrote:
> The design of the patch has changed since the initial proposal. It
> tries to perform unique inserts by holding a write lock on the bucket
> page to avoid duplicate inserts.
Do you mean that you're holding a buffer lwlock while you search the
On Wed, Aug 11, 2021 at 6:24 PM Thomas Munro wrote:
> On Thu, Aug 12, 2021 at 1:45 AM Robert Haas wrote:
> > I think that worked for me on older macOS releases, and then it
> > stopped working at some point after some update or reinstall or
> > something. Unfortunately I don't know any more
On Thu, Aug 12, 2021 at 7:40 AM Nitin Jadhav
wrote:
> > I suggest making the GUC GUC_UNIT_MS rather than GUC_UNIT_S, but
> > expressing the default in postgresl.conf.sample as 10s rather than
> > 1ms. I tried values measured in milliseconds just for testing
> > purposes and didn't initially
On 2021-Aug-13, David Rowley wrote:
> Maybe you saw that there's no such equivalent test when we set
> HAVE_X86_64_POPCNTQ for MSVC on x86_64. The reason for that is that
> we do the run-time test using cpuid.
Yeah, that and also I mistook the two independent "ifdef" blocks for one
block with
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
> > what I
> > think
On Thu, Aug 12, 2021 at 9:33 AM David Rowley wrote:
> Something there that might cause confusion is we do a configure check
> to see if popcntq works and define HAVE_X86_64_POPCNTQ if it does.
> I'm still a bit confused at why we bother doing that. Surely it just
> means that if the build
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 what I
think ShmemInitHash will actually consume.
For extensions, wouldn't it make things better if
On Fri, 13 Aug 2021 at 01:28, David Rowley wrote:
>
> On Fri, 13 Aug 2021 at 01:11, Alvaro Herrera wrote:
> > So when on MSVC, you don't have to check CPUID for support?
>
> That still needs to be checked in MSVC and as far as I can see it is
> being properly checked.
Something there that might
> On 12 Aug 2021, at 12:00, Itamar Gafni wrote:
> Copying it means there are two BIO_METHOD objects with the same type (ortig
> socket and its copy) but it's unclear if that's an issue.
Reading code there doesn't seem to be a concensus really, Apple is doing it in
the Swift TLS code but
On Fri, 13 Aug 2021 at 01:11, Alvaro Herrera wrote:
> So when on MSVC, you don't have to check CPUID for support?
That still needs to be checked in MSVC and as far as I can see it is
being properly checked.
David
So when on MSVC, you don't have to check CPUID for support?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)
On Thu, Aug 12, 2021 at 4:40 AM Dilip Kumar wrote:
>
> While reading through the README of the hash index I noticed a grammar
> error, the attached patch fixes the same.
LGTM, pushed.
--
John Naylor
EDB: http://www.enterprisedb.com
On Fri, Aug 6, 2021 at 5:33 PM vignesh C wrote:
>
> Thanks for the comments, the attached v19 patch has the fixes for the
> comments.
Thank you for updating the patch!
Here are some comments on v19 patch:
+case OCLASS_PUBLICATION_SCHEMA:
+
On Thu, Aug 12, 2021 at 9:18 PM Amit Kapila wrote:
>
> > A minor comment on the 0001 patch: In the message I think that using
> > "ID" would look better than lowercase "id" and AFAICS it's more
> > consistent with existing messages.
> >
> > + appendStringInfo(, _(" in transaction id %u with
Not sure what is the expected use with previous versions. It used to be that
the BIO_s_socket() would return a non-const pointer, so the original socket
methods object could be edited.
Copying it means there are two BIO_METHOD objects with the same type (ortig
socket and its copy) but it's
Hi,
Thanks for the feedback.
The possible path that archiver can take for each cycle is either a fast
path or a fall-back patch. The fast path involves checking availability of
next anticipated log segment and decide the next target for archival or
a fall-back path which involves full directory
> startup_progress_timer_expired should be declared as sig_atomic_t like
> we do in other cases (see interrupt.c).
Fixed.
> The default value of the new GUC is 10s in postgresql.conf.sample, but
> -1 in guc.c. They should both be 10s, and the one in
> postgresql.conf.sample should be commented
On Thu, Aug 12, 2021 at 4:30 PM Amit Kapila wrote:
>
> On Tue, Aug 10, 2021 at 5:30 PM Drouvot, Bertrand wrote:
> >
> >
> > Please find attached the new version that:
> >
> > - sets "relwrewrite" for the toast.
> >
>
> --- a/src/backend/commands/tablecmds.c
> +++
On Thu, Aug 12, 2021 at 1:21 PM Greg Nancarrow wrote:
>
> On Thu, Aug 12, 2021 at 3:54 PM Masahiko Sawada wrote:
> >
> > I've attached the updated patches. FYI I've included the patch
> > (v8-0005) that fixes the assertion failure during shared fileset
> > cleanup to make cfbot tests happy.
> >
On Tue, Aug 10, 2021 at 5:30 PM Drouvot, Bertrand wrote:
>
> Hi Amit,
>
> On 8/9/21 1:12 PM, Amit Kapila wrote:
> > On Mon, Aug 9, 2021 at 3:37 PM Drouvot, Bertrand
> > wrote:
> >> Hi Amit,
> >>
> >> On 8/9/21 10:37 AM, Amit Kapila wrote:
> >>> On Fri, Jul 9, 2021 at 12:22 PM Drouvot, Bertrand
On Thu, Aug 12, 2021 at 12:15 PM Drouvot, Bertrand wrote:
>
> On 8/10/21 1:59 PM, Drouvot, Bertrand wrote:
> > Hi Amit,
> >
>
> The first version of the patch contained a change in
> ReorderBufferToastReplace() (to put the call to
> RelationIsValid(toast_rel) and display the error message when it
On Mon, Aug 9, 2021 at 1:53 PM Amit Kapila wrote:
>
> On Sun, Aug 8, 2021 at 2:52 PM vignesh C wrote:
> >
> > On Fri, Aug 6, 2021 at 4:39 PM Amit Kapila wrote:
> > >
> > > On Fri, Aug 6, 2021 at 2:02 PM vignesh C wrote:
> > > >
> > > > On Wed, Aug 4, 2021 at 4:10 PM Amit Kapila
> > > >
While reading through the README of the hash index I noticed a grammar
error, the attached patch fixes the same.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 2760cd42e7f6354399d30ac56741268130f6e017 Mon Sep 17 00:00:00 2001
From: Dilip Kumar
Date: Thu, 12 Aug 2021
On Thu, Aug 12, 2021 at 8:40 AM Rahila Syed wrote:
>
>>
>> Can you please explain why you have the restriction for including
>> replica identity columns and do we want to put a similar restriction
>> for the primary key? As far as I understand, if we allow default
>> values on subscribers for
On Thu, Aug 12, 2021 at 3:54 PM Masahiko Sawada wrote:
>
> I've attached the updated patches. FYI I've included the patch
> (v8-0005) that fixes the assertion failure during shared fileset
> cleanup to make cfbot tests happy.
>
A minor comment on the 0001 patch: In the message I think that using
čt 22. 7. 2021 v 0:12 odesílatel Jacob Champion
napsal:
> On Wed, 2021-07-21 at 00:08 +, Jacob Champion wrote:
> > I note that the doc comment for ucs_wcwidth()...
> >
> > > *- Spacing characters in the East Asian Wide (W) or East Asian
> > > * FullWidth (F) category as
63 matches
Mail list logo
