Hi Shawn,
On Wed, Aug 15, 2018 at 9:35 AM, Shawn Debnath wrote:
> At the Unconference in Ottawa this year, I pitched the idea of moving
> components off of SLRU and on to the buffer cache. The motivation
> behind the idea was three fold:
>
> * Improve performance by eliminating fixed sized
Hi,
I found some improvements in Client Applications in /src/bin/scripts when I
resumed development of progress monitor for cluster command.
Attached patch gives the following query a semicolon for readability.
s/SELECT pg_catalog.set_config ('search_path', '', false)/
SELECT
On 2018/08/15 12:25, Etsuro Fujita wrote:
> (2018/08/15 0:51), Robert Haas wrote:
>> On Mon, Aug 13, 2018 at 12:32 PM, Etsuro Fujita
>> wrote:
>>> One thing I noticed might be an improvement is to skip
>>> build_joinrel_partition_info if the given joinrel will be to have
>>>
(2018/08/15 0:51), Robert Haas wrote:
On Mon, Aug 13, 2018 at 12:32 PM, Etsuro Fujita
wrote:
One thing I noticed might be an improvement is to skip
build_joinrel_partition_info if the given joinrel will be to have
consider_partitionwise_join=false; in the previous patch, that function
created
On Tue, Aug 14, 2018 at 04:42:43PM -0400, Bruce Momjian wrote:
> On Tue, Aug 14, 2018 at 04:23:33PM -0400, Robert Haas wrote:
> > On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian wrote:
> > > I am unclear how lexical scoping helps with this, or with Postgres.
> >
> > Well, if you say sqrt(x) in C,
Hi.
Even if you apply "data-at-rest-encryption-wip-2018.07.25.patch" to the master
branch,
the same patch error will occur.
(Patch error of pg_rewind was eliminated)
patching file src/backend/replication/logical/reorderbuffer.c
Hunk #9 FAILED at 2464.
patching file
Yes, I had read this document, BUT it's call from PL/PGSQL. I want call it
from c function.
2018-08-13 18:57 GMT+08:00 Robert Haas :
> On Fri, Aug 10, 2018 at 5:50 AM, 王翔宇 wrote:
> > I'm developing a extension for pg. Now I have create a event trigger on
> > ddl_command_end, and this function
On Wed, Aug 15, 2018 at 11:08 AM, Asim R P wrote:
> I was looking at the commitfest entry for feature
> (https://commitfest.postgresql.org/19/1639/) for the most recent list
> of patches to try out. The list doesn't look correct/complete. Can
> someone please check?
Hi Asim,
This thread is a
I noticed that src/port/snprintf.c still follows the old (pre-C99)
semantics for what to return from snprintf() after buffer overrun.
This seems bad for a couple of reasons:
* It results in potential performance loss in psnprintf and
appendPQExpBufferVA, since those have to fly blind about how
On 08/14/2018 07:01 PM, Nico Williams wrote:
> On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
>> The more I think about it, the more I think having a way to set a
>> lexically-scoped search path is probably the answer. [...]
>
> Yes please!
>
> This is what I want. Evaluate the
On 12 August 2018 at 20:07, David Rowley wrote:
>> Since range scan execution is rather different from the existing
>> TidScan execution, I ended up making a new plan type, TidRangeScan.
>> There is still only one TidPath, but it has an additional member that
>> describes which method to use.
>
>
I was looking at the commitfest entry for feature
(https://commitfest.postgresql.org/19/1639/) for the most recent list
of patches to try out. The list doesn't look correct/complete. Can
someone please check?
Asim
On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
> The more I think about it, the more I think having a way to set a
> lexically-scoped search path is probably the answer. [...]
Yes please!
This is what I want. Evaluate the search_path at function definition
time, and record code
On Tue, Aug 14, 2018 at 2:07 PM, Todd A. Cook wrote:
> Sorry, I just noticed this. Mantid is my animal, so I can set
> "min_parallel_table_scan_size = 0"
> on it if that would be helpful. (Please reply directly if so; I'm not able
> to keep up with pgsql-hackers
> right now.)
We've already
On 8/14/18 10:05 AM, Tomas Vondra wrote:
...
>
I take that back - I can reproduce the crashes, both with and without
the patch, all the way back to 9.6. Attached is a bunch of backtraces
from various versions. There's a bit of variability depending on which
pgbench script gets started
On 8/9/18, 12:56 AM, "Peter Geoghegan" wrote:
On Wed, Aug 8, 2018 at 7:40 PM, Tom Lane wrote:
>> Anyway, "VACUUM FULL pg_class" should be expected to corrupt
>> pg_class_oid_index when we happen to get a parallel build, since
>> pg_class is a mapped relation, and I've identified
> On Aug 14, 2018, at 8:00 AM, Robert Haas wrote:
>
> On Wed, Aug 8, 2018 at 1:58 PM, Tom Lane wrote:
>> I'm not sold on #2 either. That path leads to, for example,
>> s/=/OPERATOR(pg_catalog.=)/g everywhere, which is utterly catastrophic
>> to both readability and portability of your SQL
> On Aug 14, 2018, at 11:51 AM, Robert Haas wrote:
>
> On Mon, Aug 13, 2018 at 12:32 PM, Etsuro Fujita
> wrote:
>> One thing I noticed might be an improvement is to skip
>> build_joinrel_partition_info if the given joinrel will be to have
>> consider_partitionwise_join=false; in the previous
Hello Garick,
I read the rational of the host/hostaddr artificial mapping. I cannot say
I'm thrilled with the result: I do not really see a setting where avoiding a
DNS query is required but which still needs a hostname for auth... If you
have GSSAPI or SSPI then you have an underlying
On 2018-Aug-14, Fabien COELHO wrote:
> > (At least, that's true with my preferred web browser, maybe it's
> > different for other people?)
>
> So if I send with text/x-diff or text/plain I've got complaints, if I send
> with application/octet-stream, it is not right either:-) Everybody being
>
I have no doubt that some MUA around would forget to do the conversion.
FWIW, one reason that I invariably use patch(1) to apply submitted patches
is that it will take care of stripping any CRs that may have snuck in.
So I'm not particularly fussed about the problem.
Good to know.
I'm
On Tue, Aug 14, 2018 at 1:39 PM, Tom Lane wrote:
> We're kinda stuck with that. We could add FUNCTION as a preferred
> synonym, perhaps, but I doubt that'd really be worth the trouble.
Seems sufficient to note in the relevant docs that it's a legacy thing.
--
Peter Geoghegan
On Tue, Aug 14, 2018 at 04:23:33PM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian wrote:
> > Well, in C, if the calling function is not in the current C file, you
> > really don't know what function you are linking to --- it depends on
> > what other object files are
Peter Eisentraut writes:
> What should we do with the use of the keyword PROCEDURE in the CREATE
> OPERATOR and CREATE TRIGGER syntaxes?
We're kinda stuck with that. We could add FUNCTION as a preferred
synonym, perhaps, but I doubt that'd really be worth the trouble.
On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian wrote:
> Well, in C, if the calling function is not in the current C file, you
> really don't know what function you are linking to --- it depends on
> what other object files are linked into the executable.
True.
> I am unclear how lexical scoping
On Tue, Aug 14, 2018 at 03:18:32PM -0400, Garick Hamlin wrote:
> On Tue, Aug 14, 2018 at 12:24:32PM +0200, Fabien COELHO wrote:
> > I read the rational of the host/hostaddr artificial mapping. I cannot say
> > I'm thrilled with the result: I do not really see a setting where avoiding a
> > DNS
What should we do with the use of the keyword PROCEDURE in the CREATE
OPERATOR and CREATE TRIGGER syntaxes?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On Aug 14, 2018, at 10:01 AM, Tels wrote:
>
> Moin Andrew,
>
> On Tue, August 14, 2018 9:16 am, Andrew Gierth wrote:
>>> "Tom" == Tom Lane writes:
>>
Should these limits:
>>
a) be removed
>>
>> Tom> Doubt it --- we could use the "huge" request variants, maybe, but
>> Tom>
On Tue, Aug 14, 2018 at 03:00:55PM +, Robert Haas wrote:
> The more I think about it, the more I think having a way to set a
> lexically-scoped search path is probably the answer. Many years ago,
> Perl had only "local" as a way of declaring local variables, which
> used dynamic scoping, and
On Tue, Aug 14, 2018 at 12:24:32PM +0200, Fabien COELHO wrote:
>
> Hello Tom,
>
> >>As you noted in another message, a small doc update should be needed.
> >
> >Check. Proposed doc patch attached. (Only the last hunk is actually
> >specific to this patch, the rest is cleanup that I noticed
On 08/14/2018 01:44 PM, Tom Lane wrote:
Fabien COELHO writes:
I have no doubt that some MUA around would forget to do the conversion.
FWIW, one reason that I invariably use patch(1) to apply submitted patches
is that it will take care of stripping any CRs that may have snuck in.
So I'm not
Christoph Berg writes:
> The pq_sendfloat4 and 8 prototypes are duplicated.
Yup. Pushed, thanks!
regards, tom lane
On Tue, Aug 14, 2018 at 1:44 PM, Tom Lane wrote:
> Fabien COELHO writes:
>> I have no doubt that some MUA around would forget to do the conversion.
>
> FWIW, one reason that I invariably use patch(1) to apply submitted patches
> is that it will take care of stripping any CRs that may have snuck
On Tue, Aug 14, 2018 at 10:18 AM, Tom Lane wrote:
> Agreed, we'd better stop being cavalier about whether that's an
> exact synonym or not.
I made an open item for this.
--
Peter Geoghegan
Fabien COELHO writes:
> I have no doubt that some MUA around would forget to do the conversion.
FWIW, one reason that I invariably use patch(1) to apply submitted patches
is that it will take care of stripping any CRs that may have snuck in.
So I'm not particularly fussed about the problem.
I'm
Fabien COELHO writes:
> The mention of possible reverse dns queries has been removed... but I do
> not think there was any before?
Yeah, that's why I took it out. If there ever were any reverse lookups in
libpq, we got rid of them AFAICS, so this statement in the docs seemed just
unnecessarily
Hi,
On 2018-08-12 08:51:28 +0100, Shay Rojansky wrote:
> Peter, Tom,
>
> Would it be possible for you to review the following two questions? Some
> assertions have been made in this thread about the new stored procedures
> (support for dynamic and multiple resultsets) whose compatibility with
Peter Geoghegan writes:
> I noticed that the word "procedure" appears in at least a few places
> in the v11 docs as a not-quite-apt synonym of "function". For example,
> https://www.postgresql.org/docs/11/static/plpgsql-trigger.html talks
> about "PL/pgSQL Trigger Procedures" which are actually
Fabien COELHO writes:
>> Right. As before, I'm not excited about rejecting trailing junk,
>> considering we never did before.
> My 0.02¤: accepting trailing junk is just a recipee for hiding bugs:
> sh> psql "connect_timeout=2,port=5433"
> psql> \conninfo
> ... port=5432 # port directive
Moin Andrew,
On Tue, August 14, 2018 9:16 am, Andrew Gierth wrote:
>> "Tom" == Tom Lane writes:
>
> >> Should these limits:
>
> >> a) be removed
>
> Tom> Doubt it --- we could use the "huge" request variants, maybe, but
> Tom> I wonder whether the engine could run fast enough that you'd
The pq_sendfloat4 and 8 prototypes are duplicated.
Christoph
diff --git a/src/include/libpq/pqformat.h b/src/include/libpq/pqformat.h
index 6acb2e8de0..f0337325bb 100644
--- a/src/include/libpq/pqformat.h
+++ b/src/include/libpq/pqformat.h
@@ -31,9 +31,6 @@ extern void
On Mon, Aug 13, 2018 at 01:53:18PM -0300, Alvaro Herrera wrote:
> I do share Andres' concerns on the wording the comment. I would say
> something like
>
> /*
> * Reset the temporary namespace flag in MyProc. We assume this to be
> * an atomic assignment.
> *
> * Because this subtransaction
On Mon, Aug 13, 2018 at 02:15:07PM -0300, Alvaro Herrera wrote:
> If writing an OID were not atomic, the assignment would be really
> dangerous. I don't think your proposed update is good.
OK, I am withdrawing this one then.
--
Michael
signature.asc
Description: PGP signature
On Mon, Aug 13, 2018 at 10:52 AM, Jeremy Finzel wrote:
> On Thu, Aug 9, 2018 at 4:34 PM, Jeremy Finzel wrote:
>> I am using worker_spi as a model to run a SQL statement inside a
>> background worker. From my browsing of the Postgres library, I believe that
>> if I want repeatable read isolation
On Tue, Aug 14, 2018 at 03:26:29PM +, Robert Haas wrote:
> I feel like you're not being very clear about exactly what this new
> approach is. Sorry if I'm being dense.
On HEAD, we check the ownership of the relation vacuumed or analyzed
after taking a lock on it in respectively vacuum_rel()
On Tue, Aug 14, 2018 at 3:50 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> It seems to me that it would make sense if InsertPgAttributeTuple() were
>> to set attcacheoff to -1 instead of taking it from the caller.
>
> Looked this over, no objections.
>
> I wonder whether we should set that
On Mon, Aug 13, 2018 at 12:32 PM, Etsuro Fujita
wrote:
> One thing I noticed might be an improvement is to skip
> build_joinrel_partition_info if the given joinrel will be to have
> consider_partitionwise_join=false; in the previous patch, that function
> created the joinrel's partition info such
Peter Eisentraut writes:
> It seems to me that it would make sense if InsertPgAttributeTuple() were
> to set attcacheoff to -1 instead of taking it from the caller.
Looked this over, no objections.
I wonder whether we should set that field to -1 when we *read*
pg_attribute rows from disk, and
On Thu, Aug 2, 2018 at 9:06 PM Alexander Korotkov
wrote:
> On Thu, Aug 2, 2018 at 6:17 PM Alexander Korotkov
> wrote:
> > After some experiments I found that when you mix spaces and separators
> > between two fields, then Oracle takes into account only length of last
> > group of
On Sun, Aug 12, 2018 at 10:21 PM, Michael Paquier wrote:
> In the previous thread, we discussed a couple of approaches, but I was
> not happy with any of those, hence I have been spending more time in
> getting to a solution which has no user-facing changes, and still solves
> the problems folks
On Sun, Aug 12, 2018 at 8:07 AM, David Rowley
wrote:
> Thanks for working on this. It will great to see improvements made in this
> area.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Aug 8, 2018 at 1:58 PM, Tom Lane wrote:
> I'm not sold on #2 either. That path leads to, for example,
> s/=/OPERATOR(pg_catalog.=)/g everywhere, which is utterly catastrophic
> to both readability and portability of your SQL code. We *must* find
> a way to do better, not tell people
Hi Robert,
First of all thank you for review and your time spent on analyzing this
patch.
My comments are inside.
On 13.08.2018 21:47, Robert Haas wrote:
On Fri, Aug 10, 2018 at 5:55 PM, Andrew Dunstan
wrote:
This thread appears to have gone quiet. What concerns me is that there
appears to
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Doubt it --- we could use the "huge" request variants, maybe, but
> Tom> I wonder whether the engine could run fast enough that you'd want
> Tom> to.
> I do wonder (albeit without evidence) whether the quadratic slowdown
> problem I
On 08/14/2018 01:49 PM, Tomas Vondra wrote:
On 08/13/2018 04:49 PM, Andres Freund wrote:
Hi,
On 2018-08-13 11:46:30 -0300, Alvaro Herrera wrote:
On 2018-Aug-11, Tomas Vondra wrote:
Hmmm, it's difficult to compare "bt full" output, but my backtraces
look
somewhat different (and all the
Hello Andrew,
It's not done by my MUA, and it's present in your latest posted patch. If
anything I'd suspect your MUA:
andrew@emma*$ curl -s
https://www.postgresql.org/message-id/attachment/64237/pgbench-into-19.patch
Argh. Indeed, this downloaded version has CRLF. Now when I save the
The commit that started this is
commit 59a85323d9d5927a852939fa93f09d142c72c91a
Author: Peter Eisentraut
Date: Mon Jul 9 13:58:08 2018
Add UtilityReturnsTuples() support for CALL
This ensures that prepared statements for CALL can return tuples.
The change whether a statement returns
It seems to me that it would make sense if InsertPgAttributeTuple() were
to set attcacheoff to -1 instead of taking it from the caller.
InsertPgAttributeTuple() is the interface between in-memory tuple
descriptors and on-disk pg_attribute, so it makes sense to give it the
job of resetting
> "Tom" == Tom Lane writes:
>> Should these limits:
>> a) be removed
Tom> Doubt it --- we could use the "huge" request variants, maybe, but
Tom> I wonder whether the engine could run fast enough that you'd want
Tom> to.
I do wonder (albeit without evidence) whether the quadratic
> "Andrew" == Andrew Dunstan writes:
>> The patch in the original email is in text/plain with base64 transfer
>> encoding, which means that CRLF line endings are mandatory. It's
>> actually up to the receiving MUA (or the archives webserver) to undo
>> that.
>>
>> If the archives
On 08/14/2018 07:37 AM, Andrew Gierth wrote:
"Andrew" == Andrew Dunstan writes:
>>> This patch contains CRLF line endings
>>
>> Alas, not according to "file" nor "hexdump" (only 0A, no 0D) on my
>> local version, AFAICS.
>>
>> What happens on the path and what is done by mail
Hello Tom,
The thing is that there are a *lot* of systems nowadays on which localhost
maps to both ipv4 and ipv6, so that "host=localhost" would be enough to
trigger the new behavior,
I think that people would survive having the ip spelled out on localhost
errors when there are several ips
Hi
I would to introduce new flag for routines - PRIVATE. Routines with this
flag can be called only from other routines assigned with same schema.
Because these routines are not available for top queries, we can hide these
functions from some outputs like \df ..
Example:
CREATE SCHEMA s1;
2018-08-14 13:56 GMT+02:00 Pavel Stehule :
> Hi
>
> I would to introduce new flag for routines - PRIVATE. Routines with this
> flag can be called only from other routines assigned with same schema.
> Because these routines are not available for top queries, we can hide these
> functions from some
Andrew> It's not done by my MUA, and it's present in your latest posted
Andrew> patch. If anything I'd suspect your MUA:
The patch in the original email is in text/plain with base64 transfer
encoding, which means that CRLF line endings are mandatory. It's
actually up to the receiving MUA (or
On 08/13/2018 04:49 PM, Andres Freund wrote:
Hi,
On 2018-08-13 11:46:30 -0300, Alvaro Herrera wrote:
On 2018-Aug-11, Tomas Vondra wrote:
Hmmm, it's difficult to compare "bt full" output, but my backtraces look
somewhat different (and all the backtraces I'm seeing are 100% exactly
the same).
(2018/08/09 22:04), Etsuro Fujita wrote:
(2018/08/08 17:30), Kyotaro HORIGUCHI wrote:
I choosed to expand tuple descriptor for junk column added to
foreign relaions. We might be better to have new member in
ForeignScan but I didn't so that we can backpatch it.
I've not looked at the patch
> "Andrew" == Andrew Dunstan writes:
>>> This patch contains CRLF line endings
>>
>> Alas, not according to "file" nor "hexdump" (only 0A, no 0D) on my
>> local version, AFAICS.
>>
>> What happens on the path and what is done by mail clients depending
>> on the mime type is another
On 08/13/2018 06:30 PM, Fabien COELHO wrote:
Hello Andrew,
Attached is v18, another basic rebase after some perl automatic
reindentation.
This patch contains CRLF line endings
Alas, not according to "file" nor "hexdump" (only 0A, no 0D) on my
local version, AFAICS.
What happens on
Hello,
I used PostgreSQL 9.3 but I executed upgrade few days ago.
Now, I am using 10.4 PostgreSQL and:
doctrine/annotations v1.2.7
doctrine/cache v1.4.2
doctrine/collections v1.3.0
doctrine/common v2.7.3
doctrine/dbal
My opinion (if it's worth anything) is that a binary should not specify
search paths for libraries other than those explicitly provided with it as
part of its own package.
The environment should handle shared library paths, using $LD_PATH or
ldconfig or whatever. If a binary has to specify where
Hello Tom,
As you noted in another message, a small doc update should be needed.
Check. Proposed doc patch attached. (Only the last hunk is actually
specific to this patch, the rest is cleanup that I noticed while looking
around for possibly-relevant text.)
Doc build is ok.
Some
On Wed, Feb 28, 2018 at 11:24 PM, Ivan Kartyshov
wrote:
> Thank you for your valuable comments. I've made a few adjustments.
>
Thank you for working on this!
> The main goal of my changes is to let long read-only transactions run on
> replica if hot_standby_feedback is turned on.
FWIW the idea
Hello Tom,
connect_timeout=2.9 is accepted and considered as meaning 2.
connect_timeout=-10 or connect_timeout=two are also accepted and mean
forever. Probably thanks to "atoi".
Right. As before, I'm not excited about rejecting trailing junk,
considering we never did before.
My 0.02€:
Hi,
On 2018-08-14 08:44:46 +0200, Peter Eisentraut wrote:
> On 03/08/2018 15:00, Robert Haas wrote:
> > On Thu, Aug 2, 2018 at 4:44 PM, Andres Freund wrote:
> >> ISTM, if you want to increase consistency in this area, you've to go
> >> further. E.g. processing invalidations in
On 03/08/2018 15:00, Robert Haas wrote:
> On Thu, Aug 2, 2018 at 4:44 PM, Andres Freund wrote:
>> ISTM, if you want to increase consistency in this area, you've to go
>> further. E.g. processing invalidations in StartTransactionCommand() in
>> all states, which'd give you a lot more consistency.
On 31/07/2018 23:10, Peter Eisentraut wrote:
> On 27/07/2018 16:16, Robert Haas wrote:
>> With respect to this particular patch, I don't know whether there are
>> any hazards of the second type. What I'd check, if it were me, is
>> what structures in the index's relcache entry are going to get
77 matches
Mail list logo
