Hi,
While testing this feature found that - if lots of insert happened on
the master cluster then pg_recvlogical is not showing the DATA
information on logical replication slot which created on SLAVE.
Please refer this scenario -
1)
Create a Master cluster with wal_level=logcal and create
On 01.03.2019 1:32, Thomas Munro wrote:
On Fri, Mar 1, 2019 at 10:41 AM Shawn Debnath wrote:
On Fri, Mar 01, 2019 at 10:33:06AM +1300, Thomas Munro wrote:
It doesn't make any sense to put things like clog or any other SLRU in
a non-default tablespace though. It's perfectly OK if not all sm
At Tue, 26 Feb 2019 10:55:18 -0500, Robert Haas wrote
in
> On Mon, Feb 25, 2019 at 1:27 AM Kyotaro HORIGUCHI
> wrote:
> > > I'd like to see some evidence that catalog_cache_memory_target has any
> > > value, vs. just always setting it to zero.
> >
> > It is artificial (or acutually wont't be re
Hi Meskes-san, Takahashi-san
> If the standard allows it, we want to be able to process it.
I will try to implement it with the Idea-2 that doesn't use PQprepare() and
Takahasi-san's following idea.
> For example,
> - ECPG convert ":ID" to "$1" and "$1" in the original statement to "$$1"
> - n
On 2/28/19 6:08 PM, Laurenz Albe wrote:
David Steele wrote:
This patch attempts to document the limitations of the exclusive mode.
Thanks!
+
+ The primary issue with the exclusive method is that the
+ backup_label file is written into the data directory
+ when pg_start_backup
David Steele wrote:
> I added some extra language to the warning that gets emitted in the log.
> Users are more like to see that than the documentation.
>
> I also addressed a comment from another thread by adding pg_basebackup
> as .e.g. rather than or.
Looks good to me.
Yours,
Laurenz Albe
El jue., 28 de feb. de 2019 a la(s) 23:50, Michael Paquier
(mich...@paquier.xyz) escribió:
>
> On Thu, Feb 28, 2019 at 11:07:47PM -0300, Martín Marqués wrote:
> > El 28/2/19 a las 15:13, David Steele escribió:
> > +
> > + The exclusive backup method is deprecated and should be avoided in
> >
On 3/1/19 11:36 AM, Martín Marqués wrote:
El jue., 28 de feb. de 2019 a la(s) 23:50, Michael Paquier
(mich...@paquier.xyz) escribió:
On Thu, Feb 28, 2019 at 11:07:47PM -0300, Martín Marqués wrote:
El 28/2/19 a las 15:13, David Steele escribió:
+
+ The exclusive backup method is deprecat
El vie., 1 de mar. de 2019 a la(s) 06:21, David Steele
(da...@pgmasters.net) escribió:
>
>
> I also addressed a comment from another thread by adding pg_basebackup
> as .e.g. rather than or.
Thanks David,
This looks very good!
--
Martín Marquéshttp://www.2ndQuadrant.com/
Postgre
Hi Matsumura-san,
> But I will probably be late because I don't understand parse.pl very
> well.
> I think that the following rule is made by parse.pl.
>
>PreparableStmt:
>SelectStmt
>{
>is_in_preparable_stmt = true; <--- I want to add it.
>$$ = $1;
>
On Thu, Feb 28, 2019 at 10:43 AM Thomas Munro wrote:
> On Thu, Feb 28, 2019 at 10:27 AM Shawn Debnath wrote:
> > We had a quick offline discussion to get on the same page and we agreed
> > to move forward with Andres' approach above. Attached is patch v10.
> > Here's the overview of the patch:
>
(2019/02/28 0:46), Robert Haas wrote:
On Wed, Feb 27, 2019 at 7:46 AM Etsuro Fujita
wrote:
Yet another thing I noticed while working on [1] is this in
grouping_planner:
/*
* If the input rel is marked consider_parallel and there's nothing
that's
* not parallel-safe in the LIM
(2019/02/28 0:52), Robert Haas wrote:
On Tue, Feb 26, 2019 at 7:26 AM Etsuro Fujita
wrote:
The parallel safety of the final scan/join target is determined from the
grouping target, not that target, which [ is wrong ]
Your patch looks right to me.
I think it would be better for you to take
El vie., 1 de mar. de 2019 a la(s) 06:21, David Steele
(da...@pgmasters.net) escribió:
>
> I added some extra language to the warning that gets emitted in the log.
> Users are more like to see that than the documentation.
>
> I also addressed a comment from another thread by adding pg_basebackup
Meskes-san
Thank you for your comment.
> The only way to add this is by creating a replacement production for
> this rule. parse.pl cannot do it itself.
I will read README.parser, ecpg.addons, and *.pl to understand.
> > I will use @1 instend of $$1 because the replacing is almost same as
> > t
Hi,
Robert, I CCed you because you are the author of that commit. Before
that commit ("Rewrite the code that applies scan/join targets to
paths."), apply_scanjoin_target_to_paths() had a boolean parameter named
modify_in_place, and used apply_projection_to_path(), not
create_projection_path(), to
Etsuro Fujita wrote:
> (2019/02/22 22:54), Antonin Houska wrote:
> > Etsuro Fujita wrote:
> >> On the other hand, the code bit added by
> >> 0001-postgres_fdw-Perform-UPPERREL_ORDERED-step-remotely-v3.patch handles
> >> the
> >> case where a post-scan/join processing step other than grouping/ag
Please follow the 1-space indentation in the documentation files.
I think the style of mentioning all the problems in a note before the
actual description is a bit backwards.
The layout of the section should be:
- This is what it does.
- Here are some comparisons with other methods.
- For this
Etsuro Fujita wrote:
> (2019/02/23 0:21), Antonin Houska wrote:
> > Etsuro Fujita wrote:
>
> >>> (2019/02/08 2:04), Antonin Houska wrote:
> * regression tests: I think test(s) should be added for queries that have
> ORDER BY clause but do not have GROUP BY (and also no LIMIT / OFFSET)
Hi,
The Commit 5955d934194c3888f30318209ade71b53d29777f has changed the logic
to avoid dumping creation and comment commands for the public schema.
>From v11 onwards, we are using the DUMP_COMPONENT_ infrastructure in
selectDumpableNamespace() to skip the public schema creation.
As reported by Pr
for a createStmt, it will call transformCreateStmt, and then
heap_create_with_catalog.
but looks it just check the if_not_exists in transformCreateStmt.
so there is a chance that when the transformCreateStmt is called, the table
is not created, but before the heap_create_with_catalog is called,
Hello,
We probably identified a bug in the pg_background implementation:
https://github.com/vibhorkum/pg_background
It is a race condition when starting the process and BGWH_STOPPED is returned -
see the pull request for more info:
https://github.com/RekGRpth/pg_background/pull/1
I think I h
Hi Matsumura-san,
> I will read README.parser, ecpg.addons, and *.pl to understand.
Feel free to ask, when anything comes up.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes d
Hi,
I have tested bug fixes provided by all the patches. They are working
great. I found one minor issue
select * from xmltable('*' PASSING 'pre&deeppost' COLUMNS x XML PATH '/');
The above query returns the xml. But there is an extra plus symbol at the
end
pre&deeppost+
Regards,
Ram
Hi Meskes-san
I must use a midrule action like the following that works as expected.
I wonder how to write the replacement to ecpg.addons.
I think it's impossible, right? Please give me some advice.
PrepareStmt:
PREPARE prepared_name prep_type_clause AS
{
prepared_name =
On Sun, 15 Apr 2018 at 19:09, Sergei Kornilov wrote:
> Attached updated patch follows recent Reorganize partitioning code commit.
I've made a pass over v10. I think it's in pretty good shape, but I
did end up changing a few small things.
1. Tweaked the documents a bit. I was going to just change
On Fri, Mar 01, 2019 at 07:17:04PM +0800, Andy Fan wrote:
> for a createStmt, it will call transformCreateStmt, and then
> heap_create_with_catalog.
> but looks it just check the if_not_exists in transformCreateStmt.
>
> is it designed as this on purpose or is it a bug?
That's a bug. Andreas K
(2019/03/01 20:00), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/02/22 22:54), Antonin Houska wrote:
Etsuro Fujita wrote:
So, the two changes are handling different
cases, hence both changes would be required.
+ /*
+* If this is an UPPERREL_ORDERED step performed on the
On Fri, Mar 1, 2019 at 4:33 AM Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello.
>
> At Thu, 28 Feb 2019 21:16:25 +0100, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote in <
> fbd08ad3-5dd8-3169-6cba-38d610d7b...@2ndquadrant.com>
> > > One biggest issue seems to be we don't
On Fri, 1 Mar 2019 at 15:27, Richard Guo wrote:
> I have reviewed your patch. Good job except two issues I can find:
>
> 1. The patch would give wrong results when the inner side is empty. In this
> case, the whole data from outer side should be in the outputs. But with the
> patch, we will lose t
Hi Matsumura-san,
> I must use a midrule action like the following that works as
> expected.
> I wonder how to write the replacement to ecpg.addons.
> I think it's impossible, right? Please give me some advice.
You are right, for this change you have to replace the whole rule. This
cannot be done
Imai-san,
Thanks for testing and sorry it took me a while to reply.
On 2019/02/25 15:24, Imai, Yoshikazu wrote:
> [update_pt_with_joining_another_pt.sql]
> update rt set c = jrt.c + 100 from jrt where rt.b = jrt.b;
>
> [pgbench]
> pgbench -n -f update_pt_with_joining_another_pt_for_ptkey.sql -T
On 2019/03/01 22:01, Amit Langote wrote:
> Of course, I had to make sure that query_planner (which is not
> in the charge of adding source inheritance child objects) can notice that.
Oops, I meant to write "query_planner (which *is* in the charge of adding
source inheritance child objects)..."
Th
On 3/1/19 1:13 PM, Peter Eisentraut wrote:
Please follow the 1-space indentation in the documentation files.
Whoops. Will fix.
I think the style of mentioning all the problems in a note before the
actual description is a bit backwards.
In the case of an important note like this I think it
On Fri, Mar 1, 2019 at 2:07 PM David Steele wrote:
> On 3/1/19 1:13 PM, Peter Eisentraut wrote:
> > Please follow the 1-space indentation in the documentation files.
>
> Whoops. Will fix.
>
> > I think the style of mentioning all the problems in a note before the
> > actual description is a bit
Re: Tom Lane 2019-01-31 <12792.1548965...@sss.pgh.pa.us>
> initdb hasn't depended on those libpq exports since 8.2, and it was
> a bug that it did so even then.
9.2 psql (and createuser, ...) is also broken:
/usr/lib/postgresql/9.2/bin/psql: symbol lookup error:
/usr/lib/postgresql/9.2/bin/psql:
Magnus Hagander wrote:
> Maybe have the first note say "This method is deprecated bceause it has
> serious
> risks (see bellow)" and then list the actual risks at the end?
Good idea. That may attract the attention of the dogs among the readers.
Yours,
Laurenz Albe
On 03/01/19 07:15, Ramanarayana wrote:
> Hi,
> I have tested bug fixes provided by all the patches. They are working
> great. I found one minor issue
>
> select * from xmltable('*' PASSING 'pre arg?>&deeppost' COLUMNS x XML PATH '/');
>
> The above query returns the xml. But there is an extra pl
Hi,
Yes it is working fine with \a option in psql.
Cheers
Ram 4.0
Suraj Kharage writes:
> The Commit 5955d934194c3888f30318209ade71b53d29777f has changed the logic
> to avoid dumping creation and comment commands for the public schema.
Yup.
> As reported by Prabhat, if we try to restore the custom/tar dump taken from
> v10 and earlier versions, we get the repo
Hi Alvaro,
On 2/28/19 1:28 PM, Alvaro Herrera wrote:
Rebased to current master. I'll reply later to handle the other issues
you point out.
Applying with hunks.
With 0003 using
export CFLAGS="-DCOPY_PARSE_PLAN_TREES -O0 -fno-omit-frame-pointer" &&
CC="ccache gcc" ./configure --prefix /usr/
On Thu, Feb 28, 2019 at 6:13 PM Alvaro Herrera wrote:
> Tablespaces already behave a little bit especially in another sense:
> it doesn't recurse to indexes. I think it's not possible to implement a
> three-way flag, where you tell it to move only the table, or to recurse
> to child tables but le
On Fri, Mar 1, 2019 at 5:47 AM Etsuro Fujita
wrote:
> Robert, I CCed you because you are the author of that commit. Before
> that commit ("Rewrite the code that applies scan/join targets to
> paths."), apply_scanjoin_target_to_paths() had a boolean parameter named
> modify_in_place, and used appl
Etsuro Fujita wrote:
> (2019/03/01 20:00), Antonin Houska wrote:
> > Etsuro Fujita wrote:
> > I used gdb to help me understand, however the condition
> >
> > if (fpextra&& !IS_UPPER_REL(foreignrel))
> >
> > never evaluated to true with the query above.
>
> Sorry, my explanation was not en
Thank you Michael!
What can I do if I'm sure I will not use the CTAS creation ? Take a look
at the "heap_create_with_catalog" function, it check it and raise error.
Even I change it to "check it && if_not_existing", raise error, it is
still be problematic since we may some other session cre
On Thu, Feb 28, 2019 at 8:19 PM Nikita Glukhov wrote:
> Attached 34th version of the patches.
Kinda strange version numbering -- the last post on this thread is v21.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 3/1/19 2:31 AM, Kyotaro HORIGUCHI wrote:
> Hello.
>
> At Thu, 28 Feb 2019 21:16:25 +0100, Tomas Vondra
> wrote in
>
>>> One biggest issue seems to be we don't know the total number of
>
> # One *of* the biggest *issues*?
>
>>> outer tuples before actually reading a null tuple. I doubt o
Hi,
On March 1, 2019 4:53:03 AM PST, David Rowley
wrote:
>On Fri, 1 Mar 2019 at 15:27, Richard Guo wrote:
>> I have reviewed your patch. Good job except two issues I can find:
>>
>> 1. The patch would give wrong results when the inner side is empty.
>In this
>> case, the whole data from outer s
Michael Paquier writes:
> On Thu, Feb 28, 2019 at 10:52:52PM -0500, Tom Lane wrote:
>> If you're suggesting that we disable that security restriction
>> during extension creation, I really can't see how that'd be a
>> good thing ...
> No, I don't mean that. I was just wondering if someone can se
Michael Paquier writes:
> On Thu, Feb 28, 2019 at 11:50:16PM -0500, Tom Lane wrote:
>> But, having said that, we've learned that it's generally bad for
>> catalog-query functions to fail outright just because they're pointed
>> at the wrong kind of catalog object. So I think that what we want her
Andres Freund writes:
> On March 1, 2019 4:53:03 AM PST, David Rowley
> wrote:
>> On Fri, 1 Mar 2019 at 15:27, Richard Guo wrote:
>>> 1. The patch would give wrong results when the inner side is empty.
>>> 2. Because of the new added predicate 'OR (var is NULL)', we cannot
>>> use hash join or
On 01.03.2019 19:17, Robert Haas wrote:
On Thu, Feb 28, 2019 at 8:19 PM Nikita Glukhov wrote:
Attached 34th version of the patches.
Kinda strange version numbering -- the last post on this thread is v21.
For simplicity of dependence tracking, version numbering of JSON_TABLE patches
matches
On 2/25/19 10:38 AM, Konstantin Knizhnik wrote:
> Hi hackers,
>
> Small issue with readir implementation for Windows.
> Right now it returns ENOENT in case of any error returned by
> FindFirstFile.
> So all places in Postgres where opendir/listdir are used will assume
> that directory is empty an
Hi,
On 2019-03-01 23:17:27 +1300, Thomas Munro wrote:
> @@ -8616,7 +8617,7 @@ CreateCheckPoint(int flags)
> * the REDO pointer. Note that smgr must not do anything that'd have
> to
> * be undone if we decide no checkpoint is needed.
> */
> - smgrpreckpt();
> +
Hi,
On 2019-03-01 13:33:23 +0530, tushar wrote:
> While testing this feature found that - if lots of insert happened on the
> master cluster then pg_recvlogical is not showing the DATA information on
> logical replication slot which created on SLAVE.
>
> Please refer this scenario -
>
> 1)
>
Hello,
PostgreSQL FLOAT appears to support +/-Infinity and NaN per the IEEE 754
standard, with expressions such as CAST('NaN' AS FLOAT) and CAST('Infinity'
AS FLOAT) and even supports ordering columns of floats that contain NaN.
However the query "SELECT 1.0/0.0;" produces an exception:
ERROR:
> "Matt" == Matt Pulver writes:
Matt> ERROR: division by zero
Matt> Question: If Infinity and NaN are supported, then why throw an
Matt> exception here, instead of returning Infinity?
Spec says so:
4) The dyadic arithmetic operators , ,
, and (+, -, *, and /, respectively) spec
On Friday, March 1, 2019, Matt Pulver wrote:
> However the query "SELECT 1.0/0.0;" produces an exception:
>
> ERROR: division by zero
>
>
> Question: If Infinity and NaN are supported, then why throw an exception
> here, instead of returning Infinity? Is it purely for historical reasons,
> or if
Hi,
On 2019-03-01 12:46:55 -0500, Matt Pulver wrote:
> PostgreSQL FLOAT appears to support +/-Infinity and NaN per the IEEE 754
> standard, with expressions such as CAST('NaN' AS FLOAT) and CAST('Infinity'
> AS FLOAT) and even supports ordering columns of floats that contain NaN.
>
> However the
On Fri, Mar 1, 2019 at 12:43 PM Andres Freund wrote:
> Obviously it's nicer looking this way, but OTOH, that means we have to
> send more data over the queue, because we can't easily combine the
> request + "owner". I don't have too strong feelings about it though.
Yeah, I would lean toward combi
Hello,
On 2/15/19 3:24 PM, Adrien NAYRAT wrote:
On 2/14/19 9:14 PM, Andres Freund wrote:
I wonder if this doesn't need a warning, explaining that using this when
there are large transactions could lead to slowdowns.
Yes, I will add some wording
Warning added.
It seems pretty weird to have
On 3/1/19 1:04 PM, David G. Johnston wrote:
> 1/0 is an illegal operation. We could return NaN for it but the choice of
> throwing an error is just as correct. Returning infinity is strictly
> incorrect.
That differs from my understanding of how the operations are specified
in IEEE 754 (as summ
On 2019-03-01 11:04:04 -0700, David G. Johnston wrote:
> Changing the behavior is not going to happen for any existing data types.
For the overflow case that really sucks, because we're leaving a very
significant amount of performance on the table because we recheck for
overflow in every op. The a
On Thu, Feb 28, 2019 at 3:17 AM Tsunakawa, Takayuki
wrote:
> Uh, thanks. I've just recognized I didn't know the meaning of "nuisance."
> I've looked up the meaning in the dictionary. Nuisance is like a trouble
> maker...
Yes, and "attractive nuisance" means something that, superficially, it
On Thu, Feb 28, 2019 at 3:12 AM Masahiko Sawada wrote:
> Attached the updated version patch.
Regarding the user interface for this patch, please have a look at the
concerns I mention in
https://www.postgresql.org/message-id/ca+tgmozorx_uuv67rjasx_aswkdzwv8kwfkfrwxyldcqfqj...@mail.gmail.com
I pr
On Fri, Mar 1, 2019 at 12:19 AM Masahiko Sawada wrote:
> > I wonder if we really want this behavior. Should a setting that
> > controls the degree of parallelism when scanning the table also affect
> > VACUUM? I tend to think that we probably don't ever want VACUUM of a
> > table to be parallel
Hi,
On 2019-02-28 10:18:36 -0800, Andres Freund wrote:
> On 2019-02-28 18:28:37 +0900, Etsuro Fujita wrote:
> > > I'm currently
> > > converting the EPQ machinery to slots, and in course of that I (with
> > > Horiguchi-san's help), converted RefetchForeignRow to return a slot. But
> > > there's cu
On 3/1/19 1:43 PM, Robert Haas wrote:
> On Thu, Feb 28, 2019 at 3:17 AM Tsunakawa, Takayuki
> wrote:
>> Uh, thanks. I've just recognized I didn't know the meaning of "nuisance."
>> I've looked up the meaning in the dictionary. Nuisance is like a trouble
>> maker...
> My proposal would be th
Hi,
On 2019-02-27 10:55:49 -0500, Robert Haas wrote:
> I don't think that a VACUUM option would be out of place, but a GUC
> sounds like an attractive nuisance to me. It will encourage people to
> just flip it blindly instead of considering the particular cases where
> they need that behavior, an
Robert Haas writes:
> I want to make one other point about this patch, which is that over on
> the thread "New vacuum option to do only freezing" we have a patch
> that does a closely-related thing. Both patches skip one phase of the
> overall VACUUM process. THIS patch wants to skip truncation;
On Thu, Feb 28, 2019 at 11:54 PM Tatsuro Yamada
wrote:
> Attached patch is wip patch.
+ CLUSTER and VACUUM FULL,
showing current progress.
and -> or
+ certain commands during command execution. Currently, the suppoted
+ progress reporting commands are VACUUM and
CLUSTER.
suppoted ->
Andres Freund writes:
> OTOH, as the main reason for wanting to disable truncation is that a
> user is getting very undesirable HS conflicts, it doesn't seem right to
> force them to change the reloption on all tables, and then somehow force
> it to be set on all tables created at a later stage. I
Hi,
On 2019-03-01 14:17:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > OTOH, as the main reason for wanting to disable truncation is that a
> > user is getting very undesirable HS conflicts, it doesn't seem right to
> > force them to change the reloption on all tables, and then somehow for
On Friday, March 1, 2019, Chapman Flack wrote:
>
> But if someone wanted to write a user-defined division function or
> operator that would return Inf for (anything > 0) / 0 and for
> (anything < 0) / -0, and -Inf for (anything < 0) / 0 and for
> (anything > 0) / -0, and NaN for (either zero) / (
On 3/1/19 2:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> I want to make one other point about this patch, which is that over on
>> the thread "New vacuum option to do only freezing" we have a patch
>> that does a closely-related thing. Both patches skip one phase of the
>> overall VACUUM pro
Andres Freund writes:
> On 2019-03-01 14:17:33 -0500, Tom Lane wrote:
>> I think we should reject the whole patch, tbh, and go do something
>> about the underlying problem instead. Once we've made truncation
>> not require AEL, this will be nothing but a legacy wart that we'll
>> have a hard time
Andrew Dunstan writes:
> On 3/1/19 2:14 PM, Tom Lane wrote:
>> Indeed, but I'm not sure that the use-cases are the same. In particular,
>> unless somebody has done some rather impossible magic, it would be
>> disastrous to apply DISABLE_INDEX_CLEANUP as a reloption, because then
>> it would be pe
On Thu, Feb 28, 2019 at 6:40 PM Tom Lane wrote:
> 1. Encourage people to develop new patches using chosen-at-random
> high OIDs, in the 7K-9K range. They do this already, it'd just
> be encouraged instead of discouraged.
>
> 2. Commit patches as received.
>
> 3. Once each devel cycle, after featu
On Thu, Feb 28, 2019 at 5:36 PM Peter Geoghegan wrote:
> I have attempted to institute some general guidelines for what the
> thicket of rules are by creating the "committing checklist" page. This
> is necessarily imperfect, because the rules are in many cases open to
> interpretation, often for g
On Sat, Mar 2, 2019 at 8:36 AM Shawn Debnath wrote:
> On Fri, Mar 01, 2019 at 01:15:21PM -0500, Robert Haas wrote:
> > > >
> > > > +typedef enum syncrequestowner
> > > > +{
> > > > + SYNC_MD = 0 /* md smgr */
> > > > +} syncrequestowner;
> > > >
> > > > I have a feeling that Andr
On 3/1/19 2:26 PM, David G. Johnston wrote:
> Upon further reading you are correct - IEEE 754 has chosen to treat n/0
> differently for n=0 and n<>0 cases. I'm sure they have their reasons but
> ... I don't use,
> or have time for the distraction, to understand why such a decision was
> made and
On Fri, Mar 1, 2019 at 2:36 PM Shawn Debnath wrote:
> I disagree, at least with combining and retaining enums. Encoding all
> the possible request types with the current, planned and future SMGRs
> would cause a sheer explosion in the number of enum values.
How big of an explosion would it be?
On Thu, Feb 7, 2019 at 3:28 AM Masahiko Sawada wrote:
> WAL encryption will follow as an additional feature.
I don't think WAL encryption is an optional feature. You can argue
about whether it's useful to encrypt the disk files in the first place
given that there's no privilege boundary between
On Fri, Mar 1, 2019 at 11:56 AM Robert Haas wrote:
> It would be neat if there were a tool you could run to somehow tell
> you whether catversion needs to be changed for a given patch.
That seems infeasible because of stored rules. A lot of things bleed
into that. We could certainly do better at
On Sat, Mar 2, 2019 at 9:35 AM Shawn Debnath wrote:
> On Fri, Mar 01, 2019 at 03:03:19PM -0500, Robert Haas wrote:
> > On Fri, Mar 1, 2019 at 2:36 PM Shawn Debnath wrote:
> > > I disagree, at least with combining and retaining enums. Encoding all
> > > the possible request types with the current,
On Fri, Mar 1, 2019 at 12:59 PM Andrew Gierth
wrote:
> > "Matt" == Matt Pulver writes:
>
> Matt> ERROR: division by zero
>
> Matt> Question: If Infinity and NaN are supported, then why throw an
> Matt> exception here, instead of returning Infinity?
>
> Spec says so:
>
> 4) The dyadic a
On Sat, Mar 2, 2019 at 7:27 AM Robert Haas wrote:
> On Thu, Feb 7, 2019 at 3:28 AM Masahiko Sawada
> wrote:
> > WAL encryption will follow as an additional feature.
>
> I don't think WAL encryption is an optional feature. You can argue
> about whether it's useful to encrypt the disk files in th
On Fri, Sep 14, 2018 at 10:04 AM Antonin Houska wrote:
> Toshi Harada wrote:
> > Even if you apply "data-at-rest-encryption-wip-2018.07.25.patch" to the
> > master branch,
> > the same patch error will occur.
>
> The version attached to this email should be applicable to the current
> branch. So
On Fri, Mar 1, 2019 at 3:52 PM Haribabu Kommi wrote:
> The Cybertec proposed patches are doing the encryption at the instance
> level, AFAIK, the current discussion is also trying to reduce the scope of the
> encryption to object level like (tablesapce, database or table) to avoid the
> encryptio
On Fri, Mar 1, 2019 at 3:35 PM Shawn Debnath wrote:
> On Fri, Mar 01, 2019 at 03:03:19PM -0500, Robert Haas wrote:
> > On Fri, Mar 1, 2019 at 2:36 PM Shawn Debnath wrote:
> > > I disagree, at least with combining and retaining enums. Encoding all
> > > the possible request types with the current,
On 3/1/19 3:49 PM, Matt Pulver wrote:
> In many applications, I would much rather see calculations carried out
> via IEEE 754 all the way to the end, with nans and infs, which
> provides much more useful diagnostic information than an exception that
> doesn't return any rows at all. As Andres Freu
On Fri, Mar 1, 2019 at 9:11 PM Konstantin Knizhnik
wrote:
> One more thing... From my point of view one of the drawbacks of Postgres
> is that it requires underlaying file system and is not able to work with
> raw partitions.
> It seems to me that bypassing fle system layer can significantly impro
On 2/28/19 9:33 PM, Michael Paquier wrote:
> Hi all,
>
> Joe's message here has reminded me that we have lacked a lot of error
> handling around CloseTransientFile():
> https://www.postgresql.org/message-id/c49b69ec-e2f7-ff33-4f17-0eaa4f2ce...@joeconway.com
>
> This has been mentioned by Alvaro a
On Fri, Mar 1, 2019 at 4:51 PM Chapman Flack wrote:
> On 3/1/19 3:49 PM, Matt Pulver wrote:
>
> > In many applications, I would much rather see calculations carried out
> > via IEEE 754 all the way to the end, with nans and infs, which
> > provides much more useful diagnostic information than an
On Sat, 2 Mar 2019 at 05:44, Tom Lane wrote:
>
> Andres Freund writes:
> > I've not checked, but could we please make sure these cases are covered
> > in the regression tests today with a single liner?
>
> I'm not sure if the second one is actually a semantics bug or just a
> misoptimization? Bu
James Coleman writes:
> [ saop_is_not_null-v10.patch ]
I went through this again, and this time (after some more rewriting
of the comments) I satisfied myself that the logic is correct.
Hence, pushed.
I stripped down the regression test cases somewhat. Those were
good for development, but they
Chapman Flack writes:
> I wanted to try this out a little before assuming it would work,
> and there seems to be no trouble creating a trivial domain over
> float8 (say, CREATE DOMAIN ieeedouble AS float8), and then creating
> operators whose operand types are the domain type.
While you can do th
David Rowley writes:
> On Sat, 2 Mar 2019 at 05:44, Tom Lane wrote:
>> I'm not sure if the second one is actually a semantics bug or just a
>> misoptimization? But yeah, +1 for putting in some simple tests for
>> corner cases right now. Anyone want to propose a specific patch?
> The second is
Thanks all for the feedbacks! I'm working on a refined patch.
Although adding "or var is NULL" to the anti join condition forces the planner
to choose nested loop anti join, it is always faster compared to the original
plan. In order to enable the transformation from NOT IN to anti join when the
On Tue, Sep 18, 2018 at 10:37 AM Michael Banck
wrote:
> I have added a retry for this as well now, without a pg_sleep() as well.
> This catches around 80% of the half-reads, but a few slip through. At
> that point we bail out with exit(1), and the user can try again, which I
> think is fine?
Mayb
1 - 100 of 119 matches
Mail list logo
