On Sun, Nov 5, 2017 at 6:54 AM, Andres Freund wrote
> On 2017-11-05 01:05:59 +0100, Robert Haas wrote:
>> skip-gather-project-v1.patch does what it says on the tin. I still
>> don't have a test case for this, and I didn't find that it helped very
>> much,
I am also wondering
On Sat, Oct 21, 2017 at 1:39 AM, Aleksandr Parfenov
wrote:
> In attachment updated patch with fixes of empty XML tags in
> documentation.
Hi Aleksandr,
I'm not sure if this is expected at this stage, but just in case you
aren't aware, with this version of the patch
On Fri, Oct 20, 2017 at 9:05 AM, Nico Williams wrote:
> Rebased (there were conflicts in the SGML files).
Hi Nico
FYI that version has some stray absolute paths in constraints.source:
-COPY COPY_TBL FROM '@abs_srcdir@/data/constro.data';
+COPY COPY_TBL FROM
On 2017/11/06 12:53, David Rowley wrote:
> On 3 November 2017 at 17:32, David Rowley
> wrote:
>> 2. This code is way more complex than it needs to be.
>>
>> if (num_parts > 0)
>> {
>> int j;
>>
>> all_indexes = (int *) palloc(num_parts * sizeof(int));
>> j = 0;
>>
On Mon, Sep 11, 2017 at 7:43 PM, Yuto Hayamizu wrote:
> Suppose that there are three qual clauses in a scan node, current
> postgres estimates per-tuple cost of the filter to be:
>cost(A) + cost(B) + cost(C)
>
> And basic idea of the attached patch is:
>cost(A) +
Hi pgsql-hackers,
Here's a little draft patch to add *some* tab completion ability for
SELECT in psql. I have often missed the ability, especially with
invocations of utility functions.
It would be nice to be able to suggest column names from the relevant
tables in the query, but, as the SQL
On Sat, Nov 4, 2017 at 2:03 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Fri, Nov 3, 2017 at 1:10 AM, Amit Kapila wrote:
>>> On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane wrote:
I've marked the
On 31 October 2017 at 21:43, Amit Langote wrote:
> Attached updated version of the patches
match_clauses_to_partkey() needs to allow for the way quals on Bool
columns are represented.
create table pt (a bool not null) partition by list (a);
create table pt_true
Never mind, it turns out the issue boiled down to me declaring the
wrong prefixType in my config function.
TL;DR - PEBKAC
On Sun, Nov 5, 2017 at 1:09 AM, Connor Wolf wrote:
> Ok, I've got everything compiling and it installs properly, but I'm
> running into
On 3 November 2017 at 17:32, David Rowley wrote:
> 2. This code is way more complex than it needs to be.
>
> if (num_parts > 0)
> {
> int j;
>
> all_indexes = (int *) palloc(num_parts * sizeof(int));
> j = 0;
> if (min_part_idx >= 0 && max_part_idx >= 0)
> {
> for (i
Andres Freund writes:
> Well, the current approach afaics requires #relations * 2 locks, whereas
> acquiring them in every worker would scale that with the number of
> workers.
Yeah, that's gonna be a problem with this proposal.
> IIUC the problem here is that even though a
Robert Haas writes:
> This looks like it's on the right track to me. I hope Tom will look
> into it, but if he doesn't I may try to get it committed myself.
I do plan to take a look at it during this CF.
> +/* Set or update cheapest_total_path and related fields
On 31 October 2017 at 17:43, Kyotaro HORIGUCHI
wrote:
> Hello, this is a rebased version.
>
> It gets a change of the meaning of monitoring value along with
> rebasing.
>
> In previous version, the "live" column mysteriously predicts the
> necessary segments will
Peter Geoghegan writes:
> Andres Freund wrote:
>> The number of index lookups that failed to return anything can be a
>> critical performance factor in OLTP workloads. Therefore it seems like
>> it'd be a good idea to extend the explain analyze output to
Robert Haas writes:
> A basic problem here is that, as proposed, DROP COMPRESSION METHOD may
> break your database irretrievably. If there's no data compressed
> using the compression method you dropped, everything is cool -
> otherwise everything is broken and there's no
On 2017/11/03 21:39, Alvaro Herrera wrote:
> Ashutosh Bapat wrote:
>> On Fri, Nov 3, 2017 at 1:42 PM, Alvaro Herrera
>> wrote:
>
>>> I think adding "is partitioned" at end of line isn't good; looks like a
>>> phrase but isn't translatable. Maybe add keyword PARTITIONED
On Fri, Sep 8, 2017 at 3:58 AM, Konstantin Knizhnik
wrote:
> Updated version of the patch is attached to this mail.
> Also I added support of date type to operator_predicate_proof to be able to
> imply (logdate <= '2017-03-31') from (logdate < '2017-04-01') .
Hi
On 2017/11/03 6:24, Tom Lane wrote:
> Amit Langote writes:
>> On 2017/09/26 16:30, Michael Paquier wrote:
>>> Cool, let's switch it back to a ready for committer status then.
>
>> Sure, thanks.
>
> Pushed with some cosmetic adjustments --- mostly, making the
On Tue, Oct 31, 2017 at 10:43 PM, Kyotaro HORIGUCHI
wrote:
> Hello, this is a rebased version.
Hello Horiguchi-san,
I think the "ddl" test under contrib/test_decoding also needs to be
updated because it looks at pg_replication_slots and doesn't expect
your new
> If there's no data compressed
> using the compression method you dropped, everything is cool -
> otherwise everything is broken and there's no way to recover.
> The only obvious alternative is to disallow DROP altogether (or make it
> not really DROP).
Wouldn't whatever was using the
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Simon Riggs
> A backend-based solution is required for PL procedures and functions.
>
> We could put this as an option into PL/pgSQL, but it seems like it is
> a function of the transaction manager
On 2017-11-05 17:38:39 -0500, Robert Haas wrote:
> On Sun, Nov 5, 2017 at 5:17 AM, Lucas wrote:
> > The patch creates a "--lock-early" option which will make pg_dump to issue
> > shared locks on all tables on the backup TOC on each parallel worker start.
> > That way, the
On Sun, Nov 5, 2017 at 5:17 AM, Lucas wrote:
> The patch creates a "--lock-early" option which will make pg_dump to issue
> shared locks on all tables on the backup TOC on each parallel worker start.
> That way, the backup has a very small chance of failing. When it does,
>
On Sun, Nov 5, 2017 at 2:22 PM, Oleg Bartunov wrote:
>> IIRC there were some concerns about what happened with pg_upgrade,
>> with consuming precious toast bits, and a few other things.
>
> yes, pg_upgrade may be a problem.
A basic problem here is that, as proposed, DROP
On Sun, Nov 5, 2017 at 12:57 AM, Amit Kapila wrote:
> Thanks for the confirmation. Find rebased patch attached.
This looks like it's on the right track to me. I hope Tom will look
into it, but if he doesn't I may try to get it committed myself.
-if
Hi,
On November 5, 2017 1:33:24 PM PST, Jim Van Fleet wrote:
>Ran this change with hammerdb on a power 8 firestone
>
>with 2 socket, 20 core
>9.6 base-- 451991 NOPM
>0926_master -- 464385 NOPM
>11_04master -- 449177 NOPM
>11_04_patch -- 431423 NOPM
>-- two socket
Ran this change with hammerdb on a power 8 firestone
with 2 socket, 20 core
9.6 base-- 451991 NOPM
0926_master -- 464385 NOPM
11_04master -- 449177 NOPM
11_04_patch -- 431423 NOPM
-- two socket patch is a little down from previous base runs
With one socket
9.6 base -- 393727
Andres Freund wrote:
The number of index lookups that failed to return anything can be a
critical performance factor in OLTP workloads. Therefore it seems like
it'd be a good idea to extend the explain analyze output to include that
information.
I certainly agree.
I've
On Fri, Nov 3, 2017 at 5:57 PM, Alexander Korotkov
wrote:
> On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas wrote:
>> > I can propose following alternative approach: teach read-only queries on
>> > hot
>> > standby to tolerate concurrent relation
On Thu, Nov 2, 2017 at 6:02 PM, Craig Ringer wrote:
> On 2 November 2017 at 17:41, Ildus Kurbangaliev
> wrote:
>
>> In this patch compression methods is suitable for MAIN and EXTENDED
>> storages like in current implementation in postgres.
On Sat, Nov 4, 2017 at 8:07 PM, Юрий Соколов wrote:
> 2017-11-03 5:46 GMT+03:00 Tom Lane :
>>
>> Sokolov Yura writes:
>> > [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ]
>>
>> I went to check the shellsort
On Sat, Nov 04, 2017 at 12:23:36PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I plan to use the attached patch after the minor release tags land. If
> > there's significant support, I could instead push before the wrap.
>
> This looks fine to me --- I think you should
Hi
2017-11-05 4:07 GMT+01:00 Noah Misch :
> On Tue, Oct 17, 2017 at 06:06:40AM +0200, Pavel Stehule wrote:
> > Please, if you can, try it write. I am little bit lost :)
>
> I'm attaching the patch I desired. Please review. This will probably miss
> this week's minor
On Sat, Nov 4, 2017 at 4:04 AM, Michael Paquier
wrote:
> On Fri, Nov 3, 2017 at 4:04 PM, Petr Jelinek
> wrote:
> > Not specific problem to this patch, but I wonder if it should be made
> > more clear that those files (there are couple
On Thu, Nov 2, 2017 at 5:18 PM, Bernd Helmle wrote:
> Please find a minor comment fix for receivelog.c, HandleCopyStream().
>
> The comments talks about a START_STREAMING command, but i think
> START_REPLICATION is what's meant here.
>
Yeah, it is. Confusingly enough,
On Sat, Nov 4, 2017 at 10:02 PM, Amit Kapila
wrote:
> On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane wrote:
> > Paul Ramsey writes:
> >>> Whether I get a parallel aggregate seems entirely determined by the
> number
> >>> of
On Sun, Nov 5, 2017 at 2:24 AM, Andres Freund wrote:
>> shm-mq-reduce-receiver-latch-set-v1.patch causes the receiver to only
>> consume input from the shared queue when the amount of unconsumed
>> input exceeds 1/4 of the queue size. This caused a large performance
>>
On Sun, Nov 5, 2017 at 7:17 PM, Lucas wrote:
> The patch creates a "--lock-early" option which will make pg_dump to issue
> shared locks on all tables on the backup TOC on each parallel worker start.
> That way, the backup has a very small chance of failing. When it does,
>
Ok, I've got everything compiling and it installs properly, but I'm running
into problems that I think are either a side-effect of implementing
picksplit incorrectly (likely), or a bug in SP-GiST(?).
Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at
On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane wrote:
> Paul Ramsey writes:
>>> Whether I get a parallel aggregate seems entirely determined by the number
>>> of rows, not the cost of preparing those rows.
>
>> This is true, as far as I can tell and
On Thu, Sep 21, 2017 at 2:35 AM, Jeff Janes wrote:
> On Tue, Sep 19, 2017 at 9:15 PM, Amit Kapila
> wrote:
>>
>> On Wed, Sep 20, 2017 at 3:05 AM, Jeff Janes wrote:
>> > On Tue, Sep 19, 2017 at 1:17 PM, Thomas Munro
>> >
On Tue, Oct 17, 2017 at 06:06:40AM +0200, Pavel Stehule wrote:
> Please, if you can, try it write. I am little bit lost :)
I'm attaching the patch I desired. Please review. This will probably miss
this week's minor releases. If there's significant support, I could instead
push before the wrap.
On 2017-11-05 01:05:59 +0100, Robert Haas wrote:
> skip-gather-project-v1.patch does what it says on the tin. I still
> don't have a test case for this, and I didn't find that it helped very
> much, but it would probably help more in a test case with more
> columns, and you said this looked like
On Sat, Nov 4, 2017 at 5:55 PM, Andres Freund wrote:
>> master: 21436.745, 20978.355, 19918.617
>> patch: 15896.573, 15880.652, 15967.176
>>
>> Median-to-median, that's about a 24% improvement.
>
> Neat!
With the attached stack of 4 patches, I get: 10811.768 ms, 10743.424
ms,
Юрий Соколов wrote:
tps is also reflects changes:
~17ktps with qsort
~19ktps with bucket sort
Also vacuum of benchmark's table is also improved:
~3s with qsort,
~2.4s with bucket sort
One thing that you have to be careful with when it comes to our qsort
with partially
2017-11-03 5:46 GMT+03:00 Tom Lane :
>
> Sokolov Yura writes:
> > [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ]
>
> I went to check the shellsort algorithm against Wikipedia's entry,
> and found that this appears to be an incorrect
... at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=42de8a0255c2509bf179205e94b9d65f9d6f3cf9
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 10/5/17, 11:53 PM, "Jing Wang" wrote:
> The patch has been updated according to Nathan's comments.
> Thanks Nathan's review.
Thanks for the new versions of the patches. I apologize for
the long delay for this new review.
It looks like the no-pgdump patch needs a
Just leave it as char*. If you change the endptr argument you're going to
force every call site to change their return variable, and some of them
would end up having to cast away the const on their end.
OK, here is an updated patch with the controversial bits removed.
I'm in general favor
Hi,
right now it's hard to figure out whether a plain indexscan returns
matches that then get eliminated due to visibility checks in the
heap. For both index only scans (via "Heap Fetches") and bitmapscans
(via row mismatches between bitmap heap and index scans) one can gather
that to some degree
On Sat, Nov 4, 2017 at 1:23 AM, Michael Paquier
wrote:
>
> On Fri, Nov 3, 2017 at 1:55 PM, Fabrízio de Royes Mello
> wrote:
> >> Passing the database name and user name does not look much useful to
> >> me. You can have access to this data
On 2017-11-04 06:15:00 -0700, Andres Freund wrote:
> The current testcase, and I think the descriptions in the relevant
> threads, all actually fail to point out the precise way the bug is
> triggered. As e.g. evidenced that the freeze-the-dead case appears to
> not cause any failures in
Hi,
On 2017-11-04 16:38:31 +0530, Robert Haas wrote:
> On hydra (PPC), these changes didn't help much. Timings:
>
> master: 29605.582, 29753.417, 30160.485
> patch: 28218.396, 27986.951, 26465.584
>
> That's about a 5-6% improvement. On my MacBook, though, the
> improvement was quite a bit
Noah Misch writes:
> I plan to use the attached patch after the minor release tags land. If
> there's significant support, I could instead push before the wrap.
This looks fine to me --- I think you should push now.
(which reminds me, I'd better get on with making release
On 10/29/17 08:50, Michael Paquier wrote:
> On Thu, Oct 26, 2017 at 9:25 AM, Peter Eisentraut
> wrote:
>> Here is an updated patch set. This is just a rebase of the previous
>> set, no substantial changes. Based on the discussion so far, I'm
>> proposing that
On 2017-11-03 12:36:59 -0700, Peter Geoghegan wrote:
> Andres Freund wrote:
> > Here's that patch. I've stared at this some, and Robert did too. Robert
> > mentioned that the commit message might need some polish and I'm not
> > 100% sure about the error message texts yet.
>
Peter Eisentraut wrote:
> > CREATE PROCEDURE test()
> > LANGUAGE plpgsql
> > AS $$
> > RETURN QUERY EXECUTE 'SELECT 1 AS col1, 2 AS col2';
> > END;
> > $$;
> >
> > Or is that not possible or not desirable?
>
> RETURN means the execution ends there, so how would you return
Moin,
On Fri, November 3, 2017 7:13 pm, Tom Lane wrote:
> Paul Ramsey writes:
>>> Whether I get a parallel aggregate seems entirely determined by the
>>> number
>>> of rows, not the cost of preparing those rows.
>
>> This is true, as far as I can tell and unfortunate.
On 11/3/17 13:54, Tom Lane wrote:
>> Would you prefer leaving the input argument as char *, or change the
>> endptr argument to const as well?
>
> Just leave it as char*. If you change the endptr argument you're going to
> force every call site to change their return variable, and some of them
>
Hello Raúl,
Sorry about the patch. Attaching it now so it can be considered as
submitted.
There is a typo in the XML doc:
1024.0/
Please check that the documentation compiles.
I'm at odds with having the integer version rely on a double pow(), even
if it works. I think that there
On Wed, Oct 18, 2017 at 3:09 AM, Andres Freund wrote:
> 2) The spinlocks both on the the sending and receiving side a quite hot:
>
>rafia query leader:
> + 36.16% postgres postgres[.] shm_mq_receive
> + 19.49% postgres postgres[.] s_lock
> +
Hello Pavel,
Here is a v13, which is just a rebase after the documentation xml-ization.
Here is a v14, after yet another rebase, and some comments added to answer
your new comments.
I am looking to this patch.
Not sure if "cset" is best name - maybe "eset" .. like embeded set?
I used
On Mon, Aug 21, 2017 at 07:41:52AM +0100, Simon Riggs wrote:
> On 19 August 2017 at 20:54, Noah Misch wrote:
> > On Tue, Dec 06, 2016 at 01:59:18PM -0500, Robert Haas wrote:
> >> On Tue, Dec 6, 2016 at 1:36 PM, Tom Lane wrote:
> >> > Robert Haas
On Fri, Nov 3, 2017 at 1:55 PM, Fabrízio de Royes Mello
wrote:
>> Passing the database name and user name does not look much useful to
>> me. You can have access to this data already with CurrentUserId and
>> MyDatabaseId.
>
> This way we don't need to convert oid to
On Fri, Nov 3, 2017 at 4:04 PM, Petr Jelinek
wrote:
> Not specific problem to this patch, but I wonder if it should be made
> more clear that those files (there are couple above of what you added)
> are skipped no matter which directory they reside in.
Agreed, it is
On Fri, Nov 3, 2017 at 4:30 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
>>> BTW, the originally given test case shows no measurable improvement
>>> on my box.
>
>> I did manage
Paul Ramsey writes:
>> Whether I get a parallel aggregate seems entirely determined by the number
>> of rows, not the cost of preparing those rows.
> This is true, as far as I can tell and unfortunate. Feeding tables with
> 100ks of rows, I get parallel plans, feeding
Just clarifying myself a little, since I made a dumb error partway through.
On Thu, Nov 2, 2017 at 10:09 AM, Paul Ramsey
wrote:
> I'm working on a custom aggregate, that generates a serialized data
> format. The preparation of the geometry before being formatted is
On Fri, Nov 3, 2017 at 12:37 PM, Connor Wolf <
conn...@imaginaryindustries.com> wrote:
> EDIT: That's actually exactly how the example I'm working off of works.
> DERP. The SQL is
>
> CREATE TYPE vptree_area AS
> (
> center _int4,
> distance float8
> );
>
> CREATE OR REPLACE FUNCTION
On Wed, Nov 1, 2017 at 5:55 AM, Masahiko Sawada
wrote:
> On Tue, Oct 31, 2017 at 6:17 PM, Alexander Korotkov
> wrote:
> > On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada
> > wrote:
> >>
> >> On Mon, Oct 30, 2017 at 10:16
On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas wrote:
> On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov
> wrote:
> > However, from user prospective of view, current behavior of
> > hot_standby_feedback is just broken, because it both increases
On Fri, Nov 3, 2017 at 1:34 PM, Tom Lane wrote:
> Jeff Janes writes:
> > With this v3 patch (assuming this is the one you just committed
> > as ec42a1dcb30de235b252f6d4) am now getting make check failures.
>
> There's a followup commit already :-(
>
>
I wrote:
> Have not looked at the 0002 patch yet.
I looked at that one, and it seems to be a potential win with no
downside, so pushed. (I tweaked it slightly to avoid an unnecessary
conflict with the test patch I posted earlier.)
regards, tom lane
--
Sent via
Jeff Janes writes:
> With this v3 patch (assuming this is the one you just committed
> as ec42a1dcb30de235b252f6d4) am now getting make check failures.
There's a followup commit already :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list
On November 4, 2017 1:22:04 AM GMT+05:30, Alvaro Herrera
wrote:
>Peter Geoghegan wrote:
>> Andres Freund wrote:
>
>> > Staring at the vacuumlazy hunk I think I might have found a related
>bug:
>> > heap_update_tuple() just copies the old xmax to
Michael Paquier writes:
> On Fri, Nov 3, 2017 at 1:10 AM, Amit Kapila wrote:
>> On Fri, Nov 3, 2017 at 2:54 AM, Tom Lane wrote:
>>> I've marked the CF entry closed. However, I'm not sure if we're quite
>>> done with this
Alvaro Herrera wrote:
He means that the tuple that heap_update moves to page 1 (which will no
longer be processed by vacuum) will contain a multixact that's older
than relminmxid -- because it is copied unchanged by heap_update instead
of properly checking against age
Hi Alvaro,
With this v3 patch (assuming this is the one you just committed
as ec42a1dcb30de235b252f6d4) am now getting make check failures.
brin_summarize_range is returning unexpected values.
CentOS6,
PostgreSQL 11devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat
On Sat, Nov 4, 2017 at 2:05 AM, Thomas Munro
wrote:
> That
> said, I've only tested the attached lightly on FreeBSD + OpenLDAP and
> don't know if it'll work elsewhere.
Oops, that version's TAP test was a little too dependent on my
system's ldap.conf file. Here's
Alvaro Herrera wrote:
> I think your argument is sensible for some uses (where people run manual
> VACUUM after loading data) but not others (where people just use manual
> VACUUM in place of autovacuuming -- because they don't trust autovac, or
> the schedule isn't convenient, or whatever other
Peter Geoghegan wrote:
> Andres Freund wrote:
> > Staring at the vacuumlazy hunk I think I might have found a related bug:
> > heap_update_tuple() just copies the old xmax to the new tuple's xmax if
> > a multixact and still running. It does so without verifying liveliness
>
Alvaro Herrera writes:
> Thomas Munro wrote:
>> src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth
>> implementation that originally arrived in commit df4cba68, but the
>> upstream code[1] apparently continued evolving and there have been
>> more Unicode
Andres Freund wrote:
Here's that patch. I've stared at this some, and Robert did too. Robert
mentioned that the commit message might need some polish and I'm not
100% sure about the error message texts yet.
The commit message should probably say that the bug involves the
Claudio Freire writes:
> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
>> BTW, the originally given test case shows no measurable improvement
>> on my box.
> I did manage to reproduce the original test and got a consistent improvement.
It occurred
Alvaro Herrera writes:
> Tom Lane wrote:
>> It might work to build the new key in a context that's initially a
>> child of CurrentMemoryContext, then reparent it to be a child of
>> CacheMemoryContext when done.
> That's another way (than the PG_TRY block), but I think
Thomas Munro wrote:
> Hi hackers,
>
> src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth
> implementation that originally arrived in commit df4cba68, but the
> upstream code[1] apparently continued evolving and there have been
> more Unicode revisions since. It probably doesn't matter
Thomas Munro wrote:
> Hi hackers,
>
> src/backend/utils/mb/wchar.c contains a ~16 year old wcwidth
> implementation that originally arrived in commit df4cba68, but the
> upstream code[1] apparently continued evolving and there have been
> more Unicode revisions since.
I think we should update it
> Robert Haas writes:
> > We could do that, but the motivation for the current system was to
> > avoid leaking memory in a long-lived context.
Yeah, my approach here is to use a CATCH block that deletes the memory
context just created, thus avoiding a long-lived leak.
Chapman Flack writes:
> From a little experimenting in 9.5, it seems that a referential
> integrity trigger is executed with the identity of the referencED
> table's owner, but I have not been able to find this covered in
> the docs. Is this a documentation oversight, or is
On Fri, Nov 03, 2017 at 02:09:00PM -0400, Chapman Flack wrote:
> From a little experimenting in 9.5, it seems that a referential
> integrity trigger is executed with the identity of the referencED
> table's owner, but I have not been able to find this covered in
> the docs. Is this a documentation
>From a little experimenting in 9.5, it seems that a referential
integrity trigger is executed with the identity of the referencED
table's owner, but I have not been able to find this covered in
the docs. Is this a documentation oversight, or is it explained
somewhere I didn't look (or may have
On Fri, Nov 03, 2017 at 01:41:45PM -0400, Peter Eisentraut wrote:
> On 11/2/17 16:54, Nico Williams wrote:
> > Replacing condeferred and condeferrable with a char columns also
> > occurred to me, and though I assume backwards-incompatible changes to
> > pg_catalog tables are fair game, I assumed
On 11/2/17 16:40, Daniel Verite wrote:
> But instead of having procedures not return anything,
> couldn't they return whatever resultset(s) they want to
> ("no resultset" being just a particular case of "anything"),
> so that we could leave out cursors and simply write:
We could in general design
Peter Eisentraut writes:
> On 10/31/17 10:56, Tom Lane wrote:
>>> Some functions have a strtol()-like behavior
>>> where they take in a const char * and return a pointer into that as
>>> another argument. In those cases, I added a cast or two.
>> ... but I'm
On 11/1/17 22:40, Robert Haas wrote:
> That seems like it is at least arguably a wire protocol break. Today,
> if you send a string containing only one command, you will only get
> one answer.
The wire protocol already supports this. And the wire protocol doesn't
really know about statements,
On 11/1/17 06:23, Pavel Stehule wrote:
> We need to think about how the \timing option should work in such
> scenarios. Right now it does
> Has the total time sense in this case?
>
> should not be total time related to any fetched result?
The \timing option in psql measures from the
On 11/2/17 19:52, Stephen Frost wrote:
> Uh, libpq doesn't actually have symbol versioning, at least not on the
> installed Ubuntu packages for PG10, as shown by objdump -T :
You're right, I was dreaming. But in any case, he would need symbol
versioning of libssl.
--
Peter Eisentraut
On 11/2/17 16:54, Nico Williams wrote:
> Replacing condeferred and condeferrable with a char columns also
> occurred to me, and though I assume backwards-incompatible changes to
> pg_catalog tables are fair game, I assumed everyone would prefer
> avoiding such changes where possible.
I don't
On 10/31/17 10:56, Tom Lane wrote:
>> Some functions have a strtol()-like behavior
>> where they take in a const char * and return a pointer into that as
>> another argument. In those cases, I added a cast or two.
> ... but I'm not sure that it's an improvement in cases where you have to
> cast
Simon Riggs wrote:
The *only* behavioural difference I have proposed would be the *lack*
of an ERROR in (some) concurrent cases.
I think that's a big difference. Error vs. non-error is a big deal by
itself;
Are you saying avoiding an ERROR is a bad or good thing?
401 - 500 of 318634 matches
Mail list logo