Hello all,
Please find attached a trivial patch making a few arrays const (in addition
to the data they point to).
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index f553523857..aafc7187b0 100644
--- a/src/backend/access/transam/xlog.c
+++
I am Yonathan Misgan from Ethiopia, want to add some functionalities on
PostgreSQL to support Ethiopian locales. I want your advice where I start to
hack the PostgresSQL source code. I have attached some synopsis about the
existing problems of PostgresSQL related with Ethiopian locale specially
Hi Hosoya-san,
I am sorry for so late to reply to you.
I merged the patches into master(commit:
44460d7017cde005d7a2e246db0b32375bfec15d).
I tested the case I used in the previous patches and didn't find any issues.
Now I find that you are rethinking some of the details.
I will
чт, 8 авг. 2019 г. в 06:18, Kyotaro Horiguchi :
>
> Hello.
>
> At Wed, 7 Aug 2019 12:14:48 +0300, Dmitry Igrishin wrote
> in
> > > -if ($lib =~ m/\s/)
> > > -{
> > > -$lib = '' . $lib . "";
> > > -}
> > > +# Since VC automatically quotes paths specified as the data of
>
> > As for the replace comment, I'm not
> > sure it is needed since I think quoting is not the task for
> > AddLibrary/AddIncludeDir in the first place (and AddIncludeDir
> > doesn't have the same comment).
The attached 3rd version of the patch contains no comment in AddLibrary().
Sorry, forgot
On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera
wrote:
> On 2019-Aug-07, Simon Riggs wrote:
>
> > I saw your recent commit and it scares me in various places, noted below.
> >
> > "Commit: Apply constraint exclusion more generally in partitioning"
> >
> > "This applies particularly to the default
Hi Ibrar, Thomas and Robert,
On 8/2/19 11:00 PM, Ibrar Ahmed wrote:
> I have rebased the patch and currently reviewing the patch
> on master (1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012).
Thanks a lot for your effort. We are now trying to put again more work
and time in this patch.
We are grateful
Hi Amul,
On Thu, Aug 8, 2019 at 4:15 PM amul sul wrote:
>
> Hi,
>
> In RelationBuildPartitionDesc(), a memory space that use to gather
> partitioning
> bound info wasn't free at the end. This might not a problem because this
> allocated memory will eventually be recovered when the top-level
On 08.08.2019 5:40, Craig Ringer wrote:
On Tue, 6 Aug 2019 at 16:32, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
New version of the patch with several fixes is attached.
Many thanks to Roman Zharkov for testing.
FWIW I still don't understand your argument with
On Thu, 8 Aug 2019 at 12:18, Andres Freund wrote:
> Hi,
>
> On 2019-08-08 11:36:44 +0800, Craig Ringer wrote:
> > > you can only put one into the first element of a
> > > for (;;).
> > >
> >
> > Use an anonymous block outer scope? Or if not permitted even by C99
> (which
> > I think it is), a
Hi Simon,
On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs wrote:
> On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera wrote:
>> Well, yes, avoiding that is the point of this commit also: we were
>> scanning some partitions for some queries, after this patch we're
>> supposed not to.
>
>
> Understood
>
> My
Hi, hackers
"The local variables that do not have the volatile type and have been changed
between the setjmp() invocation and longjmp() call are indeterminate". This is
what the POSIX (and C standard for setjmp) says.
That's fine actually, but if we put the PG_TRY()/CATCH() in a loop, high
On Thu, Aug 8, 2019 at 1:27 PM Amit Langote wrote:
> Hi Amul,
>
> On Thu, Aug 8, 2019 at 4:15 PM amul sul wrote:
> >
> > Hi,
> >
> > In RelationBuildPartitionDesc(), a memory space that use to gather
> partitioning
> > bound info wasn't free at the end. This might not a problem because this
>
On Thu, Aug 8, 2019 at 7:31 PM Yonatan Misgan wrote:
> I am Yonathan Misgan from Ethiopia, want to add some functionalities on
> PostgreSQL to support Ethiopian locales. I want your advice where I start to
> hack the PostgresSQL source code. I have attached some synopsis about the
> existing
On Thu, Aug 8, 2019 at 5:33 PM amul sul wrote:
> On Thu, Aug 8, 2019 at 1:27 PM Amit Langote wrote:
>> Thanks for the patch. This was discussed recently in the "hyrax vs.
>> RelationBuildPartitionDesc()" thread [1] and I think Alvaro proposed
>> an approach that's similar to yours. Not sure
Hi!
The patch makes my tests pass.
I wonder about a few things:
- Isn’t there any code that could be re-used for that (the one triggered by ‘a’
< ‘A’ COLLATE ucs_basic)?
- For object key members, the standard also refers to unicode code point
collation (SQL-2:2016 4.46.3, last paragraph).
-
On Wed, Aug 07, 2019 at 05:54:14PM -0400, Tom Lane wrote:
> Actually, looking in the source code finds
>
> * We allow the user to vacuum or analyze a table if he is superuser, the
> * table owner, or the database owner (but in the latter case, only if
> * it's not a shared
On 2019-Aug-08, Dmitry Igrishin wrote:
> my $prefixcmd =
> - $solution->{options}->{python} . "\\python -c
> \"$pythonprog\"";
> + "\"$solution->{options}->{python}\\python\" -c
> \"$pythonprog\"";
I think you can make this prettier like this:
my
Adam Lee writes:
> That's fine actually, but if we put the PG_TRY()/CATCH() in a loop, high
> version gcc might complain.
I'd be inclined to say "so don't do that then". Given this interpretation
(which sure looks like a bug to me, gcc maintainers' opinion or no),
you're basically going to have
A long time ago, we changed LC_COLLATE and LC_CTYPE from cluster-wide to
per-database (61d967498802ab86d8897cb3c61740d7e9d712f6). There is some
leftover code from that in initdb.c and backend/main/main.c to pass
these environment variables around in the expectations that the backend
will write
I realize that this has now been sent, but I wanted to comment on one
item:
On 2019-Aug-04, Jonathan S. Katz wrote:
> * Ensure that partition key columns will not be dropped as the result of an
> "indirect drop," such as from a cascade from dropping the key column's data
> type (e.g. a custom
On 8/8/19 9:29 AM, Yonatan Misgan wrote:
> From: Thomas Munro
>> Perl, Python etc. If I were you I think I'd experiment with a
>> prototype implementation using PL/Perl, PL/Python etc (a way to
As a bit of subtlety that might matter, the internal representation
in PostgreSQL, as in ISO 8601,
Peter Eisentraut writes:
> A long time ago, we changed LC_COLLATE and LC_CTYPE from cluster-wide to
> per-database (61d967498802ab86d8897cb3c61740d7e9d712f6). There is some
> leftover code from that in initdb.c and backend/main/main.c to pass
> these environment variables around in the
On 2019-08-08 08:46, Mark G wrote:
> Please find attached a trivial patch making a few arrays const (in
> addition to the data they point to).
How did you find this? Any special compiler settings?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
I wrote:
> ... In particular, I'm concerned that this patch will
> result in subtle changes in what settings get chosen during initdb.
OK, after reviewing the code a bit more I take that back --- initdb's
choices are entirely made within initdb.
However, I don't much like the choice to set
+1
Patch successfully applied to the master (
43211c2a02f39d6568496168413dc00e0399dc2e)
On Thu, Aug 8, 2019 at 12:30 PM Mark G wrote:
> Hello all,
>
> Please find attached a trivial patch making a few arrays const (in
> addition to the data they point to).
>
>
>
--
Ibrar Ahmed
On 8/8/19 2:40 PM, Alvaro Herrera wrote:
> On 2019-Aug-08, Jonathan S. Katz wrote:
>
>> I modified the copy of the announcement on the website to include the
>> pg_upgrade option.
>>
>> https://www.postgresql.org/about/news/1960/
>
> Ooh, had I thought you were going to do that, I would have
On 8/8/19 2:45 PM, Alvaro Herrera wrote:
> On 2019-Aug-08, Jonathan S. Katz wrote:
>
>> On 8/8/19 2:40 PM, Alvaro Herrera wrote:
>>> On 2019-Aug-08, Jonathan S. Katz wrote:
>>>
I modified the copy of the announcement on the website to include the
pg_upgrade option.
On Thu, Aug 8, 2019 at 9:31 AM Andres Freund wrote:
> I know that Robert is working on a patch that revises the undo request
> layer somewhat, it's possible that this is best discussed afterwards.
Here's what I have at the moment. This is not by any means a complete
replacement for Amit's undo
Alvaro Herrera writes:
> On 2019-Aug-04, Jonathan S. Katz wrote:
>> * Ensure that partition key columns will not be dropped as the result of an
>> "indirect drop," such as from a cascade from dropping the key column's data
>> type (e.g. a custom data type). This fix is applied only to newly
On Thu, Aug 8, 2019 at 8:51 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> How did you find this? Any special compiler settings?
>
16 hours stuck in a plane on an international flight. I was just eyeballing
the code to kill the boredom.
-Mark
On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > I agree that all of that isn't necessary for an initial implementation,
> > I was rather trying to lay out how we could
On Wed, Aug 7, 2019 at 07:40:05PM -0400, Sehrope Sarkuni wrote:
> With the provisos above, yes I think that would work though I don't think it's
> a good idea. Better to start off using the functions directly and then look
> into optimizing only if they're a bottleneck. As a first pass I'd break
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> > On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > > I agree that all of that isn't necessary for an initial
чт, 8 авг. 2019 г. в 20:07, Alvaro Herrera :
>
> On 2019-Aug-08, Dmitry Igrishin wrote:
>
> > my $prefixcmd =
> > - $solution->{options}->{python} . "\\python -c
> > \"$pythonprog\"";
> > + "\"$solution->{options}->{python}\\python\" -c
> >
Hi, Markus!
On Thu, Aug 8, 2019 at 11:53 AM Markus Winand wrote:
> The patch makes my tests pass.
Cool.
> I wonder about a few things:
>
> - Isn’t there any code that could be re-used for that (the one triggered by
> ‘a’ < ‘A’ COLLATE ucs_basic)?
PostgreSQL supports ucs_basic, but it's alias
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Thu, Aug 08, 2019 at 03:07:59PM -0400, Stephen Frost wrote:
> >* Bruce Momjian (br...@momjian.us) wrote:
> >>On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> >>> On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen
On Thu, Aug 8, 2019 at 6:29 AM Yonatan Misgan wrote:
> So my question is after developing the converter function where I put it for
> accessing it on PostgreSQL.
Maybe you can take some inspiration from the postgresql-unit extension:
https://github.com/df7cb/postgresql-unit
Note that it is
On 8/8/19 2:15 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2019-Aug-04, Jonathan S. Katz wrote:
>>> * Ensure that partition key columns will not be dropped as the result of an
>>> "indirect drop," such as from a cascade from dropping the key column's data
>>> type (e.g. a custom data
On 2019-Aug-08, Jonathan S. Katz wrote:
> I modified the copy of the announcement on the website to include the
> pg_upgrade option.
>
> https://www.postgresql.org/about/news/1960/
Ooh, had I thought you were going to do that, I would have told you
about the item ending in a comma :-)
--
On 2019-Aug-08, Jonathan S. Katz wrote:
> On 8/8/19 2:40 PM, Alvaro Herrera wrote:
> > On 2019-Aug-08, Jonathan S. Katz wrote:
> >
> >> I modified the copy of the announcement on the website to include the
> >> pg_upgrade option.
> >>
> >> https://www.postgresql.org/about/news/1960/
> >
> >
On 2019-Aug-08, Amit Langote wrote:
> On Thu, Aug 8, 2019 at 6:22 AM Tom Lane wrote:
> > OK, but maybe also s/created as a default partition/created as the default
> > partition/ ? Writing "a" carries the pretty clear implication that there
> > can be more than one, and contradicting that a
On Wed, Aug 7, 2019 at 08:56:18AM -0400, Sehrope Sarkuni wrote:
> On Mon, Aug 5, 2019 at 9:02 PM Bruce Momjian wrote:
>
> On Wed, Jul 31, 2019 at 09:25:01AM -0400, Sehrope Sarkuni wrote:
> > Even if we do not include a separate per-relation salt or things like
> > relfilenode when
Andres Freund writes:
> On 2019-07-31 19:40:09 -0400, Tom Lane wrote:
>> That makes the other idea (of a foreach-ish macro declaring the
>> listcell value variable) problematic, too :-(.
> Hm. One way partially around that would be using an anonymous struct
> inside the for(). Something like
>
On Thu, Aug 8, 2019 at 8:25 PM Ibrar Ahmed wrote:
> +1
>
> Patch successfully applied to the master (
> 43211c2a02f39d6568496168413dc00e0399dc2e)
>
That change looks like an unrelated patch for initdb. I'm still not seeing
my patch there.
-Mark
On Fri, Aug 9, 2019 at 1:25 AM Mark G wrote:
>
>
> On Thu, Aug 8, 2019 at 8:25 PM Ibrar Ahmed wrote:
>
>> +1
>>
>> Patch successfully applied to the master (
>> 43211c2a02f39d6568496168413dc00e0399dc2e)
>>
>
> That change looks like an unrelated patch for initdb. I'm still not seeing
> my patch
Libpq doesn't have a way to control which password protocols are used.
For example, the client might expect the server to be using SCRAM, but
it actually ends up using plain password authentication instead.
This patch adds:
password_protocol = {plaintext|md5|scram-sha-256|scram-sha-256-plus}
I wrote:
> BTW, further on the subject of performance --- I'm aware of at least
> these topics for follow-on patches:
> * Fix places that are maintaining arrays parallel to Lists for
> access-speed reasons (at least simple_rte_array, append_rel_array,
> es_range_table_array).
Attached is a patch
On Fri, Aug 9, 2019 at 6:19 AM Peter Geoghegan wrote:
> On Thu, Aug 8, 2019 at 6:29 AM Yonatan Misgan wrote:
> > So my question is after developing the converter function where I put it
> > for accessing it on PostgreSQL.
>
> Maybe you can take some inspiration from the postgresql-unit
On Thu, Aug 08, 2019 at 03:07:59PM -0400, Stephen Frost wrote:
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> >
[ returning to this topic now that the CF is over ]
I wrote:
> Perhaps there's an argument for doing something to change the behavior
> of list_union and list_difference and friends. Not sure --- it could
> be a foot-gun for back-patching. I'm already worried about the risk
> of back-patching
Hi Jeevan,
I have reviewed the backup part at code level and still looking into the
restore(combine) and functional part of it. But, here are my comments so
far:
The patches need rebase.
+ if (!XLogRecPtrIsInvalid(previous_lsn))
+
On Thu, Aug 8, 2019 at 2:16 PM Bruce Momjian wrote:
> On Wed, Aug 7, 2019 at 08:56:18AM -0400, Sehrope Sarkuni wrote:
> > Simplest approach for derived keys would be to use immutable attributes
> of the
> > WAL files as an input to the key derivation. Something like HKDF(MDEK,
> "WAL:" |
>
>
On Wed, Aug 07, 2019 at 10:10:36AM +0900, Michael Paquier wrote:
> Thanks for the review, Bruce! Tom, do you have any objections?
hearing nothing but cicadas from outside, applied. There were some
warnings I missed with the first version, which are fixed.
--
Michael
signature.asc
Description:
On Thu, Aug 08, 2019 at 10:46:07PM +0300, Dmitry Igrishin wrote:
> This looks nice for a Perl hacker :-). As for me, it looks unusual and
> a bit confusing. I never
> programmed in Perl, but I was able to quickly understand where the
> problem lies due to the
> style adopted in other languages,
On Fri, Aug 9, 2019 at 1:57 AM Robert Haas wrote:
>
> On Thu, Aug 8, 2019 at 9:31 AM Andres Freund wrote:
> > I know that Robert is working on a patch that revises the undo request
> > layer somewhat, it's possible that this is best discussed afterwards.
>
> Here's what I have at the moment.
On Fri, Aug 9, 2019 at 1:17 PM Amit Langote wrote:
> On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
> wrote:
> > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > > When working on it, I realized
> > > that the way RelOptInfo.partition_qual is processed is a bit
> > > duplicative, so
On Thu, Aug 8, 2019 at 03:07:59PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Jul 9, 2019 at 11:09:01AM -0400, Bruce Momjian wrote:
> > > On Tue, Jul 9, 2019 at 10:59:12AM -0400, Stephen Frost wrote:
> > > > * Bruce Momjian
On Fri, 9 Aug 2019 at 09:55, Tom Lane wrote:
> Attached is a patch that removes simple_rte_array in favor of just
> accessing the query's rtable directly. I concluded that there was
> not much point in messing with simple_rel_array or append_rel_array,
> because they are not in fact just mirrors
On Thu, Aug 8, 2019 at 6:31 PM Stephen Frost wrote:
> Strictly speaking, that isn't actually crash recovery, it's physical
> replication / HA, and while those are certainly nice to have it's no
> guarantee that they're required or that you'd want to have the same keys
> for them- conceptually,
Sorry for being late. I found it is committed before I caught up
this thread again..
At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote
in
> Hi Alvaro,
>
> On Thu, Aug 8, 2019 at 5:27 AM Alvaro Herrera
> wrote:
> > On 2019-Aug-07, Simon Riggs wrote:
> > > I saw your recent commit and it
At Fri, 9 Aug 2019 14:02:36 +0900, Amit Langote wrote
in
> On Fri, Aug 9, 2019 at 1:17 PM Amit Langote wrote:
> > On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
> > wrote:
> > > At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > > > When working on it, I realized
> > > > that the
On Thu, Aug 8, 2019 at 06:31:42PM -0400, Stephen Frost wrote:
> > >Crash recovery doesn't happen "all the time" and neither does vacuum
> > >freeze, and autovacuum processes are independent of individual client
> > >backends- we don't need to (and shouldn't) have the keys in shared
> > >memory.
>
Horiguchi-san,
Thanks for the review.
On Fri, Aug 9, 2019 at 12:09 PM Kyotaro Horiguchi
wrote:
> At Thu, 8 Aug 2019 14:50:54 +0900, Amit Langote wrote:
> > When working on it, I realized
> > that the way RelOptInfo.partition_qual is processed is a bit
> > duplicative, so I created a separate
On Thu, Aug 08, 2019 at 03:38:20PM -0700, Jeff Davis wrote:
> Libpq doesn't have a way to control which password protocols are used.
> For example, the client might expect the server to be using SCRAM, but
> it actually ends up using plain password authentication instead.
Thanks for working on
On Thu, 8 Aug 2019 at 15:03, Konstantin Knizhnik
wrote:
>
>
> On 08.08.2019 5:40, Craig Ringer wrote:
>
> On Tue, 6 Aug 2019 at 16:32, Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
>> New version of the patch with several fixes is attached.
>> Many thanks to Roman Zharkov for
On Fri, 9 Aug 2019 at 04:24, Tom Lane wrote:
> I wrote:
> > Perhaps there's an argument for doing something to change the behavior
> > of list_union and list_difference and friends. Not sure --- it could
> > be a foot-gun for back-patching. I'm already worried about the risk
> > of
On Wed, Aug 07, 2019 at 10:17:25AM -0400, Tom Lane wrote:
> Not objecting to the patch, exactly, just feeling like there's
> more here than meets the eye. Not quite sure if it's worth
> investigating closer, or what we'd even need to do to do so.
Yes, something's weird here. I'd think that the
Hi,
On Thu, Aug 8, 2019 at 10:10 AM Amit Langote wrote:
> On Wed, Aug 7, 2019 at 6:00 PM Etsuro Fujita wrote:
> > On Wed, Aug 7, 2019 at 4:28 PM Amit Langote wrote:
> > > I just noticed obsolete references to es_result_relation_info that
> > > 0002 failed to remove. One of them is in
Hi,
On 2019-08-07 14:50:17 +0530, Amit Kapila wrote:
> On Tue, Aug 6, 2019 at 1:26 PM Andres Freund wrote:
> > On 2019-08-05 11:29:34 -0700, Andres Freund wrote:
> > > +/*
> > > + * Binary heap comparison function to compare the time at which an error
> > > + * occurred for transactions.
> > > +
On Wed, Aug 07, 2019 at 12:48:29PM +0300, Liudmila Mantrova wrote:
> If we decide to fix this, we should probably revise and back-patch the whole
> paragraph where it appears as it seems to mix up scanning target cluster
> WALs and applying source cluster WALs. A small patch is attached for your
>
On Wed, Aug 7, 2019 at 5:06 PM Thomas Munro wrote:
>
> On Thu, Aug 1, 2019 at 1:22 AM Amit Kapila wrote:
> > On Wed, Jul 31, 2019 at 10:13 AM Amit Kapila
> > wrote:
> > > On Tue, Jul 30, 2019 at 5:26 PM Thomas Munro
> > > wrote:
> > > > but
> > > > here's a small thing: I managed to reach
Thank you for your quick response. I am also impressed to develop Ethiopian
calendar as an extension on PostgreSQL and I I have already developed the
function that convert Gregorian calendar time to Ethiopian calendar time. But
the difficulty is on how to use this function on PostgreSQL as well
Hello,
On Thu, Aug 8, 2019 at 5:09 PM Amit Langote wrote:
>
> Hi Simon,
>
> On Thu, Aug 8, 2019 at 4:54 PM Simon Riggs wrote:
> > On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera
> > wrote:
> >> Well, yes, avoiding that is the point of this commit also: we were
> >> scanning some partitions for
On Tue, 16 Jul 2019 at 13:57, Masahiko Sawada wrote:
>
> On Wed, Jun 12, 2019 at 1:30 PM Masahiko Sawada wrote:
> >
> > Hi all,
> >
> > Long-running vacuum could be sometimes cancelled by administrator. And
> > autovacuums could be cancelled by concurrent processes. Even if it
> > retries after
75 matches
Mail list logo
