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
On Mon, 2014-11-03 at 22:08 -0500, Tom Lane wrote:
spockFascinating./spock
:-)
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
On Wed, 2013-09-04 at 14:35 +, Robert Haas wrote:
On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane t...@sss.pgh.pa.us 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
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, as many
On Sun, 2011-10-09 at 11:58 -0400, Tom Lane wrote:
Marc Munro m...@bloodnok.com 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.
This means
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 made a
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 attention. The commercial RDBMS vendors could
learn a lot about customer support from this forum.
__
Marc Munro
signature.asc
Description
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
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
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
a
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
about
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?
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
that
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 br...@momjian.us wrote:
Would someone who understand pgcrypto please review this?
Marc Munro wrote:
I am attaching a patch to eliminate duplicate b64_encode
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 possibility
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
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
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() but this is a whole lot more complexity
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 runs his script that
static-izes things
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
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 actually this
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 of reviewing them that
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 accomplish.
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 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. Another transaction, T2, that attempts
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 that they are only checked
at end of transaction
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 record will be locked before its
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 fire in the same way but before
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
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 update
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 of delete, since the referencing table
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 from the same race for the record
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) record.
But at that point, you've
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
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 know what records the user will choose to update before
he
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's got
a pretty fundamental design flaw
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
Oracle's
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
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 module is loaded, the
configuration file
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.
What kind of details? By the time any server-side module
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
=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 and still get
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 there some reason this could not
be
done
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 soon
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,
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 code, it
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 identical
slony
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't given
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 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 a
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 rpms
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
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 people
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 --- the
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
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 preload_libraries hook
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 would Postgres ask the add-in how much
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 ShmemAlloc().
For Postgres 8.2 I would
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 aside for
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 bulletproof way if you
simply require
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
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:
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't
aware of the slop factor and was pleased that it just worked
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.
__
Marc Munro
On Mon
.
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 [EMAIL
as 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 pgman@candle.pha.pa.us
;
+ /*
+ * 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 I was unable to dynamically
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
72 matches
Mail list logo
