On Mon, 2015-08-31 at 22:21 +, Robert Haas wrote:
> It seems to me that sharding consists of (1) breaking your data set up
> into shards, (2) possibly replicating some of those shards onto
> multiple machines, and then (3) being able to access the remote data
> from local queries. [...]
I be
On Mon, 2014-11-03 at 22:08 -0500, Tom Lane wrote:
> Fascinating.
:-)
> I believe what is happening is:
[ . . . ]
> > This is not mission-critical for me but I'd be grateful for suggestions for
> > work-arounds.
>
> I don't see any workaround that's much easier than fixing the bug.
> But what'
On Wed, 2013-09-04 at 14:35 +, Robert Haas wrote:
>
> On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane wrote:
> > I think it's entirely sensible to question whether we should reject
> (not
> > "hold up") RLS if it has major covert-channel problems.
>
> We've already had this argument before, about
On Wed, 2012-02-22 at 12:44 -0400, Andrew Dunstan wrote:
> Returning to the original point, I've come to the conclusion that
> "pure"
> isn't the right way to go. The trouble with "leakproof" is that it
> doesn't point to what it is that's not leaking, which is information
> rather than memory,
On Sun, 2011-10-09 at 11:58 -0400, Tom Lane wrote:
> Marc Munro writes:
> > It seems that in order to create an object in a given schema, I must
> > have been granted create privilege on the schema. But in order to drop
> > that object I require usage privilege.
>
>
It seems that in order to create an object in a given schema, I must
have been granted create privilege on the schema. But in order to drop
that object I require usage privilege.
This means that with the right privilege settings I can create objects
that I cannot subsequently drop, or can drop
On Sat, 2011-07-23 at 11:08 -0400, Tom Lane wrote:
> > If I drop the extension veil_demo, I am left with the veil_demo version
> > of veil_init().
>
> > Is this a feature or a bug? Is there a work-around?
>
> Hmm. I don't think we have any code in there to prohibit the same
> object from being
he postgres API goes, exposing a function that would validate a dayname
returning a day number would resolve all of this for considerably less
complexity. Also throwing an error in the to_date function for
unexpectedly mixed input formats seems quite reasonable.
Thanks for your time and atten
On Fri, 2010-06-04 at 10:33 -0400, Tom Lane wrote:
> Hmm ... that's a mighty interesting example, because it shows that any
> well-meaning change in error handling might render seemingly-unrelated
> functions "unsafe". And we're certainly not going to make error
> messages stop showing relevant in
On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
wrote:
> [ . . . ]
>
> In my current idea, when a qual-node that contains FuncExpr tries to
> reference a part of relations within a security view, its referencing
> relations will be expanded to whole of the security view at
> d
On Mon, 2010-03-01 at 16:12 -0400, pgsql-hackers-ow...@postgresql.org
wrote:
> . . .
> However there is a concern with max_standby_age. If you set it to,
> say, 300s. Then run a 300s query on the slave which causes the slave
> to fall 299s behind. Now you start a new query on the slave -- it gets
Just to intoduce myself, I'm Marc Munro the developer of Veil, a
postgres add-in that allows you to implement virtual private databases
using views.
The problem we are discussing here is the existence of covert or
side-channels being available from functions that can leak information
abou
On Thu, 2009-04-23 at 16:08 -0300, pgsql-hackers-ow...@postgresql.org
wrote:
> On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote:
>
> [...]
>
> > It's possible that this could be accomplished by something like
> Veil,
>
> Veil? Care to share an URL?
http://veil.projects.postgresql.org/
On Mon, 2009-01-12 at 14:35 -0400, Jeff Davis wrote:
> ate: Mon, 12 Jan 2009 09:52:00 -0800
> On Mon, 2009-01-12 at 08:32 -0500, Tom Lane wrote:
> > That code has been working like this for eight or ten years now and
> this
> > is the first complaint, so taking away functionality on the grounds
>
Oops, forgot to cc my reply to hackers:
On Thu, 2008-12-18 at 01:49 +0200, Marko Kreen wrote:
> On 12/16/08, Bruce Momjian wrote:
> > Would someone who understand pgcrypto please review this?
>
> > Marc Munro wrote:
> > > I am attaching a patch to eliminate dupl
On Mon, 2008-07-21 at 17:03 -0300, Tom Lane wrote:
> [. . .] I think it
> would be a good idea to be open to reviewing pgfoundry code with the
> same standards we'd use if we were going to integrate it. Perhaps
> commitfest is not the right venue for that, though, if only because
> of the possibi
I am attaching a patch to eliminate duplicate b64_encode and decode
functions from pgcrypto, and to expose those functions for use by
add-ins (I want to use them in Veil).
The patch was made against CVS head today. It compiles and tests
successfully. Though I was unable to run pgrypto regression
On Thu, 2008-06-12 at 19:10 -0400, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > So, would there be any chance of redefining the base64 functions in
> > encode.c as extern to eliminate this redundancy?
>
> It'd only last until the next time Bruce ru
On Thu, 2008-06-12 at 19:07 -0400, Andrew Dunstan wrote:
> Marc Munro wrote:
> > I require base64 or some similar encoding scheme from a C language. . .
> >
> > I know I could call these functions indirectly by calling binary_ecncode
> > through DirectFunctionCalln() b
I require base64 or some similar encoding scheme from a C language
extension and need it to be as fast as reasonably possible. In
src/backend/utils/adt/encode.c there are functions b64_encode and
b64_decode which would be ideal but these are defined static and so are
not available to my code.
I
In a digest for Tue, 2008-05-06 at 22:57 -0300, Tom Lane wrote:
...[discussion of SE-PostgreSQL patch deleted]...
> (And of course the next question after that is why we should want to
> depend on SELinux at all, rather than implementing row filtering
> in the framework of SQL permissions...)
I wo
On Fri, 2007-21-12 at 18:05 -0400, Andrew Sullivan <[EMAIL PROTECTED]>
wrote:
> > > 2. Protect the content of a field from _some_ users on a given
> system,
> >
> > I would argue that (2) is reasonably well served today by setting up
> > separate databases for separate users.
>
> I thought act
On Wed, 2007-02-05 at 08:27 -0400, Andrew Dunstan wrote:
>
> Naz Gassiep wrote:
> > Andrew Dunstan wrote:
> >
> >> Naz Gassiep wrote:
> >>
> >>> I believe the suggestion was to have an automated process that only ran
> >>> on known, sane patches.
> >>>
> >> How do we know in advance
On Tue, 2007-01-05 at 02:54 +0100, Gregory Stark wrote:
> "Naz Gassiep" <[EMAIL PROTECTED]> writes:
>
> > Even if the patch inventory wasn't kept right up to date, this system
> > could potentially help many regression issues or bugs to surface sooner,
>
> I just don't understand what this would
On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
> Date: Mon, 30 Apr 2007 09:18:36 +0100
> From: Heikki Linnakangas <[EMAIL PROTECTED]>
> To: Tom Lane <[EMAIL PROTECTED]>
> Cc: Dave Page <[EMAIL PROTECTED]>, Simon Riggs
> <[EMAIL PROTECTED]>,
> Bruce Momjian <[EMAIL PROTECTED]>,
On Tue, 2007-13-02 at 11:38 -0500, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > From an application developer's standpoint there are few options, none
> > of them ideal:
>
> How about
>
> 4) Make all the FK constraints deferred, so
On Mon, 2007-12-02 at 00:10 -0500, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > Consider a table C containing 2 child records C1 and C2, of parent P.
> > If transaction T1 updates C1 and C2, the locking order of the the
> > records will be C1, P, C2. An
On Sun, 2007-11-02 at 12:21 -0600, Jim C. Nasby wrote:
> On Thu, Feb 08, 2007 at 08:47:42AM -0800, Marc Munro wrote:
> > One of the causes of deadlocks in Postgres is that its referential
> > integrity triggers can take locks in inconsistent orders. Generally a
> > child
On Thu, 2007-08-02 at 12:24 -0800, Stephan Szabo wrote:
> On Thu, 8 Feb 2007, Marc Munro wrote:
>
> > I don't think this does stop the second from continuing before the
> > first. What will stop it, is the eventual lock that is taken on the
> > child (triggering) r
On Thu, 2007-08-02 at 14:33 -0500, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > Yes in this case, T1 must abort because the record it was going to
> > update has disappeared from underneath it. I don't see how this is
> > significantly different f
On Thu, 2007-08-02 at 10:06 -0800, Stephan Szabo wrote:
> On Thu, 8 Feb 2007, Marc Munro wrote:
. . .
> >
> > That other transaction, T1, would have run the same RI triggers and so
> > would have the same parent records locked.
>
> That's not true in the case
On Thu, 2007-08-02 at 18:06 +0100, Csaba Nagy wrote:
> The problem is that eliminating the deadlock is still not the complete
> cake... the interlocking still remains, possibly leading to degraded
> performance on high contention on very common parent rows. The real
> solution would be when an upd
I am going to restate my earlier proposal, to clarify it and in the hope
of stimulating more discussion.
One of the causes of deadlocks in Postgres is that its referential
integrity triggers can take locks in inconsistent orders. Generally a
child record will be locked before its parent, but not
Oops, forgot to include pgsql-hackers when I responded to this the first
time.
On Tue, 2007-06-02 at 20:53 -0500, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > The RI triggers currently fire when a record is updated. Under my
> > proposal they would fir
On Tue, 2007-06-02 at 23:47 +, Gregory Stark wrote:
> "Marc Munro" <[EMAIL PROTECTED]> writes:
>
> > Proposal 1: Alter the way RI triggers fire, so that they complete before
> > locking the row against which they fire.
>
> It's kind of hard to kno
Simon Riggs started this thread with the question:
. . .
Why do we need a SHARE lock at all, on the **referenc(ed)** table?
. . .
The root problem addressed by this thread seems to be that using share
locks in this way increases the likelihood of deadlock, and causes
blocking when no blocki
On Sat, 2006-10-14 at 14:55 -0400, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > The attached patch provides add-ins with the means to register for
> > shared memory and LWLocks.
>
> I finally got around to reviewing this patch, and realized that it&#
On Mon, 2006-10-02 at 12:02 -0300, Shaunak Godbole wrote:
> Hi,
>
> We are trying to introduce access control. For this we have to rewrite
> the
> input query by replacing each relation by its corresponding authorized
> view.
I assume from this that you are trying to implement something like
Orac
On Mon, 2006-07-24 at 15:17 -0400, Tom Lane wrote:
> No, being able to do that is exactly the point of the custom-GUC
> mechanism.
Excellent. I shall study this and hope to bother you no further :-)
Thanks.
__
Marc
signature.asc
Description: This is a digitally signed message part
On Mon, 2006-07-24 at 14:44 -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Marc Munro wrote:
> >> I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
> >> configuration details from a configuration file.
>
> &
On Mon, 2006-07-24 at 20:31 +0200, Peter Eisentraut wrote:
> Marc Munro wrote:
> > I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
> > configuration details from a configuration file.
>
> What kind of details? By the time any server-side
I want Veil (http://pgfoundry.org/projects/veil/) to be able to read
configuration details from a configuration file. Rather than implement
my own config file parser, I'd like to be able to re-use the parser
defined in guc-file.l
If this is not contentious, I will submit a patch to make the parse
=600,tcp,noac
Jumbo frames 8192 MTU.
All postgres data and logs are stored on the netapp.
All tests results were reproduced with postgres 8.0.8
__
Marc
On Fri, 2006-06-30 at 23:20 -0400, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > We tried all of these suggestions an
On Thu, 2006-07-13 at 01:13 -0300, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > ... A better solution from my point of view would be
> > to simply move the call to process_preload_libraries to a point
> after
> > shared memory has been set up. Is th
On Wed, 2006-07-12 at 02:18 -0300, I wrote:
> I am trying to create an initialisation function that is called using
> the preload_libraries option.
>
> The purpose of this is to set up shared memory for Veil, independant
> of postgres' own shared memory. Simple init functions work fine, but
> as
I am trying to create an initialisation function that is called using
the preload_libraries option.
The purpose of this is to set up shared memory for Veil, independant of
postgres' own shared memory. Simple init functions work fine, but as
soon as I place calls to ShemAlloc, or LWLockAssign, th
On Thu, 2006-06-29 at 21:47 -0400, Tom Lane wrote:
> One easy thing that would be worth trying is to build with
> --enable-cassert and see if any Asserts get provoked during the
> A couple other things to try, given that you can provoke the failure
> fairly easily:
> . . .
> 1. In studying the cod
On Thu, 2006-06-29 at 21:59 -0400, Tom Lane wrote:
> [ back to the start of the thread... ]
>
> BTW, a couple of thoughts here:
>
> * If my theory about the low-level cause is correct, then reindexing
> sl_log_1 would make the "duplicate key" errors go away, but nonetheless
> you'd have lost data
On Thu, 2006-06-29 at 21:47 -0400, Tom Lane wrote:
> One easy thing that would be worth trying is to build with
> --enable-cassert and see if any Asserts get provoked during the
> failure case. I don't have a lot of hope for that, but it's
> something that would require only machine time not peopl
On Thu, 2006-06-29 at 19:59 -0400, Tom Lane wrote:
> Ummm ... you did restart the server? "select version();" would be
> the definitive test.
Can't say I blame you for the skepticism but I have confirmed it again.
test=# select version();
version
Ooops: forgot to cc this to the list.
On Thu, 2006-06-29 at 19:27 -0400, Tom Lane wrote:
> Are you *certain* this slave isn't running 8.0.2 or older? If you can
> verify that, then I guess we need to look for another mechanism that
> could cause the same kind of thing.
Certain. We built new rpm
On Fri, 2006-06-30 at 00:37 +0300, Hannu Krosing wrote:
> Marc: do you have triggers on some replicated tables ?
>
We have a non-slony trigger on only 2 tables, neither of them involved
in this transaction. We certainly have no circular trigger structures.
> I remember having some corruption in
We have reproduced the problem again. This time it looks like vacuum is
not part of the picture. From the provider's log:
2006-06-29 14:02:41 CST DEBUG2 cleanupThread: 101.057 seconds for vacuuming
And from the subscriber's:
2006-06-29 13:00:43 PDT ERROR remoteWorkerThread_1: "insert into
"
On Thu, 2006-06-29 at 12:11 -0400, Tom Lane wrote:
> OK, so it's not an already-known problem.
>
> > We were able to corrupt the index within 90 minutes of starting up our
> > cluster. A slony-induced vacuum was under way on the provider at the
> > time the subscriber failed.
>
> You still haven
vider at the
time the subscriber failed.
What can we do to help identify the cause of this? We have a test
system that seems able to reproduce this fairly easily.
__
Marc
On Wed, 2006-06-28 at 09:28 -0700, Marc Munro wrote:
> We have now experienced index corruption on two separate but i
We have now experienced index corruption on two separate but identical
slony clusters. In each case the slony subscriber failed after
attempting to insert a duplicate record. In each case reindexing the
sl_log_1 table on the provider fixed the problem.
The latest occurrence was on our production
On Fri, 2006-05-19 at 12:35 -0700, Marc Munro wrote:
> On Fri, 2006-05-19 at 14:44 -0400, Tom Lane wrote:
> > This could all be solved in a cleaner, more bulletproof way if you
> > simply require such add-ins to be preloaded into the postmaster process
> > using the existing p
On Fri, 2006-05-19 at 14:44 -0400, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > My proposal makes it possible for properly configured add-ins to have a
> > guaranteed amount of shared memory available.
>
> This could all be solved in a cleaner, more bull
On Fri, 2006-05-19 at 10:05 -0700, Josh Berkus wrote:
> Marc,
>
> > The add-in would not "know" how much had been allocated to it, but could
> > be told through it's own config file. I envisage something like:
> >
> > in postgresql.conf
> >
> > # add_in_shmem = 0# Amount of shared mem to set
On Fri, 2006-05-19 at 13:41 -0300, [EMAIL PROTECTED]
wrote:
> Marc Munro wrote:
> > Veil http://pgfoundry.org/projects/veil is currently not a very good
> > Postgres citizen. It steals what little shared memory it needs from
> > postgres' shared memory using ShmemAllo
On Fri, 2006-05-19 at 13:41 -0300, [EMAIL PROTECTED]
wrote:
> On Thu, 2006-05-18 at 17:39 -0700, Marc Munro wrote:
>
> > For Postgres 8.2 I would like Veil to be a better citizen and use
> only
> > what shared memory has been reserved for postgres add-ins.
>
> How wo
Veil http://pgfoundry.org/projects/veil is currently not a very good
Postgres citizen. It steals what little shared memory it needs from
postgres' shared memory using ShmemAlloc().
For Postgres 8.2 I would like Veil to be a better citizen and use only
what shared memory has been reserved for post
You could do this using Veil, http://pgfoundry.org/projects/veil/, or
something like it. A Veil access function,
http://veil.projects.postgresql.org/curdocs/overview-page.html, could be
used to record every row returned within a query to the user that
requested it. Note that this operates at the
I wonder if this idea might be taken a little further, to allow
read-only tablespaces?
This would allow old partitions in very large databases to be kept on
read-only media, and would allow normal backups to ignore this
unchanging set of data.
It also allows for certain specific optimisations for
How about representing null array elements with a special-case cast-like
null? Something like {::null}
__
Marc
On Tue, 2005-11-08 at 23:30 -0400, [EMAIL PROTECTED]
wrote:
> Date: Tue, 08 Nov 2005 19:21:34 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: pgsql-hackers@postgreSQL.org
> Subject: Re
Last week I managed to lock-up and then crash a development database.
I'm going to try to reproduce it today and would like to know what I can
do to further investigate the problem.
I am running Linux 2.6.9-11.ELsmp X86_64 on a Quad Dual-Core Opteron
I have the following postgres RPMs installed:
an allocating its own shared memory segment?
>
> -------
>
> Marc Munro wrote:
> -- Start of PGP signed section.
> > Tom,
> > My project, Veil, steals some of this shared memory for itself. I wan'
allocate shmem space for add-ons
- Have add-ons register themselves and provide hooks for sizing and
initial space allocation
- Let add-ons race with the lockmgr for the slop (ie leave as it is)
Thoughts?
I would be happy to work on this and provide whatever patches are
necessary.
Thanks.
__
Mar
tgres.
Maybe the correct thing to do is only allow 1 user-defined LWLock for
now, and place a comment with the definition of NUM_USER_DEFINED_LWLOCKS
to warn that locking should be implemented if more than 1 is ever
needed.
__
Marc
On Fri, 2005-10-07 at 16:21 -0400, Tom Lane wrote:
> Marc Munro
I
can see, this is safe in 7.4, and otherwise unused in 8.0.
On the use of LWLockAssign():can anyone tell me if I should protect the
call using the ShmemLock spinlock?
__
Marc Munro
On Fri, 2005-10-07 at 00:10 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
;
+ /*
+ * Allocate a few LWLocks for user-defined functions.
+ */
+ #define NUM_USER_DEFINED_LWLOCKS 4
typedef enum LWLockMode
{
--cut---
__
Marc Munro
On Tue, 2005-10-04 at 22:51 -0400, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > Since
arbitrarily overloaded the
use of existing LWLocks. When the flames die down perhaps we can
discuss making a small number (one would be enough for me) of LWLocks
available.
Thank you.
__
Marc Munro
signature.asc
Description: This is a digitally signed message part
Kevin,
Hi. I was looking into PITR for PostgreSQL myself about a year back but
life intervened. I am an Oracle DBA so may be able to help you with an
understanding of how Oracle does this.
You wrote:
> Oracle has something they call "rollback segments" which I assume are
> separate bits of data
73 matches
Mail list logo
