On Thu, Feb 19, 2015 at 3:57 PM, Michael Paquier
wrote:
> On Thu, Feb 19, 2015 at 2:58 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> 1-2) sizeof(ParamListInfoData) is present in a couple of places,
>>> assuming that sizeof(ParamListInfoData) has the equivalent of 1
>>> parameter, like prepa
2015-02-17 10:39 GMT+09:00 Kouhei Kaigai :
> Let me put some comments in addition to where you're checking now.
>
> [design issues]
> * Cost estimation
> Estimation and evaluation of cost for remote join query is not an
> obvious issue. In principle, local side cannot determine the cost
> to run re
On Thu, Feb 19, 2015 at 2:58 PM, Tom Lane wrote:
> Michael Paquier writes:
>> 1-2) sizeof(ParamListInfoData) is present in a couple of places,
>> assuming that sizeof(ParamListInfoData) has the equivalent of 1
>> parameter, like prepare.c, functions.c, spi.c and postgres.c:
>> - /* sizeof(P
On Tue, Feb 10, 2015 at 12:09 PM, Peter Geoghegan wrote:
>> Then the problem suddenly becomes that previous choices of
>> indexes/statements aren't possible anymore. It seems much better to
>> introduce the syntax now and not have too much of a usecase for
>> it.
>
> The only way the lack of a way
On Mon, Feb 16, 2015 at 8:55 PM, Andres Freund wrote:
> On 2015-02-16 11:30:20 +, Syed, Rahila wrote:
>> - * As a trivial form of data compression, the XLOG code is aware that
>> - * PG data pages usually contain an unused "hole" in the middle, which
>> - * contains only zero bytes. If hole_l
On Thu, Feb 19, 2015 at 2:13 PM, Naoya Anzai
wrote:
> As a result, I think you should not delete VACOPT_VERBOSE.
In v8 it is not deleted. It is still declared, and its use is isolated
in gram.y, similarly to VACOPT_FREEZE.
> According to the last mail I have posted, the difference of
> manual-va
On Wed, Feb 18, 2015 at 12:23:05PM -0500, Robert Haas wrote:
> On Sun, Feb 15, 2015 at 6:24 PM, Noah Misch wrote:
> > It's important for parallelism to work under the extended query protocol,
> > and
> > that's nontrivial. exec_parse_message() sets cursorOptions.
> > exec_bind_message() runs the
Hi, Michael
I thought about VACOPT_VERBOSE again.
As a result, I think you should not delete VACOPT_VERBOSE.
According to the last mail I have posted, the difference of
manual-vacuum log and auto-vacuum log exists clearly.
So, at least you should not touch the mechanism of VACOPT_VERBOSE
until
Michael Paquier writes:
> 1-2) sizeof(ParamListInfoData) is present in a couple of places,
> assuming that sizeof(ParamListInfoData) has the equivalent of 1
> parameter, like prepare.c, functions.c, spi.c and postgres.c:
> - /* sizeof(ParamListInfoData) includes the first array element */
>
On Thu, Feb 19, 2015 at 11:00 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Thu, Feb 19, 2015 at 7:29 AM, Tom Lane wrote:
>>> Moreover, if we have any code that is assuming such cases are okay, it
>>> probably needs a second look. Isn't this situation effectively assuming
>>> that a varia
Hi all,
I noticed that the following structures are still defined in
gin_private.h but they are used nowhere since 2c03216d that has
reworked WAL format:
- ginxlogSplitEntry
- ginxlogSplitDataLeaf
- ginxlogSplitDataInternal
Attached is a trivial patch to remove them.
Regards,
--
Michael
diff --gi
On Wed, Feb 18, 2015 at 6:50 PM, Andrew Dunstan wrote:
>
> On 02/18/2015 08:34 PM, David Fetter wrote:
>
>> On Tue, Feb 17, 2015 at 08:21:32PM -0500, Peter Eisentraut wrote:
>>
>>> On 1/20/15 6:32 PM, David G Johnston wrote:
>>>
In fact, as far as the database knows, the values provided to t
On Thu, Feb 19, 2015 at 12:25 AM, David Steele wrote:
> Hi Fujii,
>
> Thanks for taking a look at the patch. Comments below:
>
> On 2/18/15 6:11 AM, Fujii Masao wrote:
>> On Wed, Feb 18, 2015 at 1:26 AM, David Steele wrote:
>>> On 2/17/15 10:23 AM, Simon Riggs wrote:
I vote to include pgaud
On 23.12.2014 11:28, Heikki Linnakangas wrote:
> On 12/07/2014 03:54 AM, Tomas Vondra wrote:
>> The one interesting case is the 'step skew' with statistics_target=10,
>> i.e. estimates based on mere 3000 rows. In that case, the adaptive
>> estimator significantly overestimates:
>>
>> values
On 19/02/15 15:00, Tom Lane wrote:
Michael Paquier writes:
On Thu, Feb 19, 2015 at 7:29 AM, Tom Lane wrote:
Moreover, if we have any code that is assuming such cases are okay, it
probably needs a second look. Isn't this situation effectively assuming
that a variable-length array is fixed-len
On Wed, Feb 18, 2015 at 10:57 PM, Kevin Grittner wrote:
> Magnus Hagander wrote:
> > On Feb 17, 2015 12:26 AM, "Andres Freund"
> wrote:
> >> On 2015-02-16 16:35:46 -0500, Bruce Momjian wrote:
> >> But max_standby_streaming_delay, max_standby_archive_delay and
> >> hot_standby_feedback are among
On 2015/02/18 21:44, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/18 7:44, Stephen Frost wrote:
Attached is a patch which should address this. Would love your (or
anyone else's) feedback on it. It appears to address the issue which
you raised and the re
On 19.2.2015 03:14, Tomas Vondra wrote:
>
> I've noticed two unrelated files
Meh, should be "I noticed the patch removes two unrelated files" ...
>
> ../src/test/modules/dummy_seclabel/expected/dummy_seclabel.out
> ../src/test/modules/dummy_seclabel/sql/dummy_seclabel.sql
>
> I suppose
On 13.2.2015 16:20, Teodor Sigaev wrote:
> Some of users of intarray contrib module wish to use its features
> with another kind of arrays, not only for int4 type. Suggested
> module generalizes intarray over other (not all) types op pgsql.
>
> Anyarray also provides a calculation of similarity tw
Michael Paquier writes:
> On Thu, Feb 19, 2015 at 7:29 AM, Tom Lane wrote:
>> Moreover, if we have any code that is assuming such cases are okay, it
>> probably needs a second look. Isn't this situation effectively assuming
>> that a variable-length array is fixed-length?
> AFAIK, switching a b
Hi there,
On 30.1.2015 06:27, Matt Kelly wrote:
> ​Actually, I just did one more code review of myself, and somehow missed
> that I submitted the version with the wrong oid. The oid used in the
> first version is wrong (1) and was from before I read the docs on
> properly picking one.
>
> At
On 02/18/2015 08:34 PM, David Fetter wrote:
On Tue, Feb 17, 2015 at 08:21:32PM -0500, Peter Eisentraut wrote:
On 1/20/15 6:32 PM, David G Johnston wrote:
In fact, as far as the database knows, the values provided to this
function do represent an entire population and such a correction
would be
On Tue, Feb 17, 2015 at 08:21:32PM -0500, Peter Eisentraut wrote:
> On 1/20/15 6:32 PM, David G Johnston wrote:
> > In fact, as far as the database knows, the values provided to this
> > function do represent an entire population and such a correction
> > would be unnecessary. I guess it boils dow
On Thu, Feb 19, 2015 at 7:29 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Wed, Feb 18, 2015 at 10:09 PM, Andres Freund
>> wrote:
>>> The compiler will complain if you use a FLEXIBLE_ARRAY_MEMBER in the
>>> middle of a struct but not when when you embed a struct that uses it
>>> into the
* Kevin Grittner (kgri...@ymail.com) wrote:
> Stephen Frost wrote:
> > I also agree with the general idea that it makes sense to provide a way
> > to control bloat, but I think you've missed what Andres was getting at
> > with his suggestion (if I understand correctly, apologies if I don't).
> >
>
On Sun, Feb 15, 2015 at 8:27 PM, Tom Lane wrote:
> There might be something in that, but again it's not much like this patch.
> The key point I think we're both making is that nondeterministic failures
> are bad, especially when you're talking about long-running, expensive-to-
> retry transaction
Andres pointed out that the INSERT ... ON CONFLICT UPDATE patch
doesn't work well with logical decoding. Basically, as things stand,
there is no means of determining that an INSERT had an ON CONFLICT
UPDATE clause from logical decoding. It isn't obvious that this
matters - after all, the relevant W
While hacking around with expanded arrays, I realized that array_push()
is just a horribly badly designed function. There is no reason at all
for the same C function to underlie both array_append and array_prepend:
the function spends significant time and effort reverse-engineering which
way it wa
Stephen Frost wrote:
> I also agree with the general idea that it makes sense to provide a way
> to control bloat, but I think you've missed what Andres was getting at
> with his suggestion (if I understand correctly, apologies if I don't).
>
> The problem is that we're only looking at the overal
On 16/02/15 10:46, Andres Freund wrote:
On 2015-02-16 11:34:10 +0200, Heikki Linnakangas wrote:
At a quick glance, this basic design seems workable. I would suggest
expanding the replication IDs to regular 4 byte oids. Two extra bytes is a
small price to pay, to make it work more like everythin
Kevin,
* Kevin Grittner (kgri...@ymail.com) wrote:
> Magnus Hagander wrote:
> > On Feb 17, 2015 12:26 AM, "Andres Freund" wrote:
> >> On 2015-02-16 16:35:46 -0500, Bruce Momjian wrote:
>
> >>> It seems we already have a mechanism in place that allows
> >>> tuning of query cancel on standbys vs.
Michael Paquier writes:
> On Wed, Feb 18, 2015 at 10:09 PM, Andres Freund
> wrote:
>> The compiler will complain if you use a FLEXIBLE_ARRAY_MEMBER in the
>> middle of a struct but not when when you embed a struct that uses it
>> into the middle another struct. At least gcc doesn't and I think i
On Wed, Feb 18, 2015 at 10:09 PM, Andres Freund wrote:
> On 2015-02-18 17:15:18 +0900, Michael Paquier wrote:
>> >> - I don't think that the t_bits fields in htup_details.h should be
>> >> updated either.
>> >
>> > Why not? Any not broken code should already use MinHeapTupleSize and
>> > similar m
On 2015-02-19 07:10:19 +0900, Michael Paquier wrote:
> On Wed, Feb 18, 2015 at 10:09 PM, Andres Freund
> wrote:
> > On 2015-02-18 17:15:18 +0900, Michael Paquier wrote:
> >> >> - I don't think that the t_bits fields in htup_details.h should be
> >> >> updated either.
> >> >
> >> > Why not? Any no
Magnus Hagander wrote:
> On Feb 17, 2015 12:26 AM, "Andres Freund" wrote:
>> On 2015-02-16 16:35:46 -0500, Bruce Momjian wrote:
>>> It seems we already have a mechanism in place that allows
>>> tuning of query cancel on standbys vs. preventing standby
>>> queries from seeing old data, specifical
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Now, we probably don't want to hack *all* the utility commands to return
> > > ObjectAddress instead of OID, because it many cases that's just not
> > > going to be convenient (not to speak of the code churn); so I think for
> > > most objtyp
> > Now, we probably don't want to hack *all* the utility commands to return
> > ObjectAddress instead of OID, because it many cases that's just not
> > going to be convenient (not to speak of the code churn); so I think for
> > most objtypes the ProcessUtilitySlow stanza would look like this:
> T
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Patch 0002 I think is good to go as well, AFAICT (have the various
> > > RENAME commands return the OID and attnum of affected objects).
> >
> > It's not
Stephen,
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Patch 0002 I think is good to go as well, AFAICT (have the various
> > RENAME commands return the OID and attnum of affected objects).
>
> It's not a huge complaint, but it feels a bit awkward to me that
> Ex
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Andres Freund wrote:
> > On 2015-02-15 01:48:15 -0300, Alvaro Herrera wrote:
> > I think you should just go ahead and commit 0001, 0002, 0006. Those have
> > previously been discussed and seem like a good idea and uncontroversial
> > eve
Andres Freund wrote:
> Hi,
>
> On 2015-02-15 01:48:15 -0300, Alvaro Herrera wrote:
> > This is a repost of the patch to add CREATE command deparsing support to
> > event triggers. It now supports not only CREATE but also ALTER and
> > other commands such as GRANT/REVOKE, COMMENT ON and SECURITY L
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > I've started taking a look at this as the pgaudit bits depend on it and
> > noticed that the patch set implies there's 42 patches, but there were
> > only 37 attached..?
>
> Ah, I didn't realize when I posted th
Stephen Frost wrote:
> I've started taking a look at this as the pgaudit bits depend on it and
> noticed that the patch set implies there's 42 patches, but there were
> only 37 attached..?
Ah, I didn't realize when I posted that the subject was counting those
extra patches. They are later patche
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> This is a repost of the patch to add CREATE command deparsing support to
> event triggers. It now supports not only CREATE but also ALTER and
> other commands such as GRANT/REVOKE, COMMENT ON and SECURITY LABEL.
> This patch series is b
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/18 7:44, Stephen Frost wrote:
> * The patch applies to the latest head, 'make' passes successfully,
> but 'make check' fails in the rowsecurity test.
Here's the patch against master. I'm still fiddling with the comment
wor
On Tue, Feb 17, 2015 at 12:34 AM, Michael Paquier wrote:
> On Tue, Feb 17, 2015 at 7:39 AM, Kohei KaiGai wrote:
> > 2015-02-16 12:25 GMT+09:00 Michael Paquier :
> >>
> >>
> >> On Fri, Feb 13, 2015 at 10:06 AM, Michael Paquier
> >> wrote:
> >>>
> >>> In order to move on to the next CF, I am goin
On Wed, Feb 18, 2015 at 12:34 AM, Michael Paquier wrote:
> On Wed, Feb 18, 2015 at 5:55 AM, Corey Huinker
> wrote:
> > What is required to get the New Patch superpower? I'm also in need of it.
>
> CCing Magnus... I am not sure myself, but I would imagine that the
> commit fest needs to be "Open"
Hi,
On 2015-02-15 01:48:15 -0300, Alvaro Herrera wrote:
> This is a repost of the patch to add CREATE command deparsing support to
> event triggers. It now supports not only CREATE but also ALTER and
> other commands such as GRANT/REVOKE, COMMENT ON and SECURITY LABEL.
> This patch series is brok
Hi Fujii,
Thanks for taking a look at the patch. Comments below:
On 2/18/15 6:11 AM, Fujii Masao wrote:
> On Wed, Feb 18, 2015 at 1:26 AM, David Steele wrote:
>> On 2/17/15 10:23 AM, Simon Riggs wrote:
>>> I vote to include pgaudit in 9.5, albeit with any changes. In
>>> particular, David may h
On 02/17/2015 08:21 PM, Peter Eisentraut wrote:
On 1/20/15 6:32 PM, David G Johnston wrote:
In fact, as far as
the database knows, the values provided to this function do represent an
entire population and such a correction would be unnecessary. I guess it
boils down to whether "future" querie
On 2/18/15 8:25 AM, Simon Riggs wrote:
> On 15 February 2015 at 02:34, David Steele wrote:
>
>> I've posted a couple of messages over the last few weeks about the work
>> I've been doing on the pg_audit extension. The lack of response could
>> be due to either universal acclaim or complete apath
> VACUUM [FULL] [FREEZE] ... [ANALYZE] [tname [(cname, ...)]
> | VACUUM [({FULL [bool]|FREEZE [bool]|...}[,...])] [tname [(cname, ...)]
> | VACUUM [tname [(cname, ...)] [[WITH ]({FULL [bool]|FREEZE [bool]|...})]
>
> REINDEX [{INDEX|TABLE|...}] name [[WITH] (VERBOSE [bool]|...)]
>
> EXPLAIN [[WITH
Andres Freund writes:
> On 2015-02-16 21:34:57 -0500, Tom Lane wrote:
>> Also, if we want to insist that these fields be accessed
>> through heap_getattr, I'd be inclined to put them inside the "#ifdef
>> CATALOG_VARLEN" to enforce that.
> That we definitely should do. It's imo just a small bug t
Stephen Frost wrote:
> Abhijit,
>
> * Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
> > I'm confused and unhappy about your characterisation of the state of
> > this patch. You make it seem as though there was broad consensus about
> > the changes that were needed, and that I left the patch sit
Hello,
>I think we should change the xlog format so that the block_id (which currently
>is XLR_BLOCK_ID_DATA_SHORT/LONG or a actual block id) isn't the block id but
>something like XLR_CHUNK_ID. Which is used as is for
>XLR_CHUNK_ID_DATA_SHORT/LONG, but for backup blocks can be set to to
>>XLR
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
> At 2015-02-17 13:01:46 -0500, sfr...@snowman.net wrote:
> > I have to admit that I'm confused by this. Patches don't stabilise
> > through sitting in the archives, they stabilise when the comments are
> > being addressed, the patch upda
Tim Kane wrote:
> CREATE MATERIALISED VIEW local.devices;
>
> CREATE test_table (device_id bigint FOREIGN KEY (device_id) REFERENCES
> local.devices (device_id) );
>
> ERROR: referenced relation "devices" is not a table
In the future, please show code that you have actually run. In
this case
On 15 February 2015 at 02:34, David Steele wrote:
> I've posted a couple of messages over the last few weeks about the work
> I've been doing on the pg_audit extension. The lack of response could
> be due to either universal acclaim or complete apathy, but in any case I
> think this is a very im
On 2015-02-16 21:34:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-02-17 05:51:22 +0900, Michael Paquier wrote:
> >> diff --git a/src/include/catalog/pg_authid.h
> >> b/src/include/catalog/pg_authid.h
> >> index e01e6aa..d8789a5 100644
> >> --- a/src/include/catalog/pg_authid.h
> >
Neil,
* Neil Tiffin (ne...@neiltiffin.com) wrote:
> I meant it to go to the list, but hit the wrong button.
No problem.
> > On Feb 17, 2015, at 7:01 PM, Stephen Frost wrote:
> > I noticed that you email'd me directly on this reply. Not sure if you
> > intended to or not, but I'm fine with my r
On 2015-02-18 16:59:26 +0530, Amit Kapila wrote:
> On Tue, Feb 17, 2015 at 9:52 PM, Andres Freund
> wrote:
> > A query whose runetime is dominated by a sequential scan (+ attached
> > filter) is certainly going to require a bigger prefetch size than one
> > that does other expensive stuff.
> >
> >
On 2015-02-18 17:15:18 +0900, Michael Paquier wrote:
> >> - I don't think that the t_bits fields in htup_details.h should be
> >> updated either.
> >
> > Why not? Any not broken code should already use MinHeapTupleSize and
> > similar macros.
>
> Changing t_bits impacts HeapTupleHeaderData, Reorde
Stephen,
I meant it to go to the list, but hit the wrong button.
> On Feb 17, 2015, at 7:01 PM, Stephen Frost wrote:
>
> Neil,
>
> I noticed that you email'd me directly on this reply. Not sure if you
> intended to or not, but I'm fine with my response going to the list.
>
> * Neil Tiffin (n
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/18 7:44, Stephen Frost wrote:
> >Attached is a patch which should address this. Would love your (or
> >anyone else's) feedback on it. It appears to address the issue which
> >you raised and the regression test changes are
On Tue, Feb 17, 2015 at 9:52 PM, Andres Freund
wrote:
>
> On 2015-02-11 15:49:17 -0500, Robert Haas wrote:
>
> A query whose runetime is dominated by a sequential scan (+ attached
> filter) is certainly going to require a bigger prefetch size than one
> that does other expensive stuff.
>
> Imagine
On Wed, Feb 18, 2015 at 1:26 AM, David Steele wrote:
> On 2/17/15 10:23 AM, Simon Riggs wrote:
>> I vote to include pgaudit in 9.5, albeit with any changes. In
>> particular, David may have some changes to recommend, but I haven't
>> seen a spec or a patch, just a new version of code (which isn't
On 9 February 2015 at 20:52, Thom Brown wrote:
>
> Hi all,
>
> Google Summer of Code 2015 is approaching. I'm intending on registering
> PostgreSQL again this year.
>
> Before I do that, I'd like to have an idea of how many people are
> interested in being either a student or a mentor.
>
> I've
On 2015/02/18 8:13, Tom Lane wrote:
> So I went back to your v1 patch and have now committed that with some
> cosmetic modifications. Sorry for making you put time into a dead end.
I don't mind it. Thanks for committing the patch!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing
On 2015/02/18 7:44, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/11 4:06, Stephen Frost wrote:
I had been trying to work out an FDW-specific way to address this, but I
think Dean's right that this should be addressed in
expand_security_qual(), which means
Sorry, I sent the previous mail without patches by accident. The
patches are attached to this mail.
Hello, this is the patchset v2 of this feature.
0001-Add-regrole.patch
Adding regrole as the name says.
0002-Add-regnamespace.patch
Adding regnamespace. This depends on 0001 patch.
0003-
Hello, this is the patchset v2 of this feature.
0001-Add-regrole.patch
Adding regrole as the name says.
0002-Add-regnamespace.patch
Adding regnamespace. This depends on 0001 patch.
0003-Check-new-reg-types-are-not-used-as-default-values.patch
Inhibiting the new OID aliss types from being u
Hello, this is the last patch for pg_basebackup/pg_receivexlog on
master (9.5). Preor versions don't have this issue.
4. basebackup_reply_fix_mst_v2.patch
receivelog.c patch applyable on master.
This is based on the same design with
walrcv_reply_fix_91_v2.patch in the aspect of gettimeofday().
On Tue, Feb 17, 2015 at 9:02 AM, Andres Freund wrote:
> On 2015-02-17 05:51:22 +0900, Michael Paquier wrote:
>> -- inv_api.c uses bytea in an internal structure without putting it at
>> the end of the structure. For clarity I think that we should just use
>> a bytea pointer and do a sufficient allo
Hi Rowley,
Let me put some comments on this patch.
This patch itself looks good as an infrastructure towards
the big picture, however, we still don't reach the consensus
how combined functions are used instead of usual translation
functions.
Aggregate function usually consumes one or more values
74 matches
Mail list logo
