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
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 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
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
>
> 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
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
> >
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
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.
> >
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 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
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
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 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
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, 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
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
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
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
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
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
>>
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
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
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
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 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
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
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
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
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
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.
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
* 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
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.
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
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
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
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
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
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
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
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
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 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
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 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 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
>
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 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
48 matches
Mail list logo
