On Wed, Aug 08, 2018 at 12:00:45PM +0530, Robert Haas wrote:
> On Sun, Aug 5, 2018 at 1:34 PM, Noah Misch wrote:
> > If hackers and non-core extension authors are to write such code, let's make
> > it easier to check the work.
>
> +1. Better still would be to invent a way to remove the need for
On 07-08-2018 19:21, Fabien COELHO wrote:
Hello Marina,
Hello, Fabien!
v10-0001-Pgbench-errors-use-the-RandomState-structure-for.patch
- a patch for the RandomState structure (this is used to reset a
client's random seed during the repeating of transactions after
serialization/deadlock fail
Hello. Please find the attached.
At Fri, 3 Aug 2018 11:48:38 +0530, Ashutosh Bapat
wrote in
> The purpose of non-Var node is to avoid adding the attribute to
> relation descriptor. Idea is to create a new node, which will act as a
> place holder for table oid or row id (whatever) to be fetched
On Tue, Jul 31, 2018 at 01:39:07PM +0900, Kyotaro HORIGUCHI wrote:
> "int backendID" is left in autovacuum.c as an unused variable.
Fixed.
> "Even if this is *not* an atomic operation" ?
Yeah, I am reworking this comment a bit more to map with the other
PGPROC fields.
> + * Mark the proc entry
Hi,
On 2018-07-30 16:59:16 +0900, Michael Paquier wrote:
> + /*
> + * Mark MyProc as owning this namespace which other processes can use to
> + * decide if a temporary namespace is in use or not. Even if this is an
> + * atomic operation, this can be safely done lock-less as no
On 8 August 2018 at 17:28, Amit Langote wrote:
> Attached is a patch which modifies the if test to compare relids instead
> of RelOptInfo pointers.
Thanks for investigating and writing a patch. I agree with the fix.
It's probably worth writing a test that performs run-time pruning from
an inheri
Re: Tom Lane 2018-08-02
> Fix run-time partition pruning for appends with multiple source rels.
>
> The previous coding here supposed that if run-time partitioning applied to
> a particular Append/MergeAppend plan, then all child plans of that node
> must be members of a single partitioning hiera
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Patch does not apply cleanly on the master branch, anyways I managed
On Tue, Aug 7, 2018 at 7:32 PM, Amit Langote
wrote:
> Attached updated patch adds isleaf to pg_partition_children's output.
Hi Amit,
Hmm, I wonder where this garbage is coming from:
6201 select *, pg_relation_size(relid) as size from
pg_partition_children('ptif_test');
6202 ! ERROR: invalid
On Wed, Aug 8, 2018 at 11:21 PM, Thomas Munro
wrote:
> On Tue, Aug 7, 2018 at 7:32 PM, Amit Langote
> wrote:
>> Attached updated patch adds isleaf to pg_partition_children's output.
>
> Hmm, I wonder where this garbage is coming from:
partition.c:437:3: error: array index 3 is past the end of th
On 08/03/2018 02:39 PM, Tomas Vondra wrote:
On 08/03/2018 06:40 AM, Kyotaro HORIGUCHI wrote:
...
I'm not confident on replacing double to float8 partially in gist
code. After the 0002 patch applied, I see most of problematic
usage of double or bare arithmetic on dimentional values in
gistpro
On Wed, Aug 8, 2018 at 01:55:53PM +0300, KES wrote:
> I do not know many internals and maybe wrong.
>
> But from my point of view with my current knowledge.
> If such exclusion constraint would be marked as UNIQUE we can use it for FK
> while implementing temporal/bi-temporal tables.
>
> And t
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 07/08/18 17:34, Stephen Frost wrote:
> >Now- if we thought that maybe there was some connection pooling solution
> >that could be made to work with SSL+SCRAM if channel binding is turned
> >off, then that's a use-case that maybe we shou
Bruce Momjian writes:
> On Wed, Aug 8, 2018 at 01:55:53PM +0300, KES wrote:
>> If such exclusion constraint would be marked as UNIQUE we can use it for FK
>> while implementing temporal/bi-temporal tables.
> Yes, it would work, but doing that only for equality would be surprising
> to many peop
Robert Haas writes:
> +1. Better still would be to invent a way to remove the need for such
> onerous qualification, but I don't have a good idea.
Yeah.
> So I guess what we need is a UI that lets you say either:
> - Don't tell me about anything, or
> - Tell me about all unqualified references
Christoph Berg writes:
> Since this commit added a new node type, all following node types got
> renumbered. This means all extension modules using the information
> compiled against 11beta2 need to be recompiled against 11beta3.
That's standard procedure for beta releases. We don't normally sta
On 8/7/18 11:42 AM, Stephen Frost wrote:
>
>>> CRC's are per WAL record, and possibly some WAL records might not be ok
>>> to replay, or at least we need to make sure that we replay the right set
>>> of WAL in the right order even when there are partial WAL files being
>>> given to PG (that aren't
On 8/7/18 12:05 PM, Stephen Frost wrote:
>>
>> All I'm saying is that (assuming my understanding of RestoreArchivedFile is
>> correct) we can't just do that in the current restore_command. We do need a
>> way to ask the archive for some metadata/checksums, and restore_command is
>> too late.
>
> Y
On 8 August 2018 at 09:58, Tom Lane wrote:
When the security team was discussing this issue before, we speculated
> about ideas like inventing a function trust mechanism, so that attacks
> based on search path manipulations would fail even if they managed to
> capture an operator reference. I'd
On 2018-Aug-08, Michael Paquier wrote:
> As this introduces a new
> field to PGPROC, so back-patching the thing as-is would cause an ABI
> breakage. Are folks here fine with the new field added to the bottom of
> the structure for the backpatched versions, including v11? I have found
> about com
Isaac Morland writes:
> On 8 August 2018 at 09:58, Tom Lane wrote:
>> When the security team was discussing this issue before, we speculated
>> about ideas like inventing a function trust mechanism, so that attacks
>> based on search path manipulations would fail even if they managed to
>> captur
Alvaro Herrera writes:
> Unnoticed ABI breaks make my hair stand on end.
Yeah.
> I'm unsure about pg11 -- is it a backbranch already or not? Since we've
> released beta3 already, ISTM we should consider it so.
No. See
https://www.postgresql.org/message-id/12725.1533737052%40sss.pgh.pa.us
At
> On Aug 8, 2018, at 7:47 AM, Tom Lane wrote:
>
> Isaac Morland writes:
>> On 8 August 2018 at 09:58, Tom Lane wrote:
>>> When the security team was discussing this issue before, we speculated
>>> about ideas like inventing a function trust mechanism, so that attacks
>>> based on search path
I do not know many internals and maybe wrong.
But from my point of view with my current knowledge.
If such exclusion constraint would be marked as UNIQUE we can use it for FK
while implementing temporal/bi-temporal tables.
And this will be simplify relationing while implementing them.
07.08.20
On 2018-Aug-08, KES wrote:
> I do not know many internals and maybe wrong.
>
> But from my point of view with my current knowledge.
> If such exclusion constraint would be marked as UNIQUE we can use it for FK
> while implementing temporal/bi-temporal tables.
>
> And this will be simplify rela
Mark Dilger writes:
> On Aug 8, 2018, at 7:47 AM, Tom Lane wrote:
>> The advantage of a function trust mechanism is that it'd provide
>> security against calling functions you didn't intend to without
>> any visible changes in normal application behavior. The security
>> team gave up on that app
Hi,
On 8/6/18, 11:59 AM, "Michael Paquier" wrote:
> Attached is a patch I have been working on which refactors the code of
> TRUNCATE in such a way that we check for privileges before trying to
> acquire a lock, without any user-facing impact (I have reworked a couple
> of comments compared to th
On 08/08/2018 04:08 PM, David Steele wrote:
On 8/7/18 12:05 PM, Stephen Frost wrote:
All I'm saying is that (assuming my understanding of RestoreArchivedFile is
correct) we can't just do that in the current restore_command. We do need a
way to ask the archive for some metadata/checksums, and
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On 08/08/2018 04:08 PM, David Steele wrote:
> >On 8/7/18 12:05 PM, Stephen Frost wrote:
> >>>All I'm saying is that (assuming my understanding of RestoreArchivedFile is
> >>>correct) we can't just do that in the current restore_comm
David Rowley writes:
> On 8 August 2018 at 17:28, Amit Langote wrote:
>> Attached is a patch which modifies the if test to compare relids instead
>> of RelOptInfo pointers.
> Thanks for investigating and writing a patch. I agree with the fix.
I changed this to compare the relid sets not just re
On Wed, Aug 1, 2018 at 05:33:39PM +0200, Marco van Eck wrote:
> After explaining the patch to a college we identified potentially execution of
> another user when it is defined in as a command parameter. To protect agains
> it
> I've removed the possibility to pass the 'passcommand'. With the res
On 8/8/18 11:45 AM, Stephen Frost wrote:
>
> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>> On 08/08/2018 04:08 PM, David Steele wrote:
>>> On 8/7/18 12:05 PM, Stephen Frost wrote:
> All I'm saying is that (assuming my understanding of RestoreArchivedFile
> is
> correct) we c
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> I can see cases where it *might* be worth it, but several backup tools
> support prefetch and/or parallelism which should be able to keep
> Postgres fed with WAL unless there is very high latency to the repo.
> I'm not sure the small perform
On 20/07/18 18:03, Andres Freund wrote:
On 2018-07-20 11:53:32 +0300, Heikki Linnakangas wrote:
But I think we have consensus on replacing the exit(2) calls
with _exit(2). If we do just that, it would be better than the status quo,
even if it doesn't completely fix the problem. This would preven
On 2018-Jun-25, Jeff Janes wrote:
> Is there a summary of the results of the previous rounds? I didn't see any
> announcements of them. I've been trying to find some crash recovery
> torture testing to do for v11 release, but can't find features to focus on
> which might be scariest from a WAL p
On Tue, Jul 24, 2018 at 12:25:31PM +0200, Marco van Eck wrote:
> Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W)
> around is making my auditors unhappy, and forcing me to enter the password
> over and over again. With a simple test it seems the password entered by
> the user
On Wed, Aug 08, 2018 at 10:50:34AM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> I'm unsure about pg11 -- is it a backbranch already or not? Since we've
>> released beta3 already, ISTM we should consider it so.
>
> No. See
> https://www.postgresql.org/message-id/12725.1533737052%40sss.pgh.
On Wed, Aug 08, 2018 at 12:25:03PM +0530, Robert Haas wrote:
> In my opinion, the behavior change is probably OK, but not
> back-patchable.
Thanks. I see three votes in favor of not back-patching (you,
Horiguchi-san and Nathan), so that won't happen.
> I think that the documentation could be phr
On Wed, Aug 08, 2018 at 07:19:34PM +0300, Heikki Linnakangas wrote:
> On 20/07/18 18:03, Andres Freund wrote:
> >It's much less the exit() that's unsafe, than the callbacks themselves,
> >right? Perhaps just restate that we wouldn't want to trigger atexit
> >processing due to signal safety?
>
> W
This is sort of a counter-proposal to Noah's discussion of search path
security checking in <20180805080441.gh1688...@rfd.leadboat.com>.
(There's no technical reason we couldn't do both things, but I think
this'd be more useful to most people.)
Some back story here is that the PG security team has
Hello,
We found the exact same issue on a production database at TripAdvisor. We have
no new information to add for debugging. Bumping this to up the priority on a
patch version release getting out.
Thanks,
-Kyle Samson
On Wed, Aug 8, 2018 at 10:23 AM, Kyle Samson wrote:
> We found the exact same issue on a production database at TripAdvisor. We
> have no new information to add for debugging. Bumping this to up the priority
> on a patch version release getting out.
There is a batch of point releases that were
On 2018-Aug-05, Michael Paquier wrote:
> Attached is a set of patches I proposed on the original thread, which
> skips shared catalogs if the user running REINDEX is not an owner of
> it. This is a behavior change, and as I have a hard time believing that
> anybody can take advantage of the curre
Alvaro Herrera writes:
> On 2018-Aug-05, Michael Paquier wrote:
>> Attached is a set of patches I proposed on the original thread, which
>> skips shared catalogs if the user running REINDEX is not an owner of
>> it. This is a behavior change, and as I have a hard time believing that
>> anybody ca
On 06/08/2018 20:32, Jeremy Evans wrote:
> The current code's hint is misleading for procedures:
>
> CREATE OR REPLACE PROCEDURE a(in int)
> LANGUAGE SQL
> AS $$
> SELECT NULL;
> $$;
> # CREATE PROCEDURE
>
> CREATE OR REPLACE PROCEDURE a(inout int)
> LANGUAGE SQL
> AS $$
> SELECT NULL;
> $$;
> #
On 6 August 2018 at 16:34, Stephen Frost wrote:
> Greetings,
>
> * Cynthia Shang (cynthia.sh...@crunchydata.com) wrote:
> > I was able to apply the patch (after resolving a merge conflict which
> was expected given an update in master). All looks good.
>
> If there's a merge conflict against mast
Hi Andres,
(Not my intention to miss your message, I have just noticed it.)
On Wed, Aug 08, 2018 at 01:41:27AM -0700, Andres Freund wrote:
> I can't parse this. "Even if this is an atomic operation, this can be
> safely done lock-less" - that seems like a contradictory sentence. Is
> there a "not
On Wed, Aug 08, 2018 at 02:39:00PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> I agree that it would be good to have it fixed in released versions, but
>> I also agree that such a change could cause trouble in production for
>> some. Is the "no backpatch" idea that you will push this to bo
Peter Eisentraut writes:
> Yes, the hint should be changed. But I also think the error message
> should be changed to be more appropriate to the procedure situation
> (where is the return type?). Attached patch does both. Unlike your
> patch, I kept the "DROP FUNCTION" message for the function
On 20/06/2018 21:42, Tomas Vondra wrote:
> So I think we should fix and serialize/restore the OID array, just like
> we do for tuples, snapshots etc. See the attached fix.
Yes please.
> Another thing we should probably reconsider is where the relids is
> allocated - the pointer remains valid be
I found some unused and some redundant code in ri_triggers.c that was
left around by some previous changes that aimed to optimize away certain
trigger invocations. See attached patches.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
On 8/8/18, 2:16 PM, "Michael Paquier" wrote:
> By no-backpatch, I only implied patching v12, but that would not be a
> huge amount of efforts to get that into v11, so I can do that as well.
> Any objections to doing that?
+1 for back-patching to v11.
Nathan
On 08/08/2018 09:19 PM, Peter Eisentraut wrote:
On 20/06/2018 21:42, Tomas Vondra wrote:
So I think we should fix and serialize/restore the OID array, just like
we do for tuples, snapshots etc. See the attached fix.
Yes please.
OK, will do.
Another thing we should probably reconsider i
On 08/08/2018 12:20 AM, Andres Freund wrote:
Hi,
I noticed
if (HeapTupleHeaderGetNatts(tuple.t_data) <
RelationGetDescr(erm->relation)->natts)
{
copy
On Wed, Aug 08, 2018 at 11:47:34AM -0500, Nico Williams wrote:
> Yes. Would that snprintf() and vsnprintf() were async-signal-safe --
> they can be, and some implementations probably are, but they aren't
> required to be, then making ereport() safe would be easier.
So, I took a look at glibc's im
I spent some more time poking at Jaime's example. I can reduce the
problem query to this and still get the Assert crash:
select random()
from radicado tablesample bernoulli (9.7)
where radi_texto = radi_inst_actu
limit 33;
None of the elements of this query can be removed without causing the
Ass
Another way to look at it:
Alvaro = 6*2 + 4*4 = 28
Robert = 4*5 + 2 = 22
Andres = 5 + 3 + 1 = 9
Peter = 5
Andrew = 4
Teodor = 3
Simon = 3
A round of applause for our winner!
--
Fabien.
On Tue, Aug 7, 2018 at 12:19 AM, Andrey Lepikhov
wrote:
> I wrote a background worker (hcleaner) to demonstrate application of Retail
> IndexTuple deletion (see patch at attachment).
> Like Autovacuum it utilizes concept of one launcher and many workers. But
> one worker correspond to one database
On Tue, Aug 7, 2018 at 7:00 PM, Peter Geoghegan wrote:
>
> I wonder if it would be a better idea to enable Valgrind's memcheck to
> mark buffers as read-only or read-write. We've considered doing
> something like that for years, but for whatever reason nobody followed
> through.
Basic question: h
On August 9, 2018 1:33:17 AM GMT+05:30, Andrew Dunstan
wrote:
>
>
>On 08/08/2018 12:20 AM, Andres Freund wrote:
>> Hi,
>>
>> I noticed
>> if (HeapTupleHeaderGetNatts(tuple.t_data) <
>> RelationGetDescr(erm->relation)->natts)
>>
On Wed, Jul 25, 2018 at 4:07 PM, Andres Freund wrote:
>> HEAD/REL_11_STABLE apparently solely being affected points elsewhere,
>> but I don't immediatley know where.
>
> Hm, there was:
> http://archives.postgresql.org/message-id/20180628150209.n2qch5jtn3vt2xaa%40alap3.anarazel.de
>
>
> I don't imm
Peter Geoghegan writes:
> On Wed, Jul 25, 2018 at 4:07 PM, Andres Freund wrote:
>> I don't immediately see it being responsible, but I wonder if there's a
>> chance it actually is: Note that it happens in a parallel group that
>> includes vacuum.sql, which does a VACUUM FULL pg_class - but I stil
On August 9, 2018 12:41:17 AM GMT+05:30, Michael Paquier
wrote:
>Hi Andres,
>
>(Not my intention to miss your message, I have just noticed it.)
>
>On Wed, Aug 08, 2018 at 01:41:27AM -0700, Andres Freund wrote:
>> I can't parse this. "Even if this is an atomic operation, this can be
>> safely d
I wrote:
> Now that seems to me to be a rather weird plan: why doesn't it prefer
> to flatten everything into one parallel append? Indeed, if you take
> out any of the remaining query parts such as the LIMIT, that's what
> it does. I think that its willingness to do this is actually kind
> of a b
09.08.2018 05:19, Peter Geoghegan пишет:
On Tue, Aug 7, 2018 at 12:19 AM, Andrey Lepikhov
wrote:
I wrote a background worker (hcleaner) to demonstrate application of Retail
IndexTuple deletion (see patch at attachment).
Like Autovacuum it utilizes concept of one launcher and many workers. But
On 2018/08/09 0:48, Tom Lane wrote:
> David Rowley writes:
>> On 8 August 2018 at 17:28, Amit Langote
>> wrote:
>>> Attached is a patch which modifies the if test to compare relids instead
>>> of RelOptInfo pointers.
>
>> Thanks for investigating and writing a patch. I agree with the fix.
>
>
Amit Langote writes:
> One reason why we should adapt such a test case is that, in the future, we
> may arrange for make_partitionedrel_pruneinfo(), whose code we just fixed,
> to not be called if we know that run-time pruning is not needed. It seems
> that that's true for the test added by the c
At Sat, 4 Aug 2018 05:58:52 +0900, Michael Paquier wrote
in <20180803205852.gb20...@paquier.xyz>
> On Fri, Aug 03, 2018 at 04:37:05PM -0400, Alvaro Herrera wrote:
> > On 2018-Aug-03, Kyotaro HORIGUCHI wrote:
> >> That said, I don't object to reduce the columns. Please find the
> >> attached.
> >
Thanks Thomas for notifying.
On 2018/08/08 20:47, Thomas Munro wrote:
> On Wed, Aug 8, 2018 at 11:21 PM, Thomas Munro
> wrote:
>> On Tue, Aug 7, 2018 at 7:32 PM, Amit Langote
>> wrote:
>>> Attached updated patch adds isleaf to pg_partition_children's output.
>>
>> Hmm, I wonder where this garbag
Hello.
At Fri, 3 Aug 2018 15:42:22 -0700, Peter Geoghegan wrote in
> On Fri, Aug 3, 2018 at 12:34 AM, Kyotaro HORIGUCHI
> wrote:
> >> I reread through the thread and IUCC, drop_index() is sending
> >> inval on the owing relation and invalidation happens (that is,
> >
> > I finally understand t
On 2018/08/09 13:00, Tom Lane wrote:
> Amit Langote writes:
>> One reason why we should adapt such a test case is that, in the future, we
>> may arrange for make_partitionedrel_pruneinfo(), whose code we just fixed,
>> to not be called if we know that run-time pruning is not needed. It seems
>> t
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 that as a problem
>> for parallel CREATE INDEX [2]. If that was
Peter Geoghegan writes:
> On Wed, Aug 8, 2018 at 7:40 PM, Tom Lane wrote:
>> Oooh ... but pg_class wouldn't be big enough to get a parallel
>> index rebuild during that test, would it?
> Typically not, but I don't think that we can rule it out right away.
Hmmm ... maybe we should temporarily st
On Wed, Aug 8, 2018 at 10:03 PM, Tom Lane wrote:
>> Typically not, but I don't think that we can rule it out right away.
>
> Hmmm ... maybe we should temporarily stick in an elog(LOG) showing whether
> a parallel build happened or not, so that we can check the buildfarm logs
> next time we see tha
74 matches
Mail list logo
