On Fri, Dec 31, 2010 at 8:48 AM, Peter Eisentraut wrote:
> On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
>> No, quite the opposite. With the other approach, you needed:
>>
>> constraints cannot be used on views
>> constraints cannot be used on composite types
>> constraints cannot be used
On Dec 31, 2010, at 7:34 AM, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of jue dic 30 23:02:04 -0300 2010:
>> Alvaro Herrera writes:
>>> I was thinking that we could have two different ANALYZE modes, one
>>> "full" and one "incremental"; autovacuum could be modified to use one or
>>>
On 12/31/10 4:40 AM, Robert Haas wrote:
> Someone may have proposed this before, but one way of getting standby
> naming "for free" would be to make the standby names the same as the
> roles used to log in, rather than adding a separate parameter. We
> could just recommend to people that they use
On tor, 2010-12-23 at 14:41 +0100, Jan Urbański wrote:
> It does some architectural changes to PL/Python that make it easier to
> implement other features, like for instance a validator function. The
> full list of changes in the patch is:
I would review this and the following patches, but I'd rea
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Yes, that was my calculus too. I realized that we create session ids by
> > merging the process id and backend start time, so I went ahead and added
> > the postmaster start time epoch to the postmaster.pid file. While there
> > is no way to pass ba
On 31.12.2010 13:40, Heikki Linnakangas wrote:
Sounds good.
I still don't like the synchronous_standbys='' and
synchronous_replication=on combination, though. IMHO that still
amounts to letting the standby control the behavior on master, and it
makes it impossible to temporarily add an async
Hi. Will be useful to add a column with timestamp of the revision and
a comment can you do it? not today in order that your friends dont
kill you ..
--
Sent from my mobile device
pasman
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
2010/12/31 Simon Riggs
> Please call it something other than "snapshot". There's already about 3
> tools called something similar and a couple of different meanings of the
> term in the world of Postgres.
>
>
Thanks, good point.
Renamed to fsnapshot.
Commit.
--
Best regards,
Joel Jacobson
Glue
On Fri, 2010-12-31 at 14:40 +0200, Heikki Linnakangas wrote:
> On 31.12.2010 13:48, Simon Riggs wrote:
> >
> > I see significant real-world issues with configuring replication using
> > multiple named servers, as described in the link above:
>
> All of these points only apply to specifying *multip
On Fri, 2010-12-31 at 14:00 +0100, Joel Jacobson wrote:
> This is the first alpha release of a new hopefully quite interesting
> little tool, named "snapshot".
Please call it something other than "snapshot". There's already about 3
tools called something similar and a couple of different meanings
On Dec 31, 2010, at 10:15 AM, Joel Jacobson wrote:
> 2010/12/31 David E. Wheeler
> This looks awesome, Joel! One question: Why the dependence on pg_crypto? If
> it's just for SHA1 support, and you're just using it to to create hashes of
> function bodies, I suspect that you could also use the c
2010/12/31 David E. Wheeler
> This looks awesome, Joel! One question: Why the dependence on pg_crypto? If
> it's just for SHA1 support, and you're just using it to to create hashes of
> function bodies, I suspect that you could also use the core MD5() function,
> yes?
>
Thanks for fast reply. My
On Dec 31, 2010, at 5:00 AM, Joel Jacobson wrote:
> Happy new year fellow pgsql-hackers!
>
> This is the first alpha release of a new hopefully quite interesting little
> tool, named "snapshot".
>
> Feedback welcomed.
This looks awesome, Joel! One question: Why the dependence on pg_crypto? If
On Fri, 2010-12-31 at 07:33 -0500, Aidan Van Dyk wrote:
> On Fri, Dec 31, 2010 at 5:26 AM, Simon Riggs wrote:
>
> > Your picture above is a common misconception. I will add something to
> > the docs to explain this.
>
> > 2. "sync" does not guarantee that the updates to the standbys are in any
>
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
On Thu, Dec 30, 2010 at 15:54, Peter Eisentraut wrote:
> On ons, 2010-12-29 at 11:09 +0100, Magnus Hagander wrote:
>> I've applied this version (with some minor typo-fixes).
>
> This page is now somewhat invalidated:
>
> http://developer.postgresql.org/pgdocs/postgres/role-attributes.html
Hmm. So
On Fri, Dec 31, 2010 at 8:48 AM, Stefan Kaltenbrunner
wrote:
>> What's weird about using the role name? That's our standard way of
>> distinguishing between two or more users. Why invent something new?
>
> wel a user is not a host/server for me - given there is no real benefit from
> using disti
On tor, 2010-12-30 at 11:49 -0500, Tom Lane wrote:
> ISTM there are four things we might potentially want to state in the
> error message: the feature/operation you tried to apply, the name of
> the object you tried to apply it to, the type of that object, and the
> set of object types that the fea
On 12/31/2010 02:39 PM, Robert Haas wrote:
On Fri, Dec 31, 2010 at 7:57 AM, Heikki Linnakangas
wrote:
On 31.12.2010 14:40, Robert Haas wrote:
Someone may have proposed this before, but one way of getting standby
naming "for free" would be to make the standby names the same as the
roles used
On tor, 2010-12-30 at 11:03 -0500, Robert Haas wrote:
> No, quite the opposite. With the other approach, you needed:
>
> constraints cannot be used on views
> constraints cannot be used on composite types
> constraints cannot be used on TOAST tables
> constraints cannot be used on indexes
> const
On Fri, Dec 31, 2010 at 7:57 AM, Heikki Linnakangas
wrote:
> On 31.12.2010 14:40, Robert Haas wrote:
>>
>> Someone may have proposed this before, but one way of getting standby
>> naming "for free" would be to make the standby names the same as the
>> roles used to log in, rather than adding a sep
On Fri, Dec 31, 2010 at 8:10 AM, Alvaro Herrera
wrote:
>> I think for now what I
>> had better do is try to get this SQL/MED patch finished up by
>> soldiering through this mess rather than trying to fix it. I think
>> it's going to be kind of ugly, but we haven't got another plan then
>> we're j
Excerpts from Tom Lane's message of jue dic 30 23:02:04 -0300 2010:
> Alvaro Herrera writes:
> > I was thinking that we could have two different ANALYZE modes, one
> > "full" and one "incremental"; autovacuum could be modified to use one or
> > the other depending on how many changes there are (of
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
Excerpts from Robert Haas's message of vie dic 31 02:07:18 -0300 2010:
> I think that's true in some cases but not all. The system-generated
> attribute names thing actually applies in several cases, and I think
> it's pretty cut-and-dried. When you get into something like which
> kinds of relat
Happy new year fellow pgsql-hackers!
This is the first alpha release of a new hopefully quite interesting little
tool, named "snapshot".
Feedback welcomed.
--
Best regards,
Joel Jacobson
Glue Finance
URL
https://github.com/gluefinance/snapshot
DESCRIPTION
Take a snapshot or rollback al
On 31.12.2010 14:40, Robert Haas wrote:
Someone may have proposed this before, but one way of getting standby
naming "for free" would be to make the standby names the same as the
roles used to log in, rather than adding a separate parameter. We
could just recommend to people that they use a sepa
On Fri, Dec 31, 2010 at 13:10, Robert Haas wrote:
> On Fri, Dec 31, 2010 at 4:58 AM, Magnus Hagander wrote:
>> On Fri, Dec 31, 2010 at 03:04, Tom Lane wrote:
>>> Jeff Davis writes:
Personally, my utility for the old repo is not much (if it was anything
important, I wouldn't have relie
On 31.12.2010 13:48, Simon Riggs wrote:
On Fri, 2010-12-31 at 12:06 +0200, Heikki Linnakangas wrote:
Regarding the rest of the proposal, I would still prefer the UI
discussed here:
http://archives.postgresql.org/message-id/4cae030a.2060...@enterprisedb.com
It ought to be the same amount of wo
On Fri, Dec 31, 2010 at 6:48 AM, Simon Riggs wrote:
> I suppose we might regard the feature set I am proposing as being the
> same as making synchronous_standbys a USERSET parameter, and allowing
> just two options:
> "none" - allowing the user to specify async if they wish it
> "*" - allowing peo
On Fri, Dec 31, 2010 at 5:26 AM, Simon Riggs wrote:
> Your picture above is a common misconception. I will add something to
> the docs to explain this.
> 2. "sync" does not guarantee that the updates to the standbys are in any
> way coordinated. You can run a query on one standby and get one ans
On Fri, Dec 31, 2010 at 4:58 AM, Magnus Hagander wrote:
> On Fri, Dec 31, 2010 at 03:04, Tom Lane wrote:
>> Jeff Davis writes:
>>> Personally, my utility for the old repo is not much (if it was anything
>>> important, I wouldn't have relied on the unofficial repo). But we should
>>> probably giv
On Thu, 2010-12-30 at 20:26 -0700, Joshua Tolley wrote:
> 2) initiate fsync on the primary first
> >- In this case, the slave is always slightly behind. If if your
> > primary falls over, you don't give commit messages to the clients,
> but
> > if it recovers, it might have committed data, and
On Fri, 2010-12-31 at 12:06 +0200, Heikki Linnakangas wrote:
> Regarding the rest of the proposal, I would still prefer the UI
> discussed here:
>
> http://archives.postgresql.org/message-id/4cae030a.2060...@enterprisedb.com
>
> It ought to be the same amount of work to implement, and provides
On Fri, 2010-12-31 at 12:06 +0200, Heikki Linnakangas wrote:
> On 31.12.2010 09:50, Hannu Krosing wrote:
> > On 30.12.2010 22:27, Robert Haas wrote:
> >> On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs
> >> wrote:
> >>> synchronous_replication (boolean)
> >>> Specifies whether transaction commit will
On 12/31/2010 11:06 AM, Heikki Linnakangas wrote:
On 31.12.2010 09:50, Hannu Krosing wrote:
On 30.12.2010 22:27, Robert Haas wrote:
On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs
wrote:
synchronous_replication (boolean)
Specifies whether transaction commit will wait for WAL records
to be replica
On Fri, 2010-12-31 at 09:27 +0100, Stefan Kaltenbrunner wrote:
> Maybe it has been discussed but I still don't see way it makes any
> sense. If I declare a standby a sync standby I better want it sync - not
> "maybe sync". consider the case of a 1 master and two identical sync
> standbys - one
On 31.12.2010 09:50, Hannu Krosing wrote:
On 30.12.2010 22:27, Robert Haas wrote:
On Thu, Dec 30, 2010 at 2:04 PM, Simon Riggs
wrote:
synchronous_replication (boolean)
Specifies whether transaction commit will wait for WAL records
to be replicated before the command returns a "success"
indicati
On Fri, Dec 31, 2010 at 03:04, Tom Lane wrote:
> Jeff Davis writes:
>> Personally, my utility for the old repo is not much (if it was anything
>> important, I wouldn't have relied on the unofficial repo). But we should
>> probably give a little bit of warning for folks that might want to
>> rebas
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 12/30/2010 10:23 PM, Simon Riggs wrote:
On Thu, 2010-12-30 at 21:42 +0100, Stefan Kaltenbrunner wrote:
Synchronous replication offers the ability to guarantee that all changes
made by a transaction have been transferred to at least one remote
standby server. This is an extension to the stand
On 12/30/2010 10:27 PM, Simon Riggs wrote:
On Thu, 2010-12-30 at 22:08 +0100, Stefan Kaltenbrunner wrote:
On 12/30/2010 10:01 PM, Simon Riggs wrote:
On Thu, 2010-12-30 at 15:51 -0500, Robert Treat wrote:
Still, one thing that has me concerned is that in the case of two
slaves, you don't know
42 matches
Mail list logo
