On Sun, Aug 2, 2015 at 8:06 AM, Kouhei Kaigai wrote:
>
> Amit,
>
> Let me ask three more detailed questions.
>
> Why Funnel has a valid qual of the subplan?
> The 2nd argument of make_funnel() is qualifier of the subplan
> (PartialSeqScan) then it is initialized at ExecInitFunnel,
> but never exec
On Tue, Aug 4, 2015 at 3:35 PM, Simon Riggs wrote:
> Please provide the link to the discussion of this. I don't see a problem
> here right now that can't be solved by saying
Thread:
http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com
Particular
On 4 August 2015 at 05:56, Michael Paquier
wrote:
> Hi all,
>
> As mentioned in the thread related to lowering locks of autovacuum
> reloptions in ALTER TABLE SET
> (
> http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com
> ),
> I have noticed th
On Tue, Aug 4, 2015 at 3:27 PM, Beena Emerson wrote:
> Michael Paquier wrote:
>> And this is the case of any format as well. String format validation
>> for a GUC occurs when server is reloaded or restarted, one advantage
>> of JSON is that the parser validator is already here, so we don't need
>>
On Tue, Aug 4, 2015 at 2:43 PM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>
>> As mentioned in the thread related to lowering locks of autovacuum
>> reloptions in ALTER TABLE SET
>> (http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com),
>> I
Michael Paquier wrote:
> And this is the case of any format as well. String format validation
> for a GUC occurs when server is reloaded or restarted, one advantage
> of JSON is that the parser validator is already here, so we don't need
> to reinvent a new machinery for that.
IIUC correctly, we w
On Tue, Aug 4, 2015 at 2:57 PM, Masahiko Sawada wrote:
> On Thu, Jul 30, 2015 at 2:16 PM, Beena Emerson wrote:
>> Since there will not be many nesting and grouping, I still prefer new
>> language to JSON.
>> I understand one can easily, modify/add groups in JSON using in built
>> functions but I th
On Thu, Jul 30, 2015 at 2:16 PM, Beena Emerson wrote:
> Hello,
>
> Just looking at how the 2 differnt methods can be used to set the s_s_names
> value.
>
> 1. For a simple case where quorum is required for a single group the JSON
> could be:
>
> {
> "sync_standby_names":
> {
>
Michael Paquier wrote:
> As mentioned in the thread related to lowering locks of autovacuum
> reloptions in ALTER TABLE SET
> (http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com),
> I have noticed the following code in
> AlterTableGetLockLevel@t
On Jul 31, 2015 4:22 AM, "Jeremy Harris" wrote:
>
> On 30/07/15 02:05, Peter Geoghegan wrote:
> > Since heapification is now a big fraction of the total cost of a sort
> > sometimes, even where the heap invariant need not be maintained for
> > any length of time afterwards, it might be worth revis
On Tue, Aug 4, 2015 at 2:04 AM, Simon Riggs wrote:
> On 3 August 2015 at 17:36, Tom Lane wrote:
>>
>> Alvaro Herrera writes:
>> > Simon Riggs wrote:
>> >> * For emergency anti-wraparound VACUUMs we shouldn't scan indexes at
>> >> all,
>> >> since they aren't critical path activities at that poin
On Mon, Aug 3, 2015 at 5:35 PM, Christoph Berg wrote:
> Re: Michael Paquier 2015-07-28
>
>> On Tue, Jul 28, 2015 at 5:57 PM, Christoph Berg wrote:
>> > for something between 10% and 20% of the devel builds for
>> > apt.postgresql.org
>> > (which happen every 6h if there's a git change, so it h
For a GIN index with fastupdate turned on, both the user backends and
autoanalyze routine will clear out the pending list, pushing the entries
into the normal index structure and deleting the pages used by the pending
list. But those deleted pages will not get added to the freespace map
until a va
Hi all,
As mentioned in the thread related to lowering locks of autovacuum
reloptions in ALTER TABLE SET
(http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com),
I have noticed the following code in
AlterTableGetLockLevel@tablecmds.c:
During working on allowing the planner to perform GROUP BY before joining
I've noticed that cost_agg() completely ignores input_startup_cost
when aggstrategy == AGG_HASHED.
I can see at least 3 call to cost_agg() which pass aggstrategy as
AGG_HASHED that are also passing a possible non-zero startu
> >> Why does this cause a core dump? We could consider fixing whatever
> >> the problem is rather than capping the value.
As far as I experiment with my own evaluation environment using
PostgreSQL-9.4.4 on a x86_64 Linux, this problem can be fixed with the patch
attached.
I have confirmed that
On Mon, Aug 3, 2015 at 7:44 PM, Fujii Masao wrote:
>
>
> Thanks! Pushed.
>
Thanks to you as well for committing the patch.
> BTW, while reading the code related to tablespace_map, I found that
> CancelBackup() emits the WARNING message "online backup mode was not
canceled"
> when rename() fails.
On Mon, Aug 3, 2015 at 12:03 AM, 高增琦 wrote:
> sorry for asking this really old commit.
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7ab9b2f3b79177e501a1ef90ed004cc68788abaf
>
> I could not understand why "releases the lock on the buffer" is
> a problem since vacuum will lo
On Tue, Aug 4, 2015 at 9:12 AM, Fabrízio de Royes Mello
wrote:
> Are you sure we need to do all this changes just to check the highest
> locklevel based on the reloptions?
Well, by looking at the code that's what it looks as. That's a large
change not that straight-forward.
> Or I misunderstood
On 2015-08-03 PM 09:24, Ashutosh Bapat wrote:
> On Sat, Aug 1, 2015 at 12:18 AM, Robert Haas wrote:
>>
>> OK, sure. But let's make sure postgres_fdw gets a server-level option
>> to control this.
>>
>>
> For postgres_fdw it's a boolean server-level option 'twophase_compliant'
> (suggestions for n
On Mon, Aug 3, 2015 at 2:15 AM, Michael Paquier
wrote:
>
> On Sat, Aug 1, 2015 at 9:20 PM, Andres Freund wrote:
> > On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier wrote:
> >>> For instance, if you told me to choose between ShareLock and
> >>> ShareUpdateExclusiveLock I wouldn't know which
On Mon, Aug 3, 2015 at 3:07 PM, Stephen Frost wrote:
> Thoughts? Trying to keep it straight-forward and provide a simple
> solution for users to be able to address the issue, if they're worried
> about it. Perhaps this, plus an additional paragraph which goes into
> more detail about exactly wha
* Peter Geoghegan (p...@heroku.com) wrote:
> On Mon, Jun 1, 2015 at 12:29 AM, Peter Geoghegan wrote:
> > If you're using another well known MVCC database system that has RLS,
> > I imagine when this happens the attacker similarly waits on the
> > conflicting (privileged) xact to finish (in my exam
On Mon, Aug 3, 2015 at 1:36 PM, Robert Haas wrote:
> I don't think that's what Heikki is talking about. He can correct me
> if I'm wrong, but what I think he's saying is that we should try to
> exploit the fact that we've already determined which in-memory tuples
> can be part of the current run
On 8/3/15 12:04 PM, Simon Riggs wrote:
Yes, that's what I was thinking, I just didn't say actually it. I'd been
thinking about having VACUUM do just Phase 1 for some time, since its so
much faster to do that. Will code.
I'd like to see that exposed as an option as well. There are certain
situa
On Mon, Aug 3, 2015 at 3:33 PM, Peter Geoghegan wrote:
>> When it's time to drain the heap, in performsort, divide the array into two
>> arrays, based on the run number of each tuple, and then quicksort the arrays
>> separately. The first array becomes the in-memory tail of the current tape,
>> an
On Sat, Aug 1, 2015 at 9:56 AM, Andres Freund wrote:
> On 2015-07-31 13:31:54 -0400, Robert Haas wrote:
>> On Fri, Jul 31, 2015 at 7:21 AM, Jeremy Harris wrote:
>> > Heapification is O(n) already, whether siftup (existing) or down.
>>
>> That's not my impression, or what Wikipedia says. Source?
On Sat, Aug 1, 2015 at 9:49 AM, Jeremy Harris wrote:
> On 31/07/15 18:31, Robert Haas wrote:
>> On Fri, Jul 31, 2015 at 7:21 AM, Jeremy Harris wrote:
>>> Heapification is O(n) already, whether siftup (existing) or down.
>>
>> That's not my impression, or what Wikipedia says. Source?
>
> Measurem
On Fri, Jul 31, 2015 at 12:59 AM, Heikki Linnakangas wrote:
> Oh, ok, I was confused on how the heap works. You could still abstract this
> as "in-memory tails" of the tapes, but it's more complicated than I thought
> at first:
>
> When it's time to drain the heap, in performsort, divide the array
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 3 August 2015 at 16:09, Stephen Frost wrote:
> > * Stephen Frost (sfr...@snowman.net) wrote:
> >> Agreed. I'm happy to commit that change and back-patch it to 9.5,
> >> barring objections. Given that the only way to have restrictive
>
Piotr Stefaniak writes:
> How about this one?
> 1 ERROR: could not find RelOptInfo for given relids
That would be a bug, for sure ...
> It's triggered on 13bba02271dce865cd20b6f49224889c73fed4e7 by this query
> and the attached one:
... but I can't reproduce it on HEAD with either of thes
Nikolay Shaplov wrote:
> This patch adds several new functions, available from SQL queries. All these
> functions are based on heap_page_items, but accept slightly different
> arguments and has one additional column at the result set:
>
> heap_page_tuples - accepts relation name, and bulkno, an
On Mon, Aug 3, 2015 at 8:53 AM, Geoff Winkless wrote:
> If I create a copy of the table using
>
> CREATE mytab (LIKE brokentab INCLUDING ALL);
> INSERT INTO mytab SELECT * FROM brokentab;
Also, did you drop any columns from the original "brokentab" table
where the bug can be reproduced?
--
Pete
On Mon, Aug 3, 2015 at 8:53 AM, Geoff Winkless wrote:
> the new table does not exhibit the same problem (so I'm assuming it's not
> easily reproducible and giving you a creation script isn't going to help).
>
> VACUUM FULL on the table makes no difference.
>
> Is there anything you guys can sugges
On Mon, Aug 3, 2015 at 4:13 AM, Simon Riggs wrote:
> * For normal VACUUMs we should scan indexes only if (num_dead_tuples * 20) >
> (blocks to be scanned in any one index), which allows some index bloat but
> not much
I think this kind of heuristic is good, but I think we should expose a
setting
On Mon, Aug 3, 2015 at 11:52 AM, Alvaro Herrera
wrote:
> Simon Riggs wrote:
>> * For emergency anti-wraparound VACUUMs we shouldn't scan indexes at all,
>> since they aren't critical path activities at that point
>
> It is not possible to skip scanning indexes completely, unless no tuples
> are to
On Fri, Jul 31, 2015 at 8:09 PM, Josh Berkus wrote:
> On 07/31/2015 10:43 AM, Robert Haas wrote:
>> On Thu, Jul 30, 2015 at 9:17 PM, Josh Berkus wrote:
>>> In guc.c, the maximum for wal_buffers is INT_MAX. However, wal_buffers
>>> is actually measured in 8KB buffers, not in bytes. This means th
I happened to notice two declarations of functions for BRIN that
are not actually defined, and a comment that looked like it was
incompletely edited. Attached patch is a suggestion, but I leave
it to those working on the feature to commit, since there might be
a reason I'm missing for the declarat
On 3 August 2015 at 17:36, Tom Lane wrote:
> Alvaro Herrera writes:
> > Simon Riggs wrote:
> >> * For emergency anti-wraparound VACUUMs we shouldn't scan indexes at
> all,
> >> since they aren't critical path activities at that point
>
> > It is not possible to skip scanning indexes completely,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/03/2015 09:55 AM, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
>> On Sun, Aug 02, 2015 at 11:31:16PM -0400, Tom Lane wrote:
>>> That being the case, it would probably be a good idea to get
>>> them done before alpha2, as there m
Peter Geoghegan wrote:
> Couldn't we adopt
> AssertVariableIsOfType()/AssertVariableIsOfTypeMacro() to macros like
> READ_UINT_FIELD()?
>
> I'm surprised that this stuff was only ever used for logical decoding
> infrastructure so far.
The reason it's only used there is that Andres is the one who
Peter Geoghegan wrote:
> On Sun, Aug 2, 2015 at 3:07 PM, Peter Geoghegan wrote:
> > I'm surprised that this stuff was only ever used for logical decoding
> > infrastructure so far.
>
> On second thought, having tried it, one reason is that that breaks
> things that are considered legitimate for h
* Noah Misch (n...@leadboat.com) wrote:
> On Sun, Aug 02, 2015 at 11:31:16PM -0400, Tom Lane wrote:
> > That being the case, it would probably be a good idea to get them done
> > before alpha2, as there may not be a good opportunity afterwards.
>
> Freedom to bump catversion after alpha2 will be b
Alvaro Herrera writes:
> Simon Riggs wrote:
>> * For emergency anti-wraparound VACUUMs we shouldn't scan indexes at all,
>> since they aren't critical path activities at that point
> It is not possible to skip scanning indexes completely, unless no tuples
> are to be removed from the heap.
Right
On Mon, Jul 27, 2015 at 1:40 PM, Simon Riggs wrote:
> On 22 July 2015 at 17:11, Jeff Janes wrote:
>
>> On Wed, Jul 22, 2015 at 6:59 AM, Robert Haas
>> wrote:
>>
>>> On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes
>>> wrote:
>>> > Attached is a patch that implements the vm scan for truncation. It
On 3 August 2015 at 16:53, Geoff Winkless wrote:
> If I create a copy of the table using
>
> CREATE mytab (LIKE brokentab INCLUDING ALL);
>
> Of course I meant CREATE TABLE here... finger slippage :)
Qingqing Zhou wrote:
> On Thu, Jul 30, 2015 at 2:42 PM, Jim Nasby wrote:
> >
> > I think a better option would be shoving it into a backend tuplestore and
> > just leaving it there (maybe with a command to clear it for the paranoid).
> > That gives a relation you can query against, insert into ano
Hi
We've come across a weirdness with ON CONFLICT, where UPSERTing a smallint
value produces an error:
db=# INSERT INTO brokentab(id, k1,k2,k3,k4,k5,k6,k7, smallval) VALUES
(5,0,0,0,1,0,1,0, 0) ON CONFLICT (id, k1,k2,k3,k4,k5,k6,k7) DO UPDATE SET
smallval=EXCLUDED.smallval;
ERROR: attribute 29 h
Simon Riggs wrote:
> * For emergency anti-wraparound VACUUMs we shouldn't scan indexes at all,
> since they aren't critical path activities at that point
It is not possible to skip scanning indexes completely, unless no tuples
are to be removed from the heap. Otherwise, index tuples become
linge
On Mon, Aug 3, 2015 at 12:27 PM, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
1) Test and results are in attachments. Everything seems to work
as expected.
2) I dropped these notices. It was done only for debug purposes.
Updated patch is attached.
3)
On 3 August 2015 at 16:09, Stephen Frost wrote:
> Dean, all,
>
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Agreed. I'm happy to commit that change and back-patch it to 9.5,
>> barring objections. Given that the only way to have restrictive
>> policies currently is using hooks, I don't belie
Dean, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> Agreed. I'm happy to commit that change and back-patch it to 9.5,
> barring objections. Given that the only way to have restrictive
> policies currently is using hooks, I don't believe there's any
> documentation update required either; of
Hi,
track_commit_timestamp tracks COMMIT PREPARED as expected in standby server,
but not in master server. Is this intentional? It should track COMMIT PREPARED
even in master? Otherwise, we cannot use commit_timestamp feature to check
the replication lag properly while we use 2PC.
Regards,
--
F
On Mon, Aug 3, 2015 at 8:55 PM, Amit Kapila wrote:
> On Thu, Jul 16, 2015 at 9:58 PM, Robert Haas wrote:
>>
>> On Thu, Jul 16, 2015 at 9:41 AM, Fujii Masao
>> wrote:
>> > Here are some minor comments:
>> >
>> > +ereport(LOG,
>> > +(errmsg("ignoring \"%s\"
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> In get_row_security_policies():
>
> /*
> * If the only built-in policy is the default-deny one, and hook policies
> * exist, then use the hook policies only and do not apply the
> * default-deny policy. Otherwise, we wil
On Fri, Jul 17, 2015 at 12:28 PM, Michael Paquier
wrote:
> On Wed, Jul 1, 2015 at 9:31 PM, Fujii Masao wrote:
>> On Wed, Jul 1, 2015 at 2:21 AM, Heikki Linnakangas wrote:
>>> On 06/29/2015 09:44 AM, Michael Paquier wrote:
On Mon, Jun 29, 2015 at 4:55 AM, Heikki Linnakangas wrote:
>
On 07/28/2015 10:28 PM, Heikki Linnakangas wrote:
On 07/27/2015 01:20 PM, Ildus Kurbangaliev wrote:
Hello.
In the attached patch I've made a refactoring for tranches.
The prefix for them was extended, and I've did a split of LWLockAssign
to two
functions (one with tranche and second for user de
On Sun, Aug 2, 2015 at 11:37 PM, Rajeev rastogi
wrote:
> On 31 July 2015 23:10, Robert Haas Wrote:
>>I think we're going entirely down the wrong path here. Why is it ever useful
>>for a backend's lock requests to conflict with themselves, even with
>>autonomous transactions? That seems like an
On Fri, Jul 31, 2015 at 10:11 AM, Amit Kapila
wrote:
>
> On Wed, Jul 29, 2015 at 11:48 PM, Andres Freund
wrote:
> >
> > On 2015-07-29 12:54:59 -0400, Robert Haas wrote:
> > > I would try to avoid changing lwlock.c. It's pretty easy when so
> > > doing to create mechanisms that work now but make
On 08/03/2015 07:01 AM, Michael Paquier wrote:
On Sun, Aug 2, 2015 at 4:01 AM, Heikki Linnakangas wrote:
Perhaps it's best if we copy all the WAL files from source in copy-mode, but
not in libpq mode. Regarding old WAL files in the target, it's probably best
to always leave them alone. They shou
In get_row_security_policies():
/*
* If the only built-in policy is the default-deny one, and hook policies
* exist, then use the hook policies only and do not apply the
* default-deny policy. Otherwise, we will apply both sets below.
*/
if (defaultDeny &&
(hoo
On Sat, Aug 1, 2015 at 12:18 AM, Robert Haas wrote:
> On Fri, Jul 31, 2015 at 6:33 AM, Ashutosh Bapat
> wrote:>
> >> I'm not hung up on the table-level attribute, but I think having a
> >> server-level attribute rather than a global GUC is a good idea.
> >> However, I welcome other thoughts on t
On Thu, Jul 16, 2015 at 9:58 PM, Robert Haas wrote:
>
> On Thu, Jul 16, 2015 at 9:41 AM, Fujii Masao
wrote:
> > Here are some minor comments:
> >
> > +ereport(LOG,
> > +(errmsg("ignoring \"%s\" file because no
> > \"%s\" file exists",
> > +
В письме от 3 августа 2015 14:30:46 пользователь Michael Paquier написал:
> On Mon, Aug 3, 2015 at 1:03 AM, Nikolay Shaplov
>
> wrote:
> > Hi!
> >
> > I've created a patch for pageinspect that allows to see data stored in the
> > tuple.
> >
> > This patch has two main purposes:
> >
> > 1. Prac
On Mon, Aug 3, 2015 at 12:27 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> 1) Test and results are in attachments. Everything seems to work as
> expected.
> 2) I dropped these notices. It was done only for debug purposes. Updated
> patch is attached.
> 3) fixed
>
Good! Anothe
30.07.2015 16:33, Alexander Korotkov пишет:
Hi!
On Thu, Jul 30, 2015 at 2:51 PM, Anastasia Lubennikova
mailto:lubennikov...@gmail.com>> wrote:
I have written microvacuum support for gist access method.
Briefly microvacuum includes two steps:
1. When search tells us that the tupl
Re: Michael Paquier 2015-07-28
> On Tue, Jul 28, 2015 at 5:57 PM, Christoph Berg wrote:
> > for something between 10% and 20% of the devel builds for apt.postgresql.org
> > (which happen every 6h if there's a git change, so it happens every few
> > days),
> > I'm seeing this:
> > Dubious, test
On 2 August 2015 at 13:13, Michael Paquier
wrote:
> Hi all,
>
> Commit 4046e58c (dated of 2001) has introduced the following comment
> in vacuumlazy.c:
> + /* If any tuples need to be deleted, perform final vacuum cycle */
> + /* XXX put a threshold on min nuber of tuples here? */
> +
68 matches
Mail list logo
