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
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
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
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
>>
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
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
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.
>
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
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.
>
>
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.
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
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
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
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
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 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:
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
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.
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
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
On 08/08/2018 12:20 AM, Andres Freund wrote:
Hi,
I noticed
if (HeapTupleHeaderGetNatts(tuple.t_data) <
RelationGetDescr(erm->relation)->natts)
{
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
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
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
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
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 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
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
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
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;
> $$;
> #
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
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
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
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
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
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?
>
>
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
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
>
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 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
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
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
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
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
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
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,
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
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
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
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.
> 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
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
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
>>
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
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 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.
>
>
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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 Mon, Aug 6, 2018 at 2:40 AM, Michael Paquier wrote:
> In the case of REINDEX, we *allow* shared catalogs to be reindexed.
> Hence, if a user is a database owner, he would also be able to reindex
> critical indexes on shared catalogs, where blocking authentication is
> possible just with
On Mon, Aug 6, 2018 at 8:52 AM, Craig Ringer wrote:
> Currently postgres_fdw cannot be used with 'cert' authentication, i.e.
> client-certificate validation and cert cn => postgres username mapping. You
> also can't use things like Kerberos, SSPI, etc with a superuser-created FDW
> and username
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 such
onerous qualification, but I don't have a good idea.
> a. SQL
On 07/08/18 17:34, Stephen Frost wrote:
* Michael Paquier (mich...@paquier.xyz) wrote:
On Tue, Aug 07, 2018 at 02:32:27PM +0530, Robert Haas wrote:
On Sun, Aug 5, 2018 at 4:30 PM, Heikki Linnakangas wrote:
Well, it'd be useless for users, there is no reason to switch off channel
binding if
75 matches
Mail list logo
