On 2015-02-07 17:16:12 -0500, Robert Haas wrote:
> On Sat, Feb 7, 2015 at 4:30 PM, Andres Freund wrote:
> > > [ criticicm of Amit's heapam integration ]
> > I'm not convinced that that reasoning is generally valid. While it may
> > work out nicely for seqscans - which might be useful enough on it
Hello,
A bug had been introduced in the latest versions of the patch. The order of
parameters passed to pglz_decompress was wrong.
Please find attached patch with following correction,
Original code,
+ if (pglz_decompress(block_image, record->uncompressBuf,
+
On Mon, Feb 09, 2015 at 12:37:05PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > Yeah, but people expect to be able to partition on ranges that are not
> > all of equal width. I think any proposal that we shouldn't support
> > that is the kiss of death for a feature like this - it will be so
>
On Mon, Feb 9, 2015 at 2:54 PM, Tatsuo Ishii wrote:
> Agreed. Here is the patch to implement the idea: -f just implies -n.
Some small comments:
- is_no_vacuum, as well as is_init_mode, are defined as an integers
but their use imply that they are boolean switches. This patch sets
is_no_vacuum to tr
On 2015/02/10 7:23, Dean Rasheed wrote:
On 9 February 2015 at 21:17, Stephen Frost wrote:
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection queries issued at ForeignScan.
I've looked
On 2015/02/07 1:09, Tom Lane wrote:
> IIRC, this code was written at a time when we didn't have NO INHERIT check
> constraints and so it was impossible for the parent table to get optimized
> away while leaving children. So the comment in ExplainModifyTarget was
> good at the time. But it no long
I am up for mentoring again.
On 10 Feb 2015 02:23, "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
On 10-02-2015 AM 02:37, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane wrote:
>>> It's going to be complicated and probably buggy, and I think it is heading
>>> in the wrong direction altogether. If you want to partition in some
>>> arbitrary complicated fashi
On Mon, Feb 9, 2015 at 10:27 PM, Syed, Rahila wrote:
> (snip)
Thanks for showing up here! I have not tested the test the patch,
those comments are based on what I read from v17.
>>> Do we always need extra two bytes for compressed backup block?
>>> ISTM that extra bytes are not necessary when the
Ravi Kiran writes:
> I tried modifying the postgresql.conf file where I set the value
> enable_hashjoin=off and also enable_mergejoin=off, so that I could force
> postgres to use nested loop.
> but postgres is still using the hash join algorithm even after modifying
> the postgresql code.
Did you
Stephen Frost writes:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> FWIW using different commit messages for different branches is a
>> mistake. The implicit policy we have is that there is one message,
>> identical for all branches, that describe how the patch differs in each
>> branch
On 9 February 2015 at 21:17, Stephen Frost wrote:
>> > On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
>> > > I noticed that when updating security barrier views on foreign tables,
>> > > we fail to give FOR UPDATE to selection queries issued at ForeignScan.
>>
> I've looked into this a fair bit mo
Am 09.02.15 um 13:13 schrieb Hakan Kocaman:
> Hi,
>
> 2015-02-09 10:37 GMT+01:00 Marc Balmer mailto:m...@msys.ch>>:
>
>
> (I use cursors to display large datasets in a page-wise way, where the
> user can move per-page, or, when displaying a single record, per record.
> When the us
Hi,
I want to disable the hashjoin algorithm used by postgres by default, and
enable the nested loop join algorithm, can some one tell me how to do that.
I tried modifying the postgresql.conf file where I set the value
enable_hashjoin=off and also enable_mergejoin=off, so that I could force
post
While thinking about add_path_precheck() function, it occurred to me that it
can discard some paths that otherwise would have chance be accepted in this
part of add_path():
/*
* Same pathkeys and outer rels, and fuzzily
* the same cost, so keep just one; to decide
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> FWIW using different commit messages for different branches is a
> mistake. The implicit policy we have is that there is one message,
> identical for all branches, that describe how the patch differs in each
> branch whenever necessary.
* Stephen Frost (sfr...@snowman.net) wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
> > wrote:
> > > I noticed that when updating security barrier views on foreign tables,
> > > we fail to give FOR UPDATE to selection queries issued at Fore
Stephen Frost wrote:
> > Besides the sloppiness of back-patching in
> > that one macro and nothing else, this is a huge fraction of the patch
> > that's just *gone* in the 9.0 and 9.1 branches, and there's not so
> > much as a hint about it in the commit message, which is pretty
> > astonishing to
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> I happened to notice this morning while hacking that the
> "hasRowSecurity" fields added to PlannerGlobal and PlannedStmt have
> not been given proper nodefuncs.c support. Both need to be added to
> outfuncs.c, and the latter to copyfuncs.c.
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> In 9.2 and newer branches, this commit makes substantial changes to
> execMain.c. In 9.1 and 9.0, though, the change to that file is just
> this:
>
> --- a/src/backend/executor/execMain.c
> +++ b/src/backend/executor/execMain.c
> @@ -95,6 +9
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 volunteered to be admin again, but if anyone else has a strong
int
Branch: master [804b6b6db] 2015-01-28 12:31:30 -0500
Branch: REL9_4_STABLE Release: REL9_4_1 [3cc74a3d6] 2015-01-28 12:32:06 -0500
Branch: REL9_3_STABLE Release: REL9_3_6 [4b9874216] 2015-01-28 12:32:39 -0500
Branch: REL9_2_STABLE Release: REL9_2_10 [d49f84b08] 2015-01-28 12:32:56 -0500
Branch: REL
I did some more digging on bug
http://www.postgresql.org/message-id/cahul3dpwyfnugdgo95ohydq4kugdnbkptjq0mnbtubhcmg4...@mail.gmail.com
which describes a deadlock when using libpq with SSL in a multi-threaded
environment with other threads doing SSL independently.
Attached is a reproducing Python s
On Mon, Feb 9, 2015 at 12:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane wrote:
>>> It's going to be complicated and probably buggy, and I think it is heading
>>> in the wrong direction altogether. If you want to partition in some
>>> arbitrary complic
Robert Haas writes:
> On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane wrote:
>> It's going to be complicated and probably buggy, and I think it is heading
>> in the wrong direction altogether. If you want to partition in some
>> arbitrary complicated fashion that the system can't reason about very
>>
On Mon, Feb 9, 2015 at 10:36 AM, Tom Lane wrote:
> It's going to be complicated and probably buggy, and I think it is heading
> in the wrong direction altogether. If you want to partition in some
> arbitrary complicated fashion that the system can't reason about very
> effectively, we *already ha
On Mon, Feb 9, 2015 at 5:38 AM, Magnus Hagander wrote:
> On Mon, Feb 9, 2015 at 11:09 AM, Marco Nenciarini
> wrote:
>>
>> Il 08/02/15 17:04, Magnus Hagander ha scritto:
>> >
>> > Filenames are now shown for attachments, including a direct link to the
>> > attachment itself. I've also run a job t
Amit Langote writes:
> Okay, let me back up a little and think about your suggestion which I do
> not seem to understand very well - it raises a few questions for me:
> does this mean a partitioning criteria is associated with parent
> (partitioned table) rather than each individual partition?
Ab
Heikki Linnakangas writes:
> On 02/09/2015 03:21 AM, Tom Lane wrote:
>> Meh. I don't care for that much --- it sounds a lot like deciding that
>> your problem is a nail because there is a hammer within reach. A random
>> collection of ranges doesn't seem like a very appropriate representation
>>
Hi,
2015-02-09 10:37 GMT+01:00 Marc Balmer :
>
> (I use cursors to display large datasets in a page-wise way, where the
> user can move per-page, or, when displaying a single record, per record.
> When the user goes back from per-record view to page-view, I have to
> restore the cursor to the po
On Mon, Feb 9, 2015 at 2:31 AM, Amit Kapila wrote:
> Another idea is to use Executor level interfaces (like ExecutorStart(),
> ExecutorRun(), ExecutorEnd()) for execution rather than using Portal
> level interfaces. I have used Portal level interfaces with the
> thought that we can reuse the exis
Hello,
>> Do we always need extra two bytes for compressed backup block?
>> ISTM that extra bytes are not necessary when the hole length is zero.
>> In this case the length of the original backup block (i.e.,
>> uncompressed) must be BLCKSZ, so we don't need to save the original
>> size in the e
At 2015-02-09 12:52:41 +0200, hlinnakan...@vmware.com wrote:
>
> Ok, I've committed a patch that just moves the existing code to
> common/pg_crc.c […]
Thanks, looks good.
> Attached is a rebased version of the slicing-by-8 patch.
Looks OK too.
> Do you have access to big-endian hardware to test
On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao wrote:
> MemoryContextAllocExtended() was added, so isn't it time to replace palloc()
> with MemoryContextAllocExtended(CurrentMemoryContext, MCXT_ALLOC_NO_OOM)
> in allocate_recordbuf()?
Yeah, let's move on here, but not with this patch I am afraid as
On Sun, Feb 8, 2015 at 2:54 PM, Michael Paquier
wrote:
> On Fri, Feb 6, 2015 at 4:58 PM, Fujii Masao wrote:
>> - * Wait for more WAL to arrive. Time out after 5
>> seconds,
>> - * like when polling the archive, to react to a trigger
>> -
On Mon, Jan 5, 2015 at 1:25 PM, Michael Paquier
wrote:
> On Thu, Jan 1, 2015 at 1:10 AM, Robert Haas wrote:
>> On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
>> wrote:
>>> Hmm. There is no way to check beforehand if a palloc() will fail because of
>>> OOM. We could check for MaxAllocSize, t
Am 09.02.15 um 11:47 schrieb Marc Balmer:
>
>
> Am 09.02.15 um 10:46 schrieb Heikki Linnakangas:
>> [...]
>> You could fairly easily write an extension to do that, btw. A C function
>> could call GetPortalByName() and peek into the PortalData.portalPos field.
>>
>
> Would
>
> PGresult *PQdes
On 02/08/2015 08:33 PM, Abhijit Menon-Sen wrote:
At 2015-02-08 18:46:30 +0200, hlinnakan...@vmware.com wrote:
So I propose to move pg_crc.c to src/common, and move the tables
from pg_crc_tables.h directly to pg_crc.c. Thoughts?
Sounds fine to me.
Ok, I've committed a patch that just moves t
On Sun, Feb 8, 2015 at 11:03 PM, Robert Haas wrote:
>
> On Sat, Feb 7, 2015 at 10:36 PM, Amit Kapila
wrote:
> >> Well, I agree with you, but I'm not really sure what that has to do
> >> with the issue at hand. I mean, if we were to apply Amit's patch,
> >> we'd been in a situation where, for a n
Am 09.02.15 um 10:46 schrieb Heikki Linnakangas:
> [...]
> You could fairly easily write an extension to do that, btw. A C function
> could call GetPortalByName() and peek into the PortalData.portalPos field.
>
Would
PGresult *PQdescribePortal(PGconn *conn, const char *portalName);
from libp
On Mon, Feb 9, 2015 at 11:09 AM, Marco Nenciarini <
marco.nenciar...@2ndquadrant.it> wrote:
> Il 08/02/15 17:04, Magnus Hagander ha scritto:
> >
> > Filenames are now shown for attachments, including a direct link to the
> > attachment itself. I've also run a job to populate all old threads.
> >
Il 08/02/15 17:04, Magnus Hagander ha scritto:
>
> Filenames are now shown for attachments, including a direct link to the
> attachment itself. I've also run a job to populate all old threads.
>
I wonder what is the algorithm to detect when an attachment is a patch.
If you look at https://comm
2015-02-09 10:59 GMT+01:00 Marc Balmer :
> >
> > 2015-02-09 10:37 GMT+01:00 Marc Balmer m...@msys.ch>>:
> >
> > Currently there are FETCH and the (non standard) MOVE commands to
> work
> > on cursors.
> >
> > (I use cursors to display large datasets in a page-wise way, where
> the
> >
>
> 2015-02-09 10:37 GMT+01:00 Marc Balmer mailto:m...@msys.ch>>:
>
> Currently there are FETCH and the (non standard) MOVE commands to work
> on cursors.
>
> (I use cursors to display large datasets in a page-wise way, where the
> user can move per-page, or, when displaying a si
Hi
2015-02-09 10:37 GMT+01:00 Marc Balmer :
> Currently there are FETCH and the (non standard) MOVE commands to work
> on cursors.
>
> (I use cursors to display large datasets in a page-wise way, where the
> user can move per-page, or, when displaying a single record, per record.
> When the user
On 02/09/2015 11:37 AM, Marc Balmer wrote:
Currently there are FETCH and the (non standard) MOVE commands to work
on cursors.
(I use cursors to display large datasets in a page-wise way, where the
user can move per-page, or, when displaying a single record, per record.
When the user goes back
Currently there are FETCH and the (non standard) MOVE commands to work
on cursors.
(I use cursors to display large datasets in a page-wise way, where the
user can move per-page, or, when displaying a single record, per record.
When the user goes back from per-record view to page-view, I have to
r
On Sat, 2015-02-07 at 16:08 -0800, Jeff Davis wrote:
> I believe Inclusion Constraints will be important for postgres.
I forgot to credit Darren Duncan with the name of this feature:
http://www.postgresql.org/message-id/4f8bb9b0.5090...@darrenduncan.net
Regards,
Jeff Davis
--
Sent v
48 matches
Mail list logo
