On Mar 1, 2011, at 10:54 PM, Tom Lane wrote:
Jim Nasby j...@nasby.net 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
On Feb 28, 2011, at 11:59 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland j...@mcknight.de 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
Jim Nasby j...@nasby.net 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
On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland j...@mcknight.de wrote:
On Sun, Feb 27, 2011 at 3:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Why exactly, Heikki do you think the hash is more troublesome?
It just feels wrong to rely on cryptography just to save some
Robert Haas robertmh...@gmail.com writes:
On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland j...@mcknight.de 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
On Mon, Feb 28, 2011 at 6:38 PM, Robert Haas robertmh...@gmail.com 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
On 23.02.2011 03:00, Joachim Wieland wrote:
On Tue, Feb 22, 2011 at 3:34 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Sun, Feb 27, 2011 at 3:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Feb 22, 2011 at 1:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 22.02.2011 14:24, Robert Haas wrote:
On Tue, Feb 22, 2011 at 1:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yes. It would be good to perform those sanity checks anyway.
On 22.02.2011 16:29, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.comwrote:
Yes. It would be
On Tue, Feb 22, 2011 at 9:34 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Feb 22, 2011 at 3:34 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.02.2011 16:29, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
No, the hash is stored in shared memory. The hash of the
On Tue, Feb 22, 2011 at 8:00 PM, Joachim Wieland j...@mcknight.de 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
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
On Tue, Feb 22, 2011 at 8:55 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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 are
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 n...@leadboat.com wrote:
Is it valid to scribble directly on snapshots like this?
I figured that previously executed code still has references pointing
to the snapshots
Hi,
On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
What's the reason for this restriction?
if (databaseId != MyDatabaseId)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
Joachim Wieland j...@mcknight.de writes:
On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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 snapshot
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.
Replacing the
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Tom Lane's message of lun feb 21 21:00:19 -0300 2011:
Alvaro Herrera alvhe...@commandprompt.com 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.
Alvaro Herrera alvhe...@commandprompt.com 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
On 19.02.2011 02:41, Joachim Wieland wrote:
On Fri, Feb 18, 2011 at 8:57 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On 21.02.2011 21:33, Joachim Wieland wrote:
Hi,
On Mon, Feb 21, 2011 at 4:56 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
What's the reason for this restriction?
if (databaseId != MyDatabaseId)
ereport(ERROR,
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
On Sat, Feb 19, 2011 at 9:17 PM, Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
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,
Looking into this patch.
--
Álvaro Herrera alvhe...@commandprompt.com
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:
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
On Fri, Feb 18, 2011 at 8:57 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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
alvhe...@commandprompt.com wrote:
1. why are you using the expansible char array stuff instead of using
the StringInfo facility?
2. is md5 the most appropriate
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,
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. Any
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 get an
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 n...@leadboat.com wrote:
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 j...@mcknight.de wrote:
What I am proposing now is the following:
We return snapshot information as a chunk of
On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland j...@mcknight.de 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
On Jan7, 2011, at 12:41 , Joachim Wieland wrote:
On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland j...@mcknight.de 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
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
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
alvhe...@commandprompt.com wrote:
Disadvantage of b: It doesn't allow a snapshot to be installed on a
different server. It requires a serializable open transaction to
On Fri, Dec 31, 2010 at 8:28 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
The snapshot synchronization discussion from the parallel pg_dump
patch somehow ended without a clear way to go forward.
Let me sum up what has been brought up and propose a short- and
longterm solution.
Summary:
Passing snapshot sync information can be done either:
a) by returning complete
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
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 checksum
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
On Thu, Dec 30, 2010 at 9:40 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Thu, Dec 30, 2010 at 9:49 AM, Florian Pflug f...@phlo.org 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
54 matches
Mail list logo
