On Mar 1, 2011, at 10:54 PM, Tom Lane wrote:
> Jim Nasby writes:
>> Dumb question: Is this something that could be solved by having the
>> postmaster track this information in it's local memory and make it available
>> via a variable-sized IPC mechanism, such as a port or socket? That would
>>
Jim Nasby writes:
> Dumb question: Is this something that could be solved by having the
> postmaster track this information in it's local memory and make it available
> via a variable-sized IPC mechanism, such as a port or socket? That would
> eliminate the need to clean things up after a crash
On Feb 28, 2011, at 11:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland wrote:
>>> Remember that it's not only about saving shared memory, it's also
>>> about making sure that the snapshot reflects a state of the database
>>> that has actually exist
On Mon, Feb 28, 2011 at 6:38 PM, Robert Haas wrote:
>> Remember that it's not only about saving shared memory, it's also
>> about making sure that the snapshot reflects a state of the database
>> that has actually existed at some point in the past. Furthermore, we
>> can easily invalidate a snapsh
Robert Haas writes:
> On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland wrote:
>> Remember that it's not only about saving shared memory, it's also
>> about making sure that the snapshot reflects a state of the database
>> that has actually existed at some point in the past.
> But you can do all
On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland wrote:
> On Sun, Feb 27, 2011 at 3:04 PM, Heikki Linnakangas
> wrote:
>>> Why exactly, Heikki do you think the hash is more troublesome?
>> It just feels wrong to rely on cryptography just to save some shared memory.
>
> Remember that it's not only
On Sun, Feb 27, 2011 at 3:04 PM, Heikki Linnakangas
wrote:
>> Why exactly, Heikki do you think the hash is more troublesome?
> It just feels wrong to rely on cryptography just to save some shared memory.
Remember that it's not only about saving shared memory, it's also
about making sure that the
On 23.02.2011 03:00, Joachim Wieland wrote:
On Tue, Feb 22, 2011 at 3:34 PM, Heikki Linnakangas
wrote:
Yes, that's the point I was trying to make. I believe the idea of a hash was
that it takes less memory than storing the whole snapshot (and more
importantly, a fixed amount of memory per snap
On Tue, Feb 22, 2011 at 8:55 PM, Alvaro Herrera
wrote:
> The current discussion seems to have reached the same conclusion as the
> last one: the snapshot info shouldn't leave the server, but be
> transmitted internally -- the idea of the temp file seems prevalent.
> Here's an attempt at a detailed
The current discussion seems to have reached the same conclusion as the
last one: the snapshot info shouldn't leave the server, but be
transmitted internally -- the idea of the temp file seems prevalent.
Here's an attempt at a detailed spec:
By invoking pg_export_snapshot(), a transaction can exp
On Tue, Feb 22, 2011 at 8:00 PM, Joachim Wieland wrote:
> Both Tom and Robert voted quite explicitly against the
> store-in-shared-memory idea.
No, I voted *for* that approach.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
On Tue, Feb 22, 2011 at 3:34 PM, Heikki Linnakangas
wrote:
> On 22.02.2011 16:29, Robert Haas wrote:
>> On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
>> wrote:
>>> No, the hash is stored in shared memory. The hash of the garbage has to
>>> match.
>>
>> Oh. Well that's really silly. At th
On Tue, Feb 22, 2011 at 9:34 AM, Heikki Linnakangas
wrote:
>> Oh. Well that's really silly. At that point you might as well just
>> store the snapshot and an integer identifier in shared memory, right?
>
> Yes, that's the point I was trying to make. I believe the idea of a hash was
> that it tak
On 22.02.2011 16:29, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
wrote:
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
wrote:
Yes. It would be good to perform those sanity checks anyway.
I don't think it's good;
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
wrote:
> On 22.02.2011 15:52, Robert Haas wrote:
>>
>> On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
>> wrote:
>>>
>>> Yes. It would be good to perform those sanity checks anyway.
>>
>> I don't think it's good; I think it's absolutely nec
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
wrote:
Yes. It would be good to perform those sanity checks anyway.
I don't think it's good; I think it's absolutely necessary. Otherwise
someone can generate arbitrary garbage, hash it, and feed it
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
wrote:
> This is hashing, not encryption, there is no key. The point is that even if
> the attacker has the hash value and knows the algorithm, he can not
> construct *another* snapshot that has the same hash.
What good does that do us?
> Yes.
On 22.02.2011 14:24, Robert Haas wrote:
On Tue, Feb 22, 2011 at 1:59 AM, Heikki Linnakangas
wrote:
If you don't use a cryptographically secure hash, it's easy to construct a
snapshot with the same hash as an existing snapshot, with more or less
arbitrary contents.
And if you did use a crypto
On Tue, Feb 22, 2011 at 1:59 AM, Heikki Linnakangas
wrote:
> Really? The idea of the hash is to prevent you from importing arbitrary
> snapshots into the system, allowing only copying snapshots that are in use
> by another backend. The purpose of the hash is to make sure the snapshot the
> client
On 21.02.2011 21:33, Joachim Wieland wrote:
Hi,
On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
wrote:
What's the reason for this restriction?
if (databaseId != MyDatabaseId)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
On 19.02.2011 02:41, Joachim Wieland wrote:
On Fri, Feb 18, 2011 at 8:57 PM, Alvaro Herrera
wrote:
1. why are you using the expansible char array stuff instead of using
the StringInfo facility?
2. is md5 the most appropriate digest for this? If you need a
cryptographically secure hash, do we
Alvaro Herrera writes:
> That's true too. So let's discuss the syntax. Maybe
> START TRANSACTION SNAPSHOT '\xdeadbeef';
> This kind of extension seems ugly though; maybe we should consider
> START TRANSACTION (snapshot='\xdeadbeef');
> (like VACUUM, EXPLAIN and COPY) or some such?
Excerpts from Tom Lane's message of lun feb 21 21:00:19 -0300 2011:
> Alvaro Herrera writes:
> > Actually this seems rather difficult to do, because in order to invoke
> > the function that imports the snapshot, you have to call SELECT, which
> > acquires a snapshot beforehand. So when we actuall
Alvaro Herrera writes:
> Actually this seems rather difficult to do, because in order to invoke
> the function that imports the snapshot, you have to call SELECT, which
> acquires a snapshot beforehand. So when we actually import the
> passed-in snapshot, there's already a snapshot set. This is
Excerpts from Kevin Grittner's message of lun feb 21 18:39:26 -0300 2011:
> Alvaro Herrera wrote:
>
> > I think we need a safety net so that the new serializable isolation
> > code doesn't get upset if we change the base snapshot from under
> > it, but I haven't looked at that yet.
>
> Replaci
Alvaro Herrera wrote:
> I think we need a safety net so that the new serializable isolation
> code doesn't get upset if we change the base snapshot from under
> it, but I haven't looked at that yet.
Replacing the snapshot for a serializable transaction after it has
acquired its initial snapsho
Joachim Wieland writes:
> On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
> wrote:
>> Why are we using bytea as the output format instead of text?
> It is bytea because it should be thought of "just some data". It
> should be regarded more as a token than as text and should not be
> inspected/in
Hi,
On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
wrote:
> What's the reason for this restriction?
> if (databaseId != MyDatabaseId)
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> errmsg("cannot import snapsho
Excerpts from Joachim Wieland's message of dom ene 30 14:36:12 -0300 2011:
> On Thu, Jan 20, 2011 at 1:37 AM, Noah Misch wrote:
> >> > Is it valid to scribble directly on snapshots like this?
> >> I figured that previously executed code still has references pointing
> >> to the snapshots and so
A couple more questions:
What's the reason for this restriction?
if (databaseId != MyDatabaseId)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("cannot import snapshot from a different
database")));
Why ar
Excerpts from Tom Lane's message of sáb feb 19 21:26:42 -0300 2011:
> However ... IIRC, hash_any gives different results on bigendian and
> littleendian machines. I'm not sure if a predictable cross-platform
> result is important for this use? If you're hashing data containing
> native integers,
Peter Eisentraut writes:
> On fre, 2011-02-18 at 16:57 -0300, Alvaro Herrera wrote:
>> 2. is md5 the most appropriate digest for this? If you need a
>> cryptographically secure hash, do we need something stronger? If not,
>> why not just use hash_any?
> MD5 is probably more appropriate than has
On Sat, Feb 19, 2011 at 9:17 PM, Peter Eisentraut wrote:
> The only consideration against MD5 might be
> that it would make us look quite lame. We should probably provide
> builtin SHA1 and SHA2 functions for this and other reasons.
In this particular case however the checksum is never exposed t
On fre, 2011-02-18 at 16:57 -0300, Alvaro Herrera wrote:
> 2. is md5 the most appropriate digest for this? If you need a
> cryptographically secure hash, do we need something stronger? If not,
> why not just use hash_any?
MD5 is probably more appropriate than hash_any, because the latter is
opti
Excerpts from Joachim Wieland's message of vie feb 18 21:41:51 -0300 2011:
> On Fri, Feb 18, 2011 at 8:57 PM, Alvaro Herrera
> wrote:
> > 1. why are you using the expansible char array stuff instead of using
> > the StringInfo facility?
> >
> > 2. is md5 the most appropriate digest for this? If y
On Fri, Feb 18, 2011 at 8:57 PM, Alvaro Herrera
wrote:
> 1. why are you using the expansible char array stuff instead of using
> the StringInfo facility?
>
> 2. is md5 the most appropriate digest for this? If you need a
> cryptographically secure hash, do we need something stronger? If not,
> wh
I have two questions:
1. why are you using the expansible char array stuff instead of using
the StringInfo facility?
2. is md5 the most appropriate digest for this? If you need a
cryptographically secure hash, do we need something stronger? If not,
why not just use hash_any?
--
Álvaro Herr
Looking into this patch.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Sun, Jan 30, 2011 at 12:36:12PM -0500, Joachim Wieland wrote:
> Here is a new version of the patch incorporating most of Noah's
> suggestions. The patch now also adds documentation. Since I couldn't
> really find a suitable section to document the two new functions, I
> added a new one for now.
Here is a new version of the patch incorporating most of Noah's
suggestions. The patch now also adds documentation. Since I couldn't
really find a suitable section to document the two new functions, I
added a new one for now. Any better ideas where it should go?
On Thu, Jan 20, 2011 at 1:37 AM, No
On Wed, Jan 19, 2011 at 12:12:39AM -0500, Joachim Wieland wrote:
> Noah, thank you for this excellent review. I have taken over most
> (allmost all) of your suggestions (except for the documentation which
> is still missing). Please check the updated & attached patch for
> details.
Great. I do ge
Noah, thank you for this excellent review. I have taken over most
(allmost all) of your suggestions (except for the documentation which
is still missing). Please check the updated & attached patch for
details.
On Fri, Jan 14, 2011 at 10:13 PM, Noah Misch wrote:
> "" is a valid
Hello Joachim,
I'm reviewing this patch for CommitFest 2011-01.
On Fri, Jan 07, 2011 at 06:41:38AM -0500, Joachim Wieland wrote:
> On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland wrote:
> > What I am proposing now is the following:
> >
> > We return snapshot information as a chunk of data to th
On Jan7, 2011, at 12:41 , Joachim Wieland wrote:
> On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland wrote:
> These are the implementation details and restrictions of the patch:
>
> The exporting transaction
>
>- should be read-only (to discourage people from expecting that writes of
> t
On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland wrote:
> What I am proposing now is the following:
>
> We return snapshot information as a chunk of data to the client. At
> the same time however, we set a checksum in shared memory to protect
> against modification of the snapshot. A publishing ba
On Fri, Dec 31, 2010 at 8:28 AM, Alvaro Herrera
wrote:
> A backend can have any number of snapshots registered, and those don't
> allow GlobalXmin to advance. Consider an open cursor, for example.
> Even if the rest of the transaction is read committed, the snapshot
> registered by the open curso
Excerpts from Joachim Wieland's message of vie dic 31 00:15:57 -0300 2010:
> On Thu, Dec 30, 2010 at 9:40 AM, Alvaro Herrera
> wrote:
> >> Disadvantage of b: It doesn't allow a snapshot to be installed on a
> >> different server. It requires a serializable open transaction to hold
> >> the snapsho
On 12/30/2010 10:45 PM, Heikki Linnakangas wrote:
On 30.12.2010 16:49, Florian Pflug wrote:
On Dec30, 2010, at 13:31 , Joachim Wieland wrote:
We return snapshot information as a chunk of data to the client. At
the same time however, we set a checksum in shared memory to protect
against modifica
On Thu, Dec 30, 2010 at 9:49 AM, Florian Pflug wrote:
> On Dec30, 2010, at 13:31 , Joachim Wieland wrote:
>> We return snapshot information as a chunk of data to the client. At
>> the same time however, we set a checksum in shared memory to protect
>> against modification of the snapshot. A publis
On Thu, Dec 30, 2010 at 9:40 AM, Alvaro Herrera
wrote:
>> Disadvantage of b: It doesn't allow a snapshot to be installed on a
>> different server. It requires a serializable open transaction to hold
>> the snapshot.
>
> Why does it require a serializable transaction? You could simply
> register t
On 30.12.2010 16:49, Florian Pflug wrote:
On Dec30, 2010, at 13:31 , Joachim Wieland wrote:
We return snapshot information as a chunk of data to the client. At
the same time however, we set a checksum in shared memory to protect
against modification of the snapshot. A publishing backend can revo
On Dec30, 2010, at 13:31 , Joachim Wieland wrote:
> We return snapshot information as a chunk of data to the client. At
> the same time however, we set a checksum in shared memory to protect
> against modification of the snapshot. A publishing backend can revoke
> its snapshot by deleting the check
Excerpts from Joachim Wieland's message of jue dic 30 09:31:47 -0300 2010:
> Advantage of b: No validation necessary, as soon as the transaction
> that publishes the snapshot loses that snapshot, it will also revoke
> the snapshot information (either by removing a temp file or deleting
> it from s
53 matches
Mail list logo
