so 16. 11. 2019 v 1:10 odesílatel vignesh C napsal:
> On Fri, Nov 15, 2019 at 1:23 PM Pavel Stehule
> wrote:
> >
> > updated patch attached
> >
>
> Thanks Pavel for providing updated version.
> Few comments:
> I felt the help text seems incomplete:
> @@ -159,6 +167,7 @@ help(const char *progna
On Fri, Nov 15, 2019 at 11:22:20AM -0500, Tom Lane wrote:
> Michael Paquier writes:
>> I would rather keep the solution with client_min_messages, and the
>> tests in vacuum.sql to keep those checks for the grammar parsing. So
>> this basically brings us back to use the patch I proposed here:
>> h
On Sun, Sep 15, 2019 at 3:47 AM Oleg Bartunov wrote:
> Is it worth to make a provision to add an ability to control how
> duplicates are sorted ?
Duplicates will continue to be sorted based on TID, in effect. We want
to preserve the ability to perform retail index tuple deletion. I
believe that t
On Fri, Nov 15, 2019 at 5:43 PM Mark Dilger wrote:
> On 11/13/19 11:51 AM, Peter Geoghegan wrote:
> > Can you suggest an alternative?
>
> Dupression
This suggestion makes me feel better about "deduplication".
--
Peter Geoghegan
On 11/13/19 11:51 AM, Peter Geoghegan wrote:
Can you suggest an alternative?
Dupression
--
Mark Dilger
On Tue, Nov 12, 2019 at 11:19 AM Amit Kapila wrote:
>
> On Tue, Nov 12, 2019 at 6:33 AM vignesh C wrote:
> >
> >
> > Thanks Amit for your comments. Please find the updated patch which
> > does not include the changes mentioned above.
> >
>
> Thanks for working on this. I have pushed your latest
On Fri, Nov 15, 2019 at 5:49 AM Robert Haas wrote:
> Personally, I don't care very much about backward-compatibility, or
> about how hard it is for tools to parse. I want it to be possible, but
> if it takes a little extra effort, so be it.
I think these are two separate issues. I agree on
backwa
Hello hackers,
I don't like this:
-> Parallel Hash (... rows=416667 ...) (... rows=33 ...)
I think the logic in get_parallel_divisor() only makes sense for
queries like this (output with nearby patch to show leader
contribution):
postgres=# set parallel_tuple_cost = 0;
SET
postgres=# set
On Wed, Sep 11, 2019 at 2:04 PM Peter Geoghegan wrote:
> > I haven't measured how these changes affect WAL size yet.
> > Do you have any suggestions on how to automate testing of new WAL records?
> > Is there any suitable place in regression tests?
>
> I don't know about the regression tests (I do
On Fri, Nov 15, 2019 at 1:23 PM Pavel Stehule wrote:
>
> updated patch attached
>
Thanks Pavel for providing updated version.
Few comments:
I felt the help text seems incomplete:
@@ -159,6 +167,7 @@ help(const char *progname)
printf(_("\nOptions:\n"));
printf(_(" -e, --echo
On Fri, Nov 15, 2019 at 5:16 AM Robert Haas wrote:
> Hmm. Well, maybe I'm just behind the times. But that same wikipedia
> article also says that deduplication works on large chunks "such as
> entire files or large sections of files" thus differentiating it from
> compression algorithms which work
Attachment.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index 006c6298c9..e7a504c304 100644
--- a/src/backend/acce
On 2019-Nov-12, Antonin Houska wrote:
> ok, the next version uses explicit lseek(). Maybe the fact that XLOG is mostly
> read sequentially (i.e. without frequent seeks) is the reason pread() has't
> been adopted so far.
I don't quite understand why you backed off from switching to pread. It
seem
On Wed, Nov 13, 2019 at 9:52 PM Amit Kapila wrote:
> On Wed, Nov 13, 2019 at 6:13 AM Kyotaro Horiguchi
> wrote:
> > The phatch's shape looks better. Thanks.
>
> +1. LGTM as well.
Thanks. Pushed.
I wrote:
> Accordingly, here's a patchset that does it like that.
The cfbot noticed that a couple of patches committed this week
created (trivial) conflicts with this patchset. Here's a v3
rebased up to HEAD; no interesting changes.
regards, tom lane
diff --git a/doc/src
pá 15. 11. 2019 v 21:01 odesílatel Andrew Dunstan <
andrew.duns...@2ndquadrant.com> napsal:
>
> On 11/15/19 2:14 PM, Pavel Stehule wrote:
> > Hi
> >
> >
> >
> > For release 13+, I have given some more thought to what should be
> > done.
> > I think the bar for altering the behaviour of
On 11/15/19 2:14 PM, Pavel Stehule wrote:
> Hi
>
>
>
> For release 13+, I have given some more thought to what should be
> done.
> I think the bar for altering the behaviour of a function should be
> rather higher than we have in the present case, and the longer the
> function
Hi,
On 2019-11-15 14:43:09 -0500, Robert Haas wrote:
> On Thu, May 5, 2016 at 7:01 PM Andres Freund wrote:
> > Here's a rebased version. I remember why I didn't call the column
> > "offset" (as Michael complained about upthread), it's a keyword...
>
> This never got applied, and that annoyed me
Robert Haas writes:
> This never got applied, and that annoyed me again today, so here's a
> new version that I've whacked around somewhat and propose to commit.
> ...
> Other things I changed:
> - Doc edits.
> - Added REVOKE statements as proposed by Michael (and I agree).
> - Can't patch pg_proc
On Thu, May 5, 2016 at 7:01 PM Andres Freund wrote:
> Here's a rebased version. I remember why I didn't call the column
> "offset" (as Michael complained about upthread), it's a keyword...
This never got applied, and that annoyed me again today, so here's a
new version that I've whacked around s
Hi
> For release 13+, I have given some more thought to what should be done.
> I think the bar for altering the behaviour of a function should be
> rather higher than we have in the present case, and the longer the
> function has been sanctioned by time the higher the bar should be.
> However, I
Laurenz Albe writes:
> On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote:
>> It might be worth clarifying this point in section 5.7,
>> https://www.postgresql.org/docs/devel/ddl-priv.html
>> but let's not duplicate that in every ref/ page.
> I have attached a proposed patch.
The right to
Peter Eisentraut writes:
> Say you want to set up promote_trigger_file to point to a file outside
> of the data directory, maybe because you want to integrate it with some
> external tooling. So you go into your configuration and set
> promote_trigger_file = '/srv/foobar/trigger'
> and rel
Pantelis Theodosiou writes:
> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
>>> Perhaps the way to resolve Peter's objection is to make the syntax
>>> more fully like UPDATE:
>>> INSERT INTO target SET c1 = x, c2 = y+z, ... FROM
>>> tables-providing-x-y-z
> Regarding syntax and considering that it
Hello
> Maybe we need a new elevel category for that.
> SYSTEM_WARNING or LOG_WARNING, perhaps?
I think a separate levels for user warnings and system warnings (and errors)
would be great for log analytics. Error due to user typo in query is not the
same as cache lookup error (for example).
re
Fujii Masao writes:
> On Fri, Nov 15, 2019 at 10:49 AM Michael Paquier wrote:
>> On Thu, Nov 14, 2019 at 10:38:30AM -0500, Tom Lane wrote:
>>> (BTW, from this perspective, WARNING is especially bad because it
might not get logged at all. Better to use LOG.)
>> Neither am I comfortable with
Michael Paquier writes:
> I would rather keep the solution with client_min_messages, and the
> tests in vacuum.sql to keep those checks for the grammar parsing. So
> this basically brings us back to use the patch I proposed here:
> https://www.postgresql.org/message-id/20191107013942.ga1...@paqui
On 15.11.2019 5:52, Michael Paquier wrote:
On Tue, Sep 10, 2019 at 03:23:25PM +0900, Michael Paquier wrote:
Yes, I suspect that it could be very costly in some configurations if
there is a large gap between the last replayed LSN and the last LSN
the WAL receiver has flushed.
There is an extra
On 11.11.2019 16:00, Surafel Temesgen wrote:
Next, you use DestRemoteSimple for returning conflicting tuples back:
+ dest = CreateDestReceiver(DestRemoteSimple);
+ dest->rStartup(dest, (int) CMD_SELECT, tupDesc);
However, printsimple supports very limited subset
Hi,
On 11/11/19 1:24 PM, Jesper Pedersen wrote:
v29 using UniqueKey attached.
Just a small update to the UniqueKey patch to hopefully keep CFbot happy.
Feedback, especially on the planner changes, would be greatly appreciated.
Best regards,
Jesper
>From b1a69c2791c8aba6caa85d7f24b983664115
On Mon, Nov 04, 2019 at 03:43:09PM -0800, Noah Misch wrote:
> On Mon, Nov 04, 2019 at 03:26:35PM +1300, Thomas Munro wrote:
> > On Thu, Aug 1, 2019 at 6:51 PM Noah Misch wrote:
> > > vac_truncate_clog() instance 1 starts, considers segment ABCD eligible to
> > > unlink
> > > vac_truncate_clog() i
On 11/14/19 3:21 PM, Alvaro Herrera wrote:
> On 2019-Nov-14, Andrew Dunstan wrote:
>
>> I guess this would work. There would have to be a deal of code to load
>> the library and lookup the symbol. Do we really think it's worth it?
>> Leveraging shared_preload_libraries makes this comparatively si
Hello
Could you rebase patch please? I have errors during patch apply. CFbot checks
latest demonstration patch.
> I looked into this. It seems trivial to make walsender create and use a
> temporary replication slot by default if no permanent replication slot
> is specified. This is basically the
On Wed, Nov 13, 2019 at 3:03 PM Andres Freund wrote:
> Well, it's not been that way since the format option was added, so ...
It was pretty close in the original version, but people keep trying to
be clever.
> > I also think that conditionally renaming "Output" to "Project" is a
> > super-bad id
On Wed, Nov 13, 2019 at 11:28 AM Alvaro Herrera
wrote:
> On 2019-Nov-12, Andres Freund wrote:
> > > Anyway, I still like the idea of merging the void keyword in with
> > > that.
> >
> > Hm. Any other opinions?
>
> Although it feels very strange to me at first glance, one only has to
> learn the tr
On Wed, Nov 13, 2019 at 4:46 PM Alvaro Herrera wrote:
> But it is not totally
> unreasonable to have lots of partitions, and as we improve the system,
> more and more people will want to.
Yep.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Nov 13, 2019 at 2:51 PM Peter Geoghegan wrote:
> "Deduplication" never means that you get rid of duplicates. According
> to Wikipedia's deduplication article: "Whereas compression algorithms
> identify redundant data inside individual files and encodes this
> redundant data more efficientl
Hi,
Thank you for the explanation.
Best regards.
Ranier Vilela
De: Daniel Gustafsson
Enviado: sexta-feira, 15 de novembro de 2019 11:58
Para: Ranier Vilela
Cc: pgsql-hackers@lists.postgresql.org
Assunto: Re: [PATCH][BUG FIX] Unsafe access pointers.
> On 1
Heh, it's me who now breaks postgresql build:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92529
Martin
On Fri, 15 Nov 2019 at 13:01, Fabien COELHO
wrote:
>
>
> > Yes, after the revision I see other failing tests like:
>
> Indeed, I can confirm there are still 18/195 fails with the updated gcc.
Yes, after the revision I see other failing tests like:
...
select_having... ok 16 ms
subselect... FAILED 92 ms
union... FAILED 77 ms
case ... ok 32 ms
join
Yes, after the revision I see other failing tests like:
Indeed, I can confirm there are still 18/195 fails with the updated gcc.
I'm going to investigate that and will inform you guys.
Great, thanks!
--
Fabien.
14.11.2019 0:25, Peter Geoghegan wrote:
On Mon, Oct 28, 2019 at 11:11 AM Anastasia Lubennikova
wrote:
At first I implemented bitwise as default, because it is more common .
Though, I agree that it's essential to avoid false positives here.
The new version of the patch is attached. I also updat
> On 15 Nov 2019, at 12:25, Ranier Vilela wrote:
> It's probably not happening, but it can happen, I think.
I don't think it can, given how elog() works.
> - if (!HeapTupleIsValid(classtup))
> + if (!HeapTupleIsValid(classtup)) {
> elog(ERROR, "cache lookup failed for oper
Hi,
Last time, I promise.
It's probably not happening, but it can happen, I think.
Best regards.
Ranier Vilela
--- \dll\postgresql-12.0\a\backend\access\brin\brin_validate.c Mon Sep 30
17:06:55 2019
+++ brin_validate.c Fri Nov 15 08:14:58 2019
@@ -57,8 +57,10 @@
/* Fetch opclass
On Fri, Nov 15, 2019 at 4:01 PM Dilip Kumar wrote:
>
> On Fri, Nov 15, 2019 at 3:50 PM Amit Kapila wrote:
> >
> >
> > Few other comments on this patch:
> > 1.
> > + case REORDER_BUFFER_CHANGE_INVALIDATION:
> > +
> > + /*
> > + * Execute the invalidation message locally.
> > + *
> > + * XXX Do we
On Fri, Nov 15, 2019 at 3:50 PM Amit Kapila wrote:
>
> On Thu, Nov 14, 2019 at 3:40 PM Dilip Kumar wrote:
> >
> >
> > Apart from this, I have another question in
> > 0003-Issue-individual-invalidations-with-wal_level-logical.patch
> >
> > @@ -543,6 +588,18 @@ RegisterSnapshotInvalidation(Oid dbId
On Fri, Nov 15, 2019 at 3:36 PM Kubilay Kaan wrote:
>
> So my problem is when I call a sql function which returns a refcursor for
> dynamic sql purposes it doesnt fill the recordset.
>
> So my question is does the ODBC driver supports refcursor??
>
I think the chances of getting an answer on ODB
On Thu, Nov 14, 2019 at 3:40 PM Dilip Kumar wrote:
>
>
> Apart from this, I have another question in
> 0003-Issue-individual-invalidations-with-wal_level-logical.patch
>
> @@ -543,6 +588,18 @@ RegisterSnapshotInvalidation(Oid dbId, Oid relId)
> {
> AddSnapshotInvalidationMessage(&transInvalInfo
On Thu, Nov 14, 2019 at 5:02 PM Mahendra Singh wrote:
>
> On Mon, 11 Nov 2019 at 17:56, Amit Kapila wrote:
> >
> > On Mon, Nov 11, 2019 at 5:14 PM Dilip Kumar wrote:
> > >
> > > On Mon, Nov 11, 2019 at 4:23 PM Amit Kapila
> > > wrote:
> > > >
> > > > ..
> > > > > I have tested the same with so
Hello friends,
I am not sure if I am right here bcz its my forst post so..
I am using the Provider=MSDASQL.1 through psqlODBC as Data Source(created user
DSN).
Postgresversion is 12.
Programming language is C++.
OS = Windows 10.
So my problem is when I call a sql function which returns a ref
Hello friends,
I am not sure if I am right here bcz its my forst post so..
I am using the Provider=MSDASQL.1 through psqlODBC as Data Source(created user DSN).
Postgresversion is 12.
Programming language is C++.
OS = Windows 10.
So my problem is when I call a sql function which retur
On 2019-11-15 03:14, Fujii Masao wrote:
One thought is to try to detect the misconfiguration at postmaster
start --- better to fail at startup than sometime later. But I'm
not sure how reliably we could do that.
I think that we could do something close to the area where
RemovePromoteSignalFiles
On Wed, 2019-11-13 at 17:17 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > I realized only today that if role A is a member of role B,
> > A can ALTER and DROP objects owned by B.
> > I don't have a problem with that, but the documentation seems to
> > suggest otherwise. For example, for DROP
Hi
út 12. 11. 2019 v 22:51 odesílatel Nikita Glukhov
napsal:
> On 12.11.2019 20:54, Pavel Stehule wrote:
>
> > Hi
> >
> > please, can you rebase 0001-SQL-JSON-functions-v40.patch. I have a
> > problem with patching
> >
> > Pavel
>
> Attached 41th version of the patches rebased onto current maste
Hi Amul,
On Fri, Nov 15, 2019 at 2:21 PM amul sul wrote:
> Thank you Fujita san for the patch & the enhancements. I am fine with your
> delta patch.
OK, I'll merge the delta patch with the main one in the next version,
if no objections from others.
> I would like to share some thought for othe
On Thu, Nov 14, 2019 at 9:20 PM Tom Lane wrote:
> Gareth Palmer writes:
> >> On 19/08/2019, at 3:00 AM, Tom Lane wrote:
> >> Perhaps the way to resolve Peter's objection is to make the syntax
> >> more fully like UPDATE:
> >> INSERT INTO target SET c1 = x, c2 = y+z, ... FROM
> tables-provid
HelLo!
On 11/9/19 5:26 AM, Michael Paquier wrote:
On Fri, Nov 08, 2019 at 06:03:06PM +0900, Michael Paquier wrote:
I have begun looking at this one.
Another question I have: do we need to care more about other extra
ACLs applied to other object types? For example a subset of columns
on a tabl
Thanks for testing. I am opening a new item in the next commitfest for this
topic.
On Fri, Nov 15, 2019 at 5:23 AM Tang, Haiying
wrote:
> >In order to make it work both things are needed, setting the console mode
> and a terminal that supports it.
>
>
>
> Your patch worked fine on windows which
58 matches
Mail list logo
