On Tue, Apr 28, 2020 at 11:45 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
>
> On Tue, Apr 28, 2020 at 5:16 PM davinder singh <
> davindersingh2...@gmail.com> wrote:
>
>> I have tested with different locales with codepages including above.
>> There are few which return
On Wed, Apr 29, 2020 at 8:24 AM Amit Kapila wrote:
> BTW, do you see any different results for pt_PT with create_locale
> version or the new patch version being discussed here?
>
No, there is no difference for pt_PT. The difference you are noticing is
because of the previous locale setting.
--
Hello Jonah,
Nice.
-- No ORDER/LIMIT is required with ITERATIVE as only a single tuple is
present
EXPLAIN ANALYZE
WITH ITERATIVE fib_sum (iteration, previous_number, new_number)
AS (SELECT 1, 0::numeric, 1::numeric
UNION ALL
SELECT (iteration + 1), new_number, (previous_number +
On Tue, Apr 28, 2020 at 3:55 PM Dilip Kumar wrote:
>
> On Tue, Apr 28, 2020 at 3:11 PM Amit Kapila wrote:
> >
> > On Mon, Apr 27, 2020 at 4:05 PM Dilip Kumar wrote:
> > >
> > [latest patches]
> >
> > v16-0004-Gracefully-handle-concurrent-aborts-of-uncommitt
> > - Any actions leading to
On Wed, Apr 29, 2020 at 8:21 AM Amit Kapila wrote:
>
> On Wed, Apr 29, 2020 at 1:32 AM Ranier Vilela wrote:
> >
> > Em ter., 28 de abr. de 2020 às 16:53, Juan José Santamaría Flecha
> > escreveu:
> >>
> >>
> >>
> >> On Tue, Apr 28, 2020 at 9:38 PM Ranier Vilela wrote:
> >>>
> >>> "pt" means
On Wed, Apr 29, 2020 at 10:37 AM Richard Guo wrote:
>
> On Wed, Apr 29, 2020 at 8:23 AM David Rowley wrote:
>
>> On Tue, 28 Apr 2020 at 19:04, Richard Guo wrote:
>> > I happened to notice $subject and not sure if it's an issue or not. When
>> > we're trying to remove a LEFT JOIN, one of the
On Wed, Apr 29, 2020 at 1:32 AM Ranier Vilela wrote:
>
> Em ter., 28 de abr. de 2020 às 16:53, Juan José Santamaría Flecha
> escreveu:
>>
>>
>>
>> On Tue, Apr 28, 2020 at 9:38 PM Ranier Vilela wrote:
>>>
>>> "pt" means portuguese language.
>>> "pt_BR" means portuguese language from Brazil,
On Wed, Apr 29, 2020 at 8:23 AM David Rowley wrote:
> On Tue, 28 Apr 2020 at 19:04, Richard Guo wrote:
> > I happened to notice $subject and not sure if it's an issue or not. When
> > we're trying to remove a LEFT JOIN, one of the requirements is the inner
> > side needs to be a single baserel.
I pushed this one. Some closing remarks:
On 2020-Apr-28, Alvaro Herrera wrote:
> On 2020-Apr-28, Kyotaro Horiguchi wrote:
> > Agreed to describe what is failed rather than the cause. However,
> > logical replications slots are always "previously reserved" at
> > creation.
>
> Bah, of course.
On Wed, Apr 29, 2020 at 8:29 AM David Rowley wrote:
> On Thu, 16 Apr 2020 at 14:17, Andy Fan wrote:
> > V6 also includes:
> > 1. Fix the comment misleading you mentioned above.
> > 2. Fixed a concern case for `relation_has_uniquekeys_for` function.
>
> Over on [1], Richard highlights a
On Thu, 16 Apr 2020 at 14:17, Andy Fan wrote:
> V6 also includes:
> 1. Fix the comment misleading you mentioned above.
> 2. Fixed a concern case for `relation_has_uniquekeys_for` function.
Over on [1], Richard highlights a problem in the current join removals
lack of ability to remove left
On Tue, 28 Apr 2020 at 19:04, Richard Guo wrote:
> I happened to notice $subject and not sure if it's an issue or not. When
> we're trying to remove a LEFT JOIN, one of the requirements is the inner
> side needs to be a single baserel. If there is a join qual that is a
> sublink and can be
On Tue, Apr 28, 2020 at 12:13:38PM -0400, James Coleman wrote:
> I think is missing a word. Instead of "especially the the target"
> should be "especially if the target".
Thanks, fixed.
> In this block:
>
> + Create a backup_label file to begin WAL replay at
> + the checkpoint created
On 2020-Apr-28, Kyotaro Horiguchi wrote:
> > Anyway I think this patch should fix it also -- instead of adding a new
> > flag, we just rely on the existing flags (since do_checkpoint must have
> > been set correctly from the flags earlier in that block.)
>
> Since the added (!do_checkpoint)
Hi,
On 2020-04-28 18:22:20 -0400, James Coleman wrote:
> I cc'd Andres given his commit introduced simplehash, so I figured
> he'd probably have a few pointers on when each one might be useful.
> [...]
> Do you have any thoughts on what the trade-offs/use-cases etc. are for
> dynahash versus
On Tue, Apr 28, 2020 at 06:22:20PM -0400, James Coleman wrote:
I cc'd Andres given his commit introduced simplehash, so I figured
he'd probably have a few pointers on when each one might be useful.
On Tue, Apr 28, 2020 at 8:39 AM James Coleman wrote:
...
> Any particular reasons to pick
I cc'd Andres given his commit introduced simplehash, so I figured
he'd probably have a few pointers on when each one might be useful.
On Tue, Apr 28, 2020 at 8:39 AM James Coleman wrote:
...
> > Any particular reasons to pick dynahash over simplehash? ISTM we're
> > using simplehash elsewhere
Hi,
On 2020-04-28 10:44:58 -0400, Tom Lane wrote:
> Stephen Frost writes:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> As you say, perhaps there's room for both things, but also as you say,
> >> it's not obvious how to decide intelligently between them.
>
> > The single-row case seems
I wrote:
> One thing I couldn't help noticing while fooling with this is what
> seems to be a bug in the PDF toolchain: any place you try to put
> an , you get extra whitespace. Not a lot, but once you
> see it, you can't un-see it. It's particularly obvious if one of
> two adjacent lines has
On Tue, Apr 28, 2020 at 9:38 PM Ranier Vilela wrote:
> "pt" means portuguese language.
> "pt_BR" means portuguese language from Brazil, "divisão por zero", is
> correct.
> "pt_PT" means portuguese language from Portugal, "division by zero"?
> poderia ser "divisão por zero", too.
>
> Why "pt_PT"
On Mon, Apr 27, 2020 at 8:50 PM Jeff Davis wrote:
> Can you illustrate with some examples? I get that one is appending and
> the other is modifying in-place, but how does this end up looking in
> the query language?
>
To ensure credit is given to the original authors, the initial patch I'm
On Tue, Apr 28, 2020 at 1:40 PM Pavel Stehule wrote:
>
>
>
> út 28. 4. 2020 v 18:17 odesílatel James Coleman napsal:
>>
>> On Tue, Apr 28, 2020 at 11:18 AM Pavel Stehule
>> wrote:
>> >
>> >
>> >
>> > út 28. 4. 2020 v 16:48 odesílatel Tomas Vondra
>> > napsal:
>> >>
>> >> On Tue, Apr 28, 2020
On Tue, Apr 28, 2020 at 5:16 PM davinder singh
wrote:
> On Mon, Apr 27, 2020 at 4:50 PM Amit Kapila
> wrote:
>
>> Bemba_Zambia
>> Bena_Tanzania
>> Bulgarian_Bulgaria
>> Swedish_Sweden.1252
>> Swedish_Sweden
>>
>
> I have tested with different locales with codepages including above. There
> are
On Mon, Apr 27, 2020 at 1:20 PM Amit Kapila wrote:
> I think we should backpatch this till 9.5 as I could see the changes
> made by commit 0fb54de9 to support MSVC2015 are present in that branch
> and the same is mentioned in the commit message. Would you like to
> prepare patches (and test
út 28. 4. 2020 v 18:17 odesílatel James Coleman napsal:
> On Tue, Apr 28, 2020 at 11:18 AM Pavel Stehule
> wrote:
> >
> >
> >
> > út 28. 4. 2020 v 16:48 odesílatel Tomas Vondra <
> tomas.von...@2ndquadrant.com> napsal:
> >>
> >> On Tue, Apr 28, 2020 at 03:43:43PM +0200, Pavel Stehule wrote:
>
Emre Hasegeli writes:
>> Perhaps it's too late in the v13 cycle to actually do anything
>> about this code-wise, but what should I do documentation-wise?
>> I'm certainly not eager to document that these operators behave
>> inconsistently depending on which type you're talking about.
> I don't
> Perhaps it's too late in the v13 cycle to actually do anything
> about this code-wise, but what should I do documentation-wise?
> I'm certainly not eager to document that these operators behave
> inconsistently depending on which type you're talking about.
I don't think we need to worry too
On 2020-Apr-28, Kyotaro Horiguchi wrote:
> At Mon, 27 Apr 2020 18:33:42 -0400, Alvaro Herrera
> wrote in
> > On 2020-Apr-08, Kyotaro Horiguchi wrote:
> >
> > > At Wed, 08 Apr 2020 09:37:10 +0900 (JST), Kyotaro Horiguchi
> > > wrote in
> > Thanks for the fix! I propose two changes:
> >
>
PG the text, character varying, character varying(length), character column
types are all the same thing with each column type inheriting the
properties from the parent type. With each successive type further
properties are added but they're all basically just "text" with some
additional
On Tue, Apr 28, 2020 at 12:21 AM Masahiko Sawada
wrote:
> I agree with both patches.
Thanks for the review.
> For the first fix it seems better to push down the logic to the page
> deletion code as your 0001 patch does so. The following change changes
> the page deletion code so that it emits
On Tue, Apr 28, 2020 at 11:18 AM Pavel Stehule wrote:
>
>
>
> út 28. 4. 2020 v 16:48 odesílatel Tomas Vondra
> napsal:
>>
>> On Tue, Apr 28, 2020 at 03:43:43PM +0200, Pavel Stehule wrote:
>> >út 28. 4. 2020 v 15:26 odesílatel Tomas Vondra
>> >
>> >napsal:
>> >
>> >> ...
>> >>
>> >> >I'm not so
On Tue, Apr 28, 2020 at 12:31 AM Michael Paquier wrote:
>
> On Mon, Mar 09, 2020 at 09:26:17AM -0400, James Coleman wrote:
> >> - pg_stat_tmp/, and
> >> - pg_subtrans/ are omitted from the data copied
> >> - from the source cluster. Any file or directory beginning with
> >> -
On Tue, Apr 28, 2020 at 11:51 AM Stephen Frost wrote:
> Greetings Jonah!
>
Hey, Stephen. Hope you're doing well, man!
> One of the first question that we need to ask though, imv anyway, is- do
> the other databases use the WITH ITERATIVE syntax? How many of them?
> Are there other
On Mon, Apr 27, 2020 at 8:50 PM Jeff Davis wrote:
> Hi,
>
Hey, Jeff. Long time no talk. Good to see you're still on here.
You might get better feedback in a month or so; right now we just got
> into feature freeze.
>
Yep. No hurry. I've just been playing with this and wanted to start getting
Greetings Jonah!
* Jonah H. Harris (jonah.har...@gmail.com) wrote:
> On Tue, Apr 28, 2020 at 6:19 AM Andreas Karlsson wrote:
>
> > Do you have any examples of queries where it would help? It is pretty
> > hard to say how much value some new syntax adds without seeing how it
> > improves an
"Jonathan S. Katz" writes:
> On 4/27/20 8:49 AM, Tom Lane wrote:
>> Other than that point, the main.css patch as I presented it just adds
>> some rules that aren't used yet, so it could be pushed as soon as you're
>> satisfied about the !important change. It'd probably make sense to
>> push it
út 28. 4. 2020 v 16:48 odesílatel Tomas Vondra
napsal:
> On Tue, Apr 28, 2020 at 03:43:43PM +0200, Pavel Stehule wrote:
> >út 28. 4. 2020 v 15:26 odesílatel Tomas Vondra <
> tomas.von...@2ndquadrant.com>
> >napsal:
> >
> >> ...
> >>
> >> >I'm not so concerned about this in any query where we
On Mon, Apr 27, 2020 at 4:50 PM Amit Kapila wrote:
> Bemba_Zambia
> Bena_Tanzania
> Bulgarian_Bulgaria
> Swedish_Sweden.1252
> Swedish_Sweden
>
I have tested with different locales with codepages including above. There
are few which return different locale code but the error messages in both
On Tue, Apr 28, 2020 at 6:19 AM Andreas Karlsson wrote:
> Do you have any examples of queries where it would help? It is pretty
> hard to say how much value some new syntax adds without seeing how it
> improves an intended use case.
>
Hey, Andreas.
Thanks for the response. I'm currently
On Tue, Apr 28, 2020 at 6:16 AM Oleksandr Shulgin <
oleksandr.shul...@zalando.de> wrote:
> will help the community to focus on the actual details of your proposal.
>
I'd like it if the community would focus on the details of the proposal as
well :)
--
Jonah H. Harris
On Tue, Apr 28, 2020 at 03:43:43PM +0200, Pavel Stehule wrote:
út 28. 4. 2020 v 15:26 odesílatel Tomas Vondra
napsal:
...
>I'm not so concerned about this in any query where we have a real FROM
>clause because even if we end up with only one row, the relative
>penalty is low, and the
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> As you say, perhaps there's room for both things, but also as you say,
>> it's not obvious how to decide intelligently between them.
> The single-row case seems pretty clear and also seems common enough that
> it'd be worth
Greetings,
* Lőrinc Pap (lor...@gradle.com) wrote:
> Thanks for the quick response, Tom!
We prefer to not top-post on these lists, just fyi.
> What about implementing only the first part of my proposal, i.e. BINARY
> COPY without the redundant column count & size info?
For my part, at least, I
tushar writes:
> While testing something else ,i found 1 scenario where pg_dump is failing
> CREATE FUNCTION do_analyze() RETURNS VOID VOLATILE LANGUAGE SQL
> AS 'ANALYZE pg_am';
> CREATE FUNCTION wrap_do_analyze(c INT) RETURNS INT IMMUTABLE LANGUAGE SQL
> AS 'SELECT $1 FROM
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Apr 23, 2020 at 10:35 AM Tom Lane wrote:
> > I think we're failing to communicate here. I agree that if the goal
> > is simply to re-implement what the RI triggers currently do --- that
> > is, retail one-row-at-a-time checks ---
Hi Michael,
On Mon, Apr 27, 2020 at 9:56 PM Michael Paquier wrote:
> rather soon, it looks like LLVM releases a new major version every 3
> months or so.
FYI LLVM has a six-month release cadence [1], the next release is
expected coming September (I can't tell whether you were joking).
Cheers,
Thanks for the quick response, Tom!
What about implementing only the first part of my proposal, i.e. BINARY
COPY without the redundant column count & size info?
That would already be a big win - I agree the rest of the proposed changes
would only complicate the usage, but I'd argue that leaving
út 28. 4. 2020 v 15:26 odesílatel Tomas Vondra
napsal:
> On Tue, Apr 28, 2020 at 08:39:18AM -0400, James Coleman wrote:
> >On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra
> > wrote:
> >>
> >> On Mon, Apr 27, 2020 at 09:04:09PM -0400, James Coleman wrote:
> >> >On Sun, Apr 26, 2020 at 7:41 PM James
On Sat, Apr 25, 2020 at 7:25 AM David Rowley wrote:
> I looked at this again and I don't think what I've got is right.
Apart from the considerations which you raised, I think there's also a
costing issue here. For instance, suppose we have an Append with three
children. Two of them have partial
On Tue, Apr 28, 2020 at 08:39:18AM -0400, James Coleman wrote:
On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra
wrote:
On Mon, Apr 27, 2020 at 09:04:09PM -0400, James Coleman wrote:
>On Sun, Apr 26, 2020 at 7:41 PM James Coleman wrote:
>>
>> On Sun, Apr 26, 2020 at 4:49 PM Tomas Vondra
>>
On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra
wrote:
>
> On Mon, Apr 27, 2020 at 09:04:09PM -0400, James Coleman wrote:
> >On Sun, Apr 26, 2020 at 7:41 PM James Coleman wrote:
> >>
> >> On Sun, Apr 26, 2020 at 4:49 PM Tomas Vondra
> >> wrote:
> >> >
> >> > On Sun, Apr 26, 2020 at 02:46:19PM
On Mon, Apr 27, 2020 at 09:04:09PM -0400, James Coleman wrote:
On Sun, Apr 26, 2020 at 7:41 PM James Coleman wrote:
On Sun, Apr 26, 2020 at 4:49 PM Tomas Vondra
wrote:
>
> On Sun, Apr 26, 2020 at 02:46:19PM -0400, James Coleman wrote:
> >On Sat, Apr 25, 2020 at 8:31 PM Tomas Vondra
> >
On Thu, Apr 23, 2020 at 10:35 AM Tom Lane wrote:
> I think we're failing to communicate here. I agree that if the goal
> is simply to re-implement what the RI triggers currently do --- that
> is, retail one-row-at-a-time checks --- then we could probably dispense
> with all the
On 4/28/20 10:43 AM, Benjamin Schaller wrote:
for an university project I'm currently doing some research on
PostgreSQL. I was wondering if hypothetically it would be possible to
implement a raw device system to PostgreSQL. I know that the
disadvantages would probably be higher than the
Greetings,
* Benjamin Schaller (benjamin.schal...@s2018.tu-chemnitz.de) wrote:
> for an university project I'm currently doing some research on PostgreSQL. I
> was wondering if hypothetically it would be possible to implement a raw
> device system to PostgreSQL. I know that the disadvantages
On Tue, Apr 28, 2020 at 2:53 PM Rajin Raj wrote:
>
> Is there any impact of using the character varying without providing the
> length while creating tables?
> I have created two tables and inserted 1M records. But I don't see any
> difference in pg_class. (size, relpage)
>
> create table
út 28. 4. 2020 v 13:35 odesílatel Ashutosh Bapat <
ashutosh.bapat@gmail.com> napsal:
> On Mon, Apr 27, 2020 at 7:56 PM Greg Stark wrote:
> >
> > On Fri, 24 Apr 2020 at 10:08, Tom Lane wrote:
> > >
> > > I'm skeptical. If we'd marked them that way from day one, it would
> have
> > > been
Hi ,
While testing something else ,i found 1 scenario where pg_dump is failing
Below is the standalone scenario -
--connect to psql terminal and create 2 database
postgres=# create database db1;
CREATE DATABASE
postgres=# create database db2;
CREATE DATABASE
--Connect to database db1 and
On Mon, Apr 27, 2020 at 7:56 PM Greg Stark wrote:
>
> On Fri, 24 Apr 2020 at 10:08, Tom Lane wrote:
> >
> > I'm skeptical. If we'd marked them that way from day one, it would have
> > been fine, but to change it now is a whole different discussion. I think
> > the odds that anybody will thank
On Wed, Apr 8, 2020 at 11:16 AM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Fri, 27 Mar 2020 at 22:06, Muhammad Usama wrote:
> >
> > Hi Sawada San,
> >
> > I have been further reviewing and testing the transaction involving
> multiple server patches.
> > Overall the patches
On Tue, Apr 28, 2020 at 3:11 PM Amit Kapila wrote:
>
> On Mon, Apr 27, 2020 at 4:05 PM Dilip Kumar wrote:
> >
> [latest patches]
>
> v16-0004-Gracefully-handle-concurrent-aborts-of-uncommitt
> - Any actions leading to transaction ID assignment are prohibited.
> That, among others,
> +
On 4/27/20 6:52 PM, Jonah H. Harris wrote:> If there's any interest,
I'll clean-up their patch and submit. Thoughts?
Hi,
Do you have any examples of queries where it would help? It is pretty
hard to say how much value some new syntax adds without seeing how it
improves an intended use case.
On Tue, Apr 28, 2020 at 5:49 AM Jonah H. Harris
wrote:
> On Mon, Apr 27, 2020 at 11:33 PM David Fetter wrote:
>
>>
>> Have the authors agreed to make it available to the project under a
>> compatible license?
>
>
> If there’s interest, obviously. Otherwise I wouldn’t be asking.
>
> I said from
On Mon, Apr 27, 2020 at 4:05 PM Dilip Kumar wrote:
>
[latest patches]
v16-0004-Gracefully-handle-concurrent-aborts-of-uncommitt
- Any actions leading to transaction ID assignment are prohibited.
That, among others,
+ Note that access to user catalog tables or regular system catalog
Is there any impact of using the character varying without providing the
length while creating tables?
I have created two tables and inserted 1M records. But I don't see any
difference in pg_class. (size, relpage)
create table test_1(name varchar);
create table test_2(name varchar(50));
insert
Hey,
for an university project I'm currently doing some research on
PostgreSQL. I was wondering if hypothetically it would be possible to
implement a raw device system to PostgreSQL. I know that the
disadvantages would probably be higher than the advantages compared to
working with the file
On 2020-04-28 15:09, Michael Paquier wrote:
On Tue, Apr 28, 2020 at 02:49:00PM +0900, Fujii Masao wrote:
Isn't it safer to report the wait event during fgets() rather than
putting
those calls around the whole loop, like other code does? For example,
writeTimeLineHistory() reports the wait
At Mon, 27 Apr 2020 19:40:07 -0400, Alvaro Herrera
wrote in
> On 2020-Apr-08, Kyotaro Horiguchi wrote:
>
> > I understand how it happens.
> >
> > The latch triggered by checkpoint request by CHECKPOINT command has
> > been absorbed by ConditionVariableSleep() in
> >
On Tue, 28 Apr 2020 at 11:35, Peter Geoghegan wrote:
>
> On Mon, Apr 27, 2020 at 11:02 AM Peter Geoghegan wrote:
> > I would like to backpatch both patches to all branches that have
> > commit 857f9c36cda -- v11, v12, and master. The second issue isn't
> > serious, but it seems worth keeping
One of the problems to allow logical decoding of in-progress (or
prepared) transactions is that the transaction which we are decoding
can abort concurrently and we might not be able to detect it which
leads to getting the wrong version of a row from system catalogs.
This can further lead to
Hi hackers,
I happened to notice $subject and not sure if it's an issue or not. When
we're trying to remove a LEFT JOIN, one of the requirements is the inner
side needs to be a single baserel. If there is a join qual that is a
sublink and can be converted to a semi join with the inner side rel,
On Tue, Apr 28, 2020 at 02:49:00PM +0900, Fujii Masao wrote:
> Isn't it safer to report the wait event during fgets() rather than putting
> those calls around the whole loop, like other code does? For example,
> writeTimeLineHistory() reports the wait event during read() rather than
> whole loop.
On Tue, Apr 28, 2020 at 12:56:19PM +0900, Fujii Masao wrote:
> Yes. Attached is the updated version of the patch, which introduces
> +(pg_lsn, numeric) and -(pg_lsn, numeric) operators.
> To implement them, I added also numeric_pg_lsn() function that converts
> numeric to pg_lsn.
-those
73 matches
Mail list logo
