Hello,
COMMIT AND CHAIN in implicit block leaves blockState as TBLOCK_STARTED,
which doesn't trigger the chaining. but ROLLBACK AND CHAIN sets the
blockState into TBLOCK_ABORT_PENDING, so the chaining is triggered.
I think disabling s->chain beforehand should do the desired behavior.
Patc
Bonjour Michaël,
- *ptr && WHATEVER(*ptr)
*ptr is redundant, WHATEVER yields false on '\0', and it costs on each
char but at the end. It might be debatable in some places, e.g. it is
likely that there are no spaces in the string, but likely that there are
more than one digit.
Still t
Hi
čt 29. 8. 2019 v 5:03 odesílatel Ian Barwick
napsal:
> Hi
>
> Here:
>
>
> https://www.postgresql.org/docs/current/plpgsql-control-structures.html#PLPGSQL-RECORDS-ITERATING
>
> we have a sample PL/PgSQL function (dating from at least 7.2) demonstrating
> query result loops, which refreshes som
Hi
Here:
https://www.postgresql.org/docs/current/plpgsql-control-structures.html#PLPGSQL-RECORDS-ITERATING
we have a sample PL/PgSQL function (dating from at least 7.2) demonstrating
query result loops, which refreshes some pseudo materialized views stored in
a user-defined table.
As we've
Michael Paquier writes:
> On Wed, Aug 28, 2019 at 12:19:08PM -0400, Tom Lane wrote:
>> The attached patch just follows a mechanical rule of "set on_error_die
>> to 0 in exactly those calls where the surrounding code verifies the
>> exit code is what it expects".
> I am fine with that approach. T
On 2019-08-29 00:43, peter.eisentr...@2ndquadrant.com wrote:
> Make spaces and capitalization match surrounding code.
>That's fine, but I suggest that if you really want to make an impact in
>test coverage, look to increase function coverage rather than line
>coverage. Or look for files that
On Tue, Aug 27, 2019 at 2:09 PM Thomas Munro wrote:
> On Tue, Aug 27, 2019 at 1:48 PM Tom Lane wrote:
> > A stack trace would likely be really useful right about now.
>
> Yeah. Looking into how to get that.
Erm. I heard the system was in a very unhappy state and couldn't be
logged into. After
On Wed, Aug 28, 2019 at 12:19:08PM -0400, Tom Lane wrote:
> The attached patch just follows a mechanical rule of "set on_error_die
> to 0 in exactly those calls where the surrounding code verifies the
> exit code is what it expects". That leads to a lot of code that
> looks like, say,
>
> # Inse
On Wed, Aug 28, 2019 at 09:50:44AM +0200, Fabien COELHO wrote:
> - *ptr && WHATEVER(*ptr)
> *ptr is redundant, WHATEVER yields false on '\0', and it costs on each
> char but at the end. It might be debatable in some places, e.g. it is
> likely that there are no spaces in the string, but like
On Wed, Aug 28, 2019 at 10:22:07AM +0200, Julien Rouhaud wrote:
>>> The filtering is done at table level (with and without the
>>> concurrently option), so SCHEMA, DATABASE and SYSTEM automatically
>>> benefit from it. If this clause is used with a REINDEX INDEX, the
>>> statement errors out, as I
On Wed, Aug 28, 2019 at 08:17:47PM +0300, Alexey Kondratov wrote:
Hi Tomas,
Interesting. Any idea where does the extra overhead in this particular
case come from? It's hard to deduce that from the single flame graph,
when I don't have anything to compare it with (i.e. the flame
graph for
the
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi everyone,
The v8 patch [1] applies cleanly and passes tes
On 2019-Aug-28, Joshua Brindle wrote:
> I think we need to reign in the thread somewhat. The feature allows
> end users to define some sandboxing within PG. Nothing is being forced
> on anyone but we would like the capability to harden a PG installation
> for many reasons already stated.
My own o
On 2019-Aug-28, Thomas Kellerer wrote:
> Merlin Moncure schrieb am 28.08.2019 um 18:22:
> > My test case here is the query: pgsql-hackers
>
> That search term is the first hit on DuckDuckGo:
> https://duckduckgo.com/?q=pgsql-hackers+ExecHashJoinNewBatch&t=h_&ia=web
Yes, but that's an old post, n
On Thu, Aug 29, 2019 at 7:08 AM Joshua Brindle
wrote:
> On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
> > On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > > A prime example is madvise() which was a catastrophic failure that 1)
> > > isn't preventable by any LSM including SELinux, 2)
On 2019-08-28 21:38, Joshua Brindle wrote:
> I think we need to reign in the thread somewhat. The feature allows
> end users to define some sandboxing within PG. Nothing is being forced
> on anyone
Features come with a maintenance cost. If we ship it, then people are
going to try it out. Then we
I started to review this patch yesterday with Melanie Plageman, so we
rebased this patch over the current master. The main conflicts were
due to a simplehash patch that has been committed separately[1]. I've
attached the rebased patch.
I was playing with the code, and if one of the table's most co
Hi,
On 2019-08-28 15:38:11 -0400, Joshua Brindle wrote:
> It seems like complete system compromises should be prioritized over
> slowdowns, and it seems very unlikely to cause a noticeable slowdown
> anyway.
The point isn't really this specific issue, but that the argument that
you'll not cause p
On Wed, Aug 28, 2019 at 3:22 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-28 15:02:17 -0400, Joshua Brindle wrote:
> > On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
> > > On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > > > A prime example is madvise() which was a catastrophic fai
> Sorry for long delay. Here is more or less what I had in mind. After changing
> read_closest to read the whole page I couldn't resist to just merge it into
> readpage itself, since it's basically the same. It could raise questions
> about>
> performance and how intrusive this patch is, but I ho
Hi,
On 2019-08-28 15:02:17 -0400, Joshua Brindle wrote:
> On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
> > On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > > A prime example is madvise() which was a catastrophic failure that 1)
> > > isn't preventable by any LSM including SELinux,
Andres Freund writes:
> On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
>> A prime example is madvise() which was a catastrophic failure that 1)
>> isn't preventable by any LSM including SELinux, 2) isn't used by PG
>> and is therefore a good candidate for a kill list, and 3) a clear win
>> in
On Wed, Aug 28, 2019 at 2:53 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> > A prime example is madvise() which was a catastrophic failure that 1)
> > isn't preventable by any LSM including SELinux, 2) isn't used by PG
> > and is therefore a good candida
On Tue, Aug 27, 2019 at 8:30 PM Michael Paquier wrote:
> Please note that I have not looked in details where we could put that,
> but perhaps Robert and Peter G who worked on 4ea51cd to add support
> for abbreviated keys have some ideas, so I am adding them in CC for
> input.
Movead is correct --
Andres Freund writes:
> On 2019-08-28 14:30:20 -0400, Tom Lane wrote:
>> Admittedly, you can't get per-subprocess restrictions that way, but the
>> incremental value from that seems *really* tiny. If listen() has a bug
>> you need to fix the bug, not invent this amount of rickety infrastructure
>
On Wed, Aug 28, 2019 at 2:30 PM Tom Lane wrote:
>
>
> (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
Just going to address this one now. SELinux is an LSM and therefore
only makes decisions when LSM hooks are invoked, which are not 1:1 for
syscalls (not even close). F
Hi,
On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote:
> A prime example is madvise() which was a catastrophic failure that 1)
> isn't preventable by any LSM including SELinux, 2) isn't used by PG
> and is therefore a good candidate for a kill list, and 3) a clear win
> in the dont-let-PG-be-a-ve
On Wed, Aug 28, 2019 at 2:47 PM Joshua Brindle
wrote:
>
> On Wed, Aug 28, 2019 at 2:30 PM Tom Lane wrote:
> >
>
> >
> > (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
>
> Just going to address this one now. SELinux is an LSM and therefore
> only makes decisions when L
On 2019-08-28 14:30:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Maybe I'm missing something, but it's not clear to me what meaningful
> > attack surface can be reduced for PostgreSQL by forbidding certain
> > syscalls, given the wide variety of syscalls required to run postgres.
>
> I t
Hi,
On 2019-08-28 14:23:00 -0400, Joshua Brindle wrote:
> > or some similar technology where the filtering is done by logic
> > that's outside the executable you wish to not trust.
> > (After googling for libseccomp, I see that it's supposed to not
> > allow syscalls to be turned back on once turn
Andres Freund writes:
> Maybe I'm missing something, but it's not clear to me what meaningful
> attack surface can be reduced for PostgreSQL by forbidding certain
> syscalls, given the wide variety of syscalls required to run postgres.
I think the idea is to block access to seldom-used syscalls b
On Wed, Aug 28, 2019 at 1:42 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > On 2019-08-28 17:13, Joe Conway wrote:
> >> Attached is a patch for discussion, adding support for seccomp-bpf
> >> (nowadays generally just called seccomp) syscall filtering at
> >> configure-time using libseccomp.
Merlin Moncure schrieb am 28.08.2019 um 18:22:
My test case here is the query: pgsql-hackers
That search term is the first hit on DuckDuckGo:
https://duckduckgo.com/?q=pgsql-hackers+ExecHashJoinNewBatch&t=h_&ia=web
Searching for "postgres ExecHashJoinNewBatch" returns that ot position 4
https:
Hi,
On 2019-08-28 13:28:06 -0400, Joe Conway wrote:
> > To compute the initial set of allowed system calls, you need to have
> > fantastic test coverage. What you don't want is some rarely used error
> > recovery path to cause a system crash. I wouldn't trust our current
> > coverage for this.
Hi,
On 2019-08-28 11:13:27 -0400, Joe Conway wrote:
> Recent security best-practices recommend, and certain highly
> security-conscious organizations are beginning to require, that SECCOMP
> be used to the extent possible. The major web browsers, container
> runtime engines, and systemd are all ex
Hi,
On 2019-08-28 10:26:35 -0700, Andres Freund wrote:
> On August 28, 2019 9:22:44 AM PDT, Merlin Moncure wrote:
> >Hackers,
> >[apologies if this is the incorrect list or is already discussed
> >material]
>
> Probably should be on the -www list. Redirecting. Please trim in future
> replies.
>
Peter Eisentraut writes:
> On 2019-08-28 17:13, Joe Conway wrote:
>> Attached is a patch for discussion, adding support for seccomp-bpf
>> (nowadays generally just called seccomp) syscall filtering at
>> configure-time using libseccomp. I would like to get this in shape to be
>> committed by the e
On 8/28/19 12:47 PM, David Fetter wrote:
> On Wed, Aug 28, 2019 at 11:13:27AM -0400, Joe Conway wrote:
>> SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall
>> filtering mechanism which allows reduction of the kernel attack surface
>> by preventing (or at least audit logging) norma
On 8/28/19 1:03 PM, Peter Eisentraut wrote:
> On 2019-08-28 17:13, Joe Conway wrote:
>> * systemd does not implement seccomp filters by default. Packagers may
>> decide to do so, but there is no guarantee. Adding them post install
>> potentially requires cooperation by groups outside control of
Hi,
On August 28, 2019 9:22:44 AM PDT, Merlin Moncure wrote:
>Hackers,
>[apologies if this is the incorrect list or is already discussed
>material]
Probably should be on the -www list. Redirecting. Please trim in future replies.
>I've noticed that mailing list discussions in -hackers and other
Hi Tomas,
Interesting. Any idea where does the extra overhead in this particular
case come from? It's hard to deduce that from the single flame graph,
when I don't have anything to compare it with (i.e. the flame graph
for
the "normal" case).
I guess that bottleneck is in disk operations. You
On 2019-08-28 17:13, Joe Conway wrote:
> * systemd does not implement seccomp filters by default. Packagers may
> decide to do so, but there is no guarantee. Adding them post install
> potentially requires cooperation by groups outside control of
> the database admins.
Well, if we are intere
On Tue, Aug 27, 2019 at 10:33 PM Robert Haas wrote:
> While reviewing a proposed patch to basebackup.c this morning, I found
> myself a bit underwhelmed by the quality of the code and comments in
> basebackup.c's sendFile(). I believe it's already been pointed out
> that the the retry logic here
On Wed, Aug 28, 2019 at 11:13:27AM -0400, Joe Conway wrote:
> SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall
> filtering mechanism which allows reduction of the kernel attack surface
> by preventing (or at least audit logging) normally unused syscalls.
>
> Quoting from this li
On 2019-08-26 20:08, Laurenz Albe wrote:
> test=> CREATE OR REPLACE PROCEDURE testproc() LANGUAGE plpgsql AS
>$$BEGIN PERFORM 42; COMMIT; PERFORM 'x'; END;$$;
> CREATE PROCEDURE
> test=> CALL testproc();
> CALL
> test=> BEGIN;
> BEGIN
> test=> CALL testproc();
> ERROR: invalid transaction
On 2019-08-22 11:46, movead...@highgo.ca wrote:
> *1. src/include/utils/float.h:140*
>
> Analyze:
> This is an error report line when converting a big float8 value
> which a float4 can not storage to float4.
>
> Test case:
> Add a test case as below in file float4.sql:
> select float4(1234567890
Hackers,
[apologies if this is the incorrect list or is already discussed material]
I've noticed that mailing list discussions in -hackers and other
mailing lists appear to not be indexed by google -- at all. We are
also not being tracked by any mailing list aggregators -- in contrast
to a decade
Alexander Kukushkin writes:
> On Wed, 28 Aug 2019 at 04:51, Michael Paquier wrote:
>> note that your patch had a warning as "result" is not needed in
>> run_simple_command().
> Ohh, sorry about that. I compiled the whole source tree and the
> warning was buried down among other output :(
"make
I wrote:
> After a brief review of node->psql calls in the TAP tests, I'm
> of the opinion that what we should do is revert fb57f40 and instead
> change PostgresNode::psql so that on_error_die defaults to 1, then
> fix the *very* small number of callers that need it to be zero.
> Otherwise we're ju
> On Mon, Aug 5, 2019 at 10:38 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Of course we can modify it to read a whole page and leave visibility check
> for the code after `index_getnext_tid` (although in case if we know that all
> tuples on this page are visilbe I guess it's not strictly ne
SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall
filtering mechanism which allows reduction of the kernel attack surface
by preventing (or at least audit logging) normally unused syscalls.
Quoting from this link:
https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt
It was apparently entirely undocumented that the tablespace size
estimates sent by the base backup protocol are in kilobytes. Here is a
patch to document that. Also, a related clarification in the
pg_basebackup.c source code: It was not clear without analyzing the
whole stack that "totalsize" is
On 2019-Aug-26, Tom Lane wrote:
> I wrote:
> > I propose the attached. I'm inclined to think that the risk/benefit
> > of back-patching this is not very good, so I just want to stick it in
> > HEAD, unless somebody can explain why dead_end children are likely to
> > crash in the field.
>
> Pushe
Michael Paquier writes:
> This is a follow-up of the discussion which happened here after Tom
> has committed fb57f40:
> https://www.postgresql.org/message-id/20190828012439.ga1...@paquier.xyz
> I have reviewed the TAP tests, and we have much more spots where it
> is better to use PostgresNode::sa
I'm pretty new to this, and I find it hard trying to make some sense from
src code.
I'm trying to understand, logical decoding.
In `HEAP2` RMGR,
what does HEAP2_NEW_CID operation do?
can somebody give an example, when this type of record is written to wal
files.
When logical decoding decodes th
Hello devs,
The attached patch improves psql code coverage by adding a specific TAP
test. The 1709 tests take 4 seconds CPU (6.3 elapsed time) on my laptop.
The infrastructure is updated to require perl module "Expect", allowing to
test interactive features such as tab completion and prompt
Heikki Linnakangas writes:
> I bumped into a little bug in BRIN, while hacking on something
> unrelated. This causes a segfault, or an assertion failure if assertions
> are enabled:
Good catch.
> Fix attached.
Hm, I don't particularly care for directly comparing Datum values
like that. We do
> Please add that to commitfest.
Done: https://commitfest.postgresql.org/24/2261/
regards, Sergei
On Wed, Aug 28, 2019 at 5:38 PM Sergei Kornilov wrote:
> Hello
> We already have function pg_get_userbyid(oid) with lookup in pg_authid
> catalog. My collegue ask me can we add similar function
> pg_get_databasebyid(oid) with lookup in pg_databases.
> It is simple function to get a database name
Hello
We already have function pg_get_userbyid(oid) with lookup in pg_authid catalog.
My collegue ask me can we add similar function pg_get_databasebyid(oid) with
lookup in pg_databases.
It is simple function to get a database name by oid and fallback to 'unknown
(OID=n)' if missing.
The propos
On Fri, Aug 16, 2019 at 10:25 PM Etsuro Fujita wrote:
> It seems that I performed the above tests on an assertion-enabled
> build. :( So I executed the tests one more time. Here are the
> results.
>
> * 2-way self-join of pt: explain analyze select * from pt t0, pt t1
> where t0.a = t1.a;
> -
Hello,
I hear that not recommended to set pg_resetwal with --wal-segsize for wal
increasing. Are any more detailed information exists about it? What an
effects could be? Does it possible change it due full offline?
Regards, Paul
On Wed, Aug 28, 2019 at 2:43 AM Moon, Insung
wrote:
> So what about modifying the XLogWrite function only to write the size
> that should record?
> Can this idea benefit from WAL writing performance?
> If it's OK to improve, I want to do modification.
> How do you think of it?
>
I have performed
Thank you for your fix.
> This assumes that the merge function returns a newly-palloc'd value.
> That's a shaky assumption; if one of the arguments is an empty range,
> range_merge() returns the other argument, rather than a newly
> constructed value. And surely we can't assume assume that for
> u
Hi,
I have a join query with is not distinct from criteria (select *
from table1 join table2 on a is not distinct from b). on examining, it was
the nested loop join that makes the query slow. For join with ' is not
distinct from ' qual can't the planner choose hash-join
Hi,
On Tue, Aug 27, 2019 at 4:57 PM Richard Guo wrote:
> Check the query below as a more illustrative example:
>
> create table p (k int, val int) partition by range(k);
> create table p_1 partition of p for values from (1) to (10);
> create table p_2 partition of p for values from (10) to (100);
Hi,
Thank you, Michael, for committing it!
On Wed, 28 Aug 2019 at 04:51, Michael Paquier wrote:
> note that your patch had a warning as "result" is not needed in
> run_simple_command().
Ohh, sorry about that. I compiled the whole source tree and the
warning was buried down among other output :(
On 23/08/2019 11:44, Masahiko Sawada wrote:
On Fri, Aug 23, 2019 at 7:05 AM Ashwin Agrawal wrote:
On Thu, Aug 22, 2019 at 1:14 AM Heikki Linnakangas wrote:
The patch also includes a little unit test module to test this without
creating a 16 TB table. A whole new test module seems a bit like
Thank you Fujita San for the enhancement, will have a look.
Regards,
Amul
On Wed, Aug 28, 2019 at 3:52 PM Etsuro Fujita
wrote:
> On Fri, Aug 16, 2019 at 10:25 PM Etsuro Fujita
> wrote:
> > It seems that I performed the above tests on an assertion-enabled
> > build. :( So I executed the tests
Hello
Updated patch attached. (also I merged into one file)
> +
> + WAL receiver will be restarted after primary_slot_name
> + was changed.
>
> The sentence sounds strange. Here is a suggestion:
> The WAL receiver is restarted after an update of primary_slot_name (or
> primary_conninf
I bumped into a little bug in BRIN, while hacking on something
unrelated. This causes a segfault, or an assertion failure if assertions
are enabled:
CREATE TABLE brintest (n numrange);
CREATE INDEX brinidx ON brintest USING brin (n);
INSERT INTO brintest VALUES ('empty');
INSERT INTO brintest
On Wed, Aug 28, 2019 at 3:05 AM Tom Lane wrote:
> I'd vote for back-patching to 10. Even if there is in fact no deadlock
> hazard, you've clearly demonstrated a significant performance hit that
> we're taking for basically no reason.
Done.
The second symptom reported in my first email looked li
On Wed, Aug 28, 2019 at 7:03 AM Michael Paquier wrote:
>
> On Thu, Jul 11, 2019 at 11:14:20PM +0200, Julien Rouhaud wrote:
> > I didn't want to spend too much time enjoying bison and adding new
> > unreserved keywords, so for now I just implemented this syntax to
> > start a discussion for this fe
> On Wed, Aug 28, 2019 at 7:37 AM Fabien COELHO wrote:
>
> > While doing benchmarking using different tools, including pgbench, I found
> > it
> > useful as a temporary hack to add copy freeze and maintenance_work_mem
> > options
> > (the last one not as an env variable, just as a set before, al
Hi, Moon-san.
At Wed, 28 Aug 2019 15:43:02 +0900, "Moon, Insung"
wrote in
> Dear Hackers.
>
> Currently, the XLogWrite function is written in 8k(or 16kb) units
> regardless of the size of the new record.
> For example, even if a new record is only 300 bytes, pg_pwrite is
> called to write dat
Michaël,
I have taken the liberty to optimize the existing int64 function by removing
spurious tests.
Which are?
- *ptr && WHATEVER(*ptr)
*ptr is redundant, WHATEVER yields false on '\0', and it costs on each
char but at the end. It might be debatable in some places, e.g. it is
likel
On Wed, Aug 28, 2019 at 08:51:29AM +0200, Fabien COELHO wrote:
> Here is an updated patch for the u?int64 conversion functions.
Thanks!
> I have taken the liberty to optimize the existing int64 function by removing
> spurious tests.
Which are?
> I have not created uint64 specific inlined overfl
77 matches
Mail list logo
