On Friday, July 19, 2013 7:17 PM tubadzin wrote:
> Hi. I'm a little confused. 1.I have source code 9.2.4. version from
> http://www.postgresql.org/ftp/source/
> 2.I want to add new alghoritm to index nested loops join, merge join and hash
> join.
> I have Executor catalog in src catalag c
Andres Freund escribió:
> On 2013-07-19 08:23:25 -0400, Robert Haas wrote:
> > And I'd also propose getting rid
> > of bgw_sighup and bgw_sigterm in both branches, while we're at it.
> > AFAICT, they don't add any functionality, and they're basically
> > unusable for dynamically started backgroun
Joe Abbate writes:
> What is the purpose of the [ AND ... ] at the end of the WHEN clause?
> Is that for later releases, when presumably additional filter_variables
> will be introduced? Right now, if I add "AND tag IN ..." I get an
Yes. I had other filter variables in some versions of the patch
(2013/07/20 1:11), Tom Lane wrote:
> Andres Freund writes:
>> On 2013-07-20 00:49:11 +0900, Hiroshi Inoue wrote:
>>> Using SnapshotSelf instead of SnapshotNow for currtid_ () wouldn't
>>> matter.
>
>> I think it actually might. You could get into dicey situations if you
>> use currtid_ in a query
Noah Misch writes:
> On Fri, Jul 05, 2013 at 02:47:06PM -0400, Tom Lane wrote:
>> So I'm inclined to propose that SPI itself should offer some mechanism
>> for cleaning up tuple tables at subtransaction abort. We could just
>> have it automatically throw away tuple tables made in the current
>> s
Markus Wanner writes:
>> - per-installation (not even per-cluster) DSO availability
>>
>> If you install PostGIS 1.5 on a system, then it's just impossible to
>> bring another cluster (of the same PostgreSQL major version), let
> On Debian, that should be well possible. Certainly instal
This function appears to believe that it can PG_CATCH any random error
and then just carry on, without doing a subtransaction cleanup. This
is as wrong as can be. It might be all right if we had sufficiently
narrow constraints on what could happen inside the PG_TRY block, but in
point of fact it'
New version:
- fix returning "after" values if there are not "before"
- add more regression tests
I'd like to hear/read any feedback ;)
Regards,
Karol
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
--- a/doc/src/sgml/ref/update.sgml
+++ b/doc/
Hello,
What is the purpose of the [ AND ... ] at the end of the WHEN clause?
Is that for later releases, when presumably additional filter_variables
will be introduced? Right now, if I add "AND tag IN ..." I get an
ERROR: filter variable "tag" specified more than once
Joe
--
Sent via pgsql-
On Fri, Jul 19, 2013 at 2:15 PM, Robert Haas wrote:
> On Fri, Jul 19, 2013 at 1:45 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Jul 19, 2013 at 12:58 PM, Rod Taylor wrote:
A poorly coded trigger on the referencing table has the ability to break
foreign keys, and as a result
"some Salesforce folks" that would be me! It looks like I didn't quite
communicate to Tom just what I was looking for as I do indeed want to have
a variable number of "any" types, as:
CREATE AGGREGATE FOO ( ANYELEMENT, , VARIADIC "any") (
...
STYPE = ANYARRAY
...)
so the corresponding transi
On Wed, Jun 26, 2013 at 2:47 AM, Tom Lane wrote:
> Some of the rest of us would like to hear those reasons, because my
> immediate reaction is that the patch must be broken by design. WITH
> ORDINALITY should not be needing to mess with the fundamental evaluation
> semantics of SRFs, but it sure
*I am not the best specialist about logical replication, but as it
looks to be a requirement to have 2 nodes with different system
identifiers, you shouldn't link 1 node to another node whose data
folder has been created from the base backup of the former (for
example create the 2nd node based on a
On Fri, Jul 19, 2013 at 1:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 19, 2013 at 12:58 PM, Rod Taylor wrote:
>>> A poorly coded trigger on the referencing table has the ability to break
>>> foreign keys, and as a result create a database which cannot be dumped and
>>> reloaded.
One more change was required to add both the users in each node's db as
super users and replication started!!
Thanks.
On Thu, Jul 18, 2013 at 5:35 PM, Andres Freund wrote:
> Hi!
>
> On 2013-07-19 07:31:07 +0900, Michael Paquier wrote:
> > If this behavior is confirmed, I think that this bug sh
Robert Haas writes:
> On Fri, Jul 19, 2013 at 12:58 PM, Rod Taylor wrote:
>> A poorly coded trigger on the referencing table has the ability to break
>> foreign keys, and as a result create a database which cannot be dumped and
>> reloaded.
> This is a known limitation of our foreign key machine
On Fri, Jul 19, 2013 at 11:41:14AM -0400, Robert Haas wrote:
> On Thu, Jul 18, 2013 at 8:56 PM, David Fetter wrote:
> > Please find attached a PoC patch to implement $subject.
> >
> > So far, with a lot of help from Andrew Gierth, I've roughed out an
> > implementation which allows you to ALTER FO
Jeff Janes writes:
> On Thu, Jul 18, 2013 at 8:04 PM, Tom Lane wrote:
>> DISTINCT (and also ORDER BY) properties of aggregates are implemented
>> at runtime; the planner doesn't really do anything about them, except
>> suppress the choice it might otherwise make of using hashed aggregation.
> Co
On Thu, Jul 18, 2013 at 8:04 PM, Tom Lane wrote:
> Jeff Janes writes:
>> AGG_PLAIN sometimes does sorts, but it thinks they are free. Also, under
>> explain analyze it does not explicitly report whether the sort was external
>> or not, nor report the disk or memory usage, the way other sorts do.
Robert Haas escribió:
> 4. If we use GetActiveSnapshot, all the comments about about a fresh
> MVCC snapshot still apply. However, the snapshot in question could be
> even more stale, especially in repeatable read or serializable mode.
> However, this might be thought a more consistent behavior t
On Fri, Jul 19, 2013 at 12:33 PM, Tom Lane wrote:
> Stephen Frost writes:
>> if (lockmode == AccessShareLock)
>> aclresult = pg_class_aclcheck(reloid, GetUserId(),
>> ACL_SELECT);
>> + else if (lockmode == RowExclusiveLock)
>> + aclresult
A poorly coded trigger on the referencing table has the ability to break
foreign keys, and as a result create a database which cannot be dumped and
reloaded.
The BEFORE DELETE trigger accidentally does RETURN NEW, which suppresses
the DELETE action by the foreign key trigger. This allows the recor
On Fri, Jul 19, 2013 at 12:51 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Fri, Jul 19, 2013 at 12:29 PM, Alvaro Herrera
>> wrote:
>
>> > I think seeing otherwise invisible rows is useful in pgrowlocks. It
>> > helps observe the effects on tuples written by concurrent transactions
>>
Robert Haas escribió:
> On Fri, Jul 19, 2013 at 12:29 PM, Alvaro Herrera
> wrote:
> > I think seeing otherwise invisible rows is useful in pgrowlocks. It
> > helps observe the effects on tuples written by concurrent transactions
> > during experimentation. But then, maybe this functionality bel
On Fri, Jul 19, 2013 at 12:58 PM, Rod Taylor wrote:
> A poorly coded trigger on the referencing table has the ability to break
> foreign keys, and as a result create a database which cannot be dumped and
> reloaded.
>
> The BEFORE DELETE trigger accidentally does RETURN NEW, which suppresses the
>
On 07/18/2013 10:39 PM, Alvaro Herrera wrote:
> To scan the index, we first obtain the TID of index tuple for page 0. If
> this returns a valid TID, we read that tuple to determine the min/max bounds
> for this page range. If it returns invalid, then the range is unsummarized,
> and the scan must
On Fri, Jul 19, 2013 at 12:29 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Fri, Jul 19, 2013 at 1:27 AM, Tom Lane wrote:
>
>> > Why not tell people to use SnapshotDirty if they need a
>> > not-guaranteed-consistent result? At least then it's pretty obvious
>> > that you're getting som
On 07/15/2013 10:19 AM, Jeff Davis wrote:
> On Thu, 2013-07-11 at 10:51 -0400, Nicholas White wrote:
>> I've attached a revised version that fixes the issues above:
>
> I'll get to this soon, sorry for the delay.
>
> Regards,
> Jeff Davis
So ... are you doing a final review of this for the
Stephen Frost writes:
> if (lockmode == AccessShareLock)
> aclresult = pg_class_aclcheck(reloid, GetUserId(),
> ACL_SELECT);
> + else if (lockmode == RowExclusiveLock)
> + aclresult = pg_class_aclcheck(reloid, GetUserId(),
> +
Robert Haas escribió:
> On Fri, Jul 19, 2013 at 1:27 AM, Tom Lane wrote:
> > Why not tell people to use SnapshotDirty if they need a
> > not-guaranteed-consistent result? At least then it's pretty obvious
> > that you're getting some randomness in with your news.
> On further reflection, I thin
On 2013-07-20 00:49:11 +0900, Hiroshi Inoue wrote:
> (2013/07/18 21:46), Robert Haas wrote:
> >There seems to be a consensus that we should try to get rid of
> >SnapshotNow entirely now that we have MVCC catalog scans, so I'm
> >attaching two patches that together come close to achieving that goal:
(2013/07/18 21:46), Robert Haas wrote:
There seems to be a consensus that we should try to get rid of
SnapshotNow entirely now that we have MVCC catalog scans, so I'm
attaching two patches that together come close to achieving that goal:
...
With that done, the only remaining uses of Snapshot
> I've even proposed that in the past in
> 20130225211533.gd3...@awork2.anarazel.de . I plan to propose an updated
> version of that patch (not allowing numeric 2nd level ids) for the next
> CF.
>
> So you can just do stuff like:
>
> server.foo.grand_unified_config = value.
Sounds good to me.
Andres Freund writes:
> On 2013-07-20 00:49:11 +0900, Hiroshi Inoue wrote:
>> Using SnapshotSelf instead of SnapshotNow for currtid_ () wouldn't
>> matter.
> I think it actually might. You could get into dicey situations if you
> use currtid_ in a query performing updates or inserts because it wo
On Thu, Jul 18, 2013 at 8:56 PM, David Fetter wrote:
> Please find attached a PoC patch to implement $subject.
>
> So far, with a lot of help from Andrew Gierth, I've roughed out an
> implementation which allows you to ALTER FOREIGN TABLE so it inherits
> a local table.
>
> TBD: CREATE FOREIGN TAB
Greetings,
We've run into a curious case and I'd like to solicit feedback
regarding a possible change to the access rights required to acquire
locks on a relation. Specifically, we have a process which normally
INSERTs into a table and another process which Exclusive locks that
same tab
On 07/18/2013 11:30 PM, Tom Lane wrote:
Noah Misch writes:
On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
It's always annoyed me that pgindent insists on adjusting vertical
whitespace around #else and related commands. This has, for example,
rendered src/include/storage/barrier.h
Ashutosh Bapat writes:
> On Wed, Jun 26, 2013 at 1:30 AM, Tom Lane wrote:
>> For there to *be* a unique "appropriate outer join", we need to require
>> that a LATERAL-using qual clause that's under an outer join contain
>> lateral references only to the outer side of the nearest enclosing outer
>
On Thu, Jul 18, 2013 at 2:53 PM, David Christensen wrote:
> Hey folks, this corrects typos going back to
> 75c6519ff68dbb97f73b13e9976fb8075bbde7b8 where EUC_JIS_2004 and
> SHIFT_JIS_2004 were first added.
>
> These typos are present in all supported major versions of PostgreSQL, back
> through
On 07/18/2013 09:20 PM, Peter Eisentraut wrote:
The new jsonfuncs.c has some confusing typedef scheme. For example, it
has a bunch of definitions like this:
typedef struct getState
{
...
} getState, *GetState;
So GetState is a pointer to getState. I have never seen that kind of
conventi
Dean Rasheed writes:
> I took a look at this patch too. I didn't read all the code in detail,
> but there was one area I wondered about --- is it still necessary to
> add the new field rowsec_relid to RangeTblEntry?
> As far as I can see, it is only used in the new function getrelid()
> which rep
(2013/07/19 22:03), Andres Freund wrote:
On 2013-07-19 08:57:01 +0900, Inoue, Hiroshi wrote:
I had the idea they were used for a client-side implementation of WHERE
CURRENT OF. Perhaps that's dead code and could be removed entirely?
It's been reported that ODBC still uses them.
Though Postg
On 7/19/13 3:53 AM, KONDO Mitsumasa wrote:
Recently, a user who think system availability is important uses
synchronous replication cluster.
If your argument for why it's OK to ignore bounding crash recovery on
the master is that it's possible to failover to a standby, I don't think
that is a
Hi.I'm a little confused. 1.I have source code 9.2.4. version
fromhttp://www.postgresql.org/ftp/source/ 2.I want to add new alghoritm to
index nested loops join, merge join and hash join. I have Executor catalog in
src catalag containing nodeHash.c, nodeHasjoin.c, nodeMergejoin and
nodeNestloop
On 2013-07-19 01:27:41 -0400, Tom Lane wrote:
> Noah Misch writes:
> > To me, the major advantage of removing SnapshotNow is to force all
> > third-party code to reevaluate. But that could be just as well
> > achieved by renaming it to, say, SnapshotImmediate. If there are
> > borderline-legitim
>> *for example: for failback safe standby.*
>I think that introducing another configuration format is a pretty bad
>idea. While something new might not turn out to be as bad, we've seen
>how annoying a separate configuration format turned out for
>recovery.conf.
Its not totally different way of
On 2013-07-19 08:57:01 +0900, Inoue, Hiroshi wrote:
> >>I had the idea they were used for a client-side implementation of WHERE
> >>CURRENT OF. Perhaps that's dead code and could be removed entirely?
> >
> >It's been reported that ODBC still uses them.
>
> Though PostgreSQL's TID is similar to Or
On Fri, Jul 19, 2013 at 1:27 AM, Tom Lane wrote:
> Noah Misch writes:
>> To me, the major advantage of removing SnapshotNow is to force all
>> third-party code to reevaluate. But that could be just as well
>> achieved by renaming it to, say, SnapshotImmediate. If there are
>> borderline-legitim
Hi,
On 2013-07-19 08:23:25 -0400, Robert Haas wrote:
> On Fri, Jul 19, 2013 at 7:24 AM, Andres Freund wrote:
> > The changes here make it impossible to write a bgworker which properly
> > works in 9.3 and 9.4. Was that intended? If so, the commit message
> > should mention the compatibility break
On Fri, Jul 19, 2013 at 1:23 PM, Robert Haas wrote:
> On Fri, Jul 19, 2013 at 7:24 AM, Andres Freund wrote:
>> The changes here make it impossible to write a bgworker which properly
>> works in 9.3 and 9.4. Was that intended? If so, the commit message
>> should mention the compatibility break...
On Mon, Jul 15, 2013 at 1:41 PM, Jeff Davis wrote:
>> I'm of the opinion that we ought to extract the parts of the patch
>> that hold the VM pin for longer, review those separately, and if
>> they're good and desirable, apply them.
>
> I'm confused. My patch holds a VM page pinned for those cases
On Fri, Jul 19, 2013 at 7:24 AM, Andres Freund wrote:
> The changes here make it impossible to write a bgworker which properly
> works in 9.3 and 9.4. Was that intended? If so, the commit message
> should mention the compatibility break...
Yeah, sorry, I probably should have mentioned that. The
On 19 July 2013 04:09, Greg Smith wrote:
> On 7/18/13 11:03 PM, Stephen Frost wrote:
>>
>> Wasn't there a wiki page about this
>> feature which might also help? Bigger question- is it correct for the
>> latest version of the patch?
>
>
> https://wiki.postgresql.org/wiki/RLS has accumulated a lot
I have couple of questions.
On Wed, Jun 26, 2013 at 1:30 AM, Tom Lane wrote:
> I've been studying the bug reported at
>
> http://www.postgresql.org/message-id/20130617235236.GA1636@jeremyevans.local
> that the planner can do the wrong thing with queries like
>
> SELECT * FROM
> i LEFT JOIN LAT
On 18 July 2013 22:27, Stephen Frost wrote:
> Dean,
>
>
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Thanks! This is really looking quite good, but it's a bit late and I'm
>> going on vacation tomorrow, so I didn't quite want to commit it yet. :)
>
> Apologies on this taking a bit longer than
On 2013-07-19 14:54:16 +0530, Samrat Revagade wrote:
> I was going through the archives and there was a discussion about
> using ini file to setup
> replication.(http://www.postgresql.org/message-id/4c9876b4.9020...@enterprisedb.com).
> I think if we work on this proposal and separate out the repl
Please find updated hyperlinks:
> Below I have explained how to to use ini file for failback safe stadby setup:
> While discussing feature of fail-back safe standby
> (CAF8Q-Gy7xa60HwXc0MKajjkWFEbFDWTG=ggyu1kmt+s2xcq...@mail.gmail.com)
http://www.postgresql.org/message-id/CAF8Q-Gy7xa60HwXc0MKajjk
Hi,
I was going through the archives and there was a discussion about
using ini file to setup
replication.(http://www.postgresql.org/message-id/4c9876b4.9020...@enterprisedb.com).
I think if we work on this proposal and separate out the replication
setup from postgresql.conf file then we can prov
(2013/07/19 0:41), Greg Smith wrote:
On 7/18/13 11:04 AM, Robert Haas wrote:
On a system where fsync is sometimes very very slow, that
might result in the checkpoint overrunning its time budget - but SO
WHAT?
Checkpoints provide a boundary on recovery time. That is their only purpose.
You can
59 matches
Mail list logo
