"Greg Stark" writes:
> On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas wrote:
>>> What if relabeling support were to spread some more?
>>
>> The only example I can think of besides XML is JSON. There might be a
>> few more. Basically, relabelling is a handy shortcut when you are
>> serializing da
> The point here is that synchronous replication, at least to some
> people, is going to imply that the user-visible states of the two
> copies are consistent. To other people, it is going to imply that
> committed transactions will never be lost even in the event of a
> catastropic loss of the pr
> The point here is that synchronous replication, at least to some
> people, is going to imply that the user-visible states of the two
> copies are consistent. To other people, it is going to imply that
> committed transactions will never be lost even in the event of a
> catastropic loss of the pr
> The whole relabeling thing seems like a seriously silly idea. Why is
> it at all a shortcut to use "AS" instead of "," ?
Because a lot of times you don't want to relabel, so you omit the "AS
label" part altogether, and the label is deduced from the expression
itself. For example, I don't need t
On Sat, 2008-12-13 at 22:23 -0500, Robert Haas wrote:
> > If it's guaranteed to be visible on the standby after it's committed on
> > the master, and you don't have any way to make it actually simultaneous,
> > then that implies that it's visible on the slave for some brief period
> > of time befor
> Might it not be true that anybody unfamiliar would be confused and that this
> is a bit of a straw man?
[...]
> If my application assumes that it can commit to one server, and then read
> back the commit from another server, and my application breaks as a result,
> it's because I didn't understan
> If it's guaranteed to be visible on the standby after it's committed on
> the master, and you don't have any way to make it actually simultaneous,
> then that implies that it's visible on the slave for some brief period
> of time before it's committed on the master.
>
> That situation is still as
On Sat, 2008-12-13 at 21:35 -0500, Robert Haas wrote:
> On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane wrote:
> > "Robert Haas" writes:
> >> I think we need to reserve the term "synchronous replication" for a
> >> system where transactions that begin at the same time on the primary
> >> and standby se
On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane wrote:
> "Robert Haas" writes:
>> I think we need to reserve the term "synchronous replication" for a
>> system where transactions that begin at the same time on the primary
>> and standby see the same tuples. Clearly that is "more" synchronous
>
> We wo
On Sun, Dec 14, 2008 at 1:42 AM, Robert Haas wrote:
>> What if relabeling support were to spread some more?
>
> The only example I can think of besides XML is JSON. There might be a
> few more. Basically, relabelling is a handy shortcut when you are
> serializing data and want to avoid specifyin
> What if relabeling support were to spread some more?
The only example I can think of besides XML is JSON. There might be a
few more. Basically, relabelling is a handy shortcut when you are
serializing data and want to avoid specifying a list of columns and an
(almost) identical list of labels.
On Sun, 2008-12-14 at 03:28 +0300, Oleg Serov wrote:
> Hello!. I'm using PgBouncer with permanent connection, So, when i
> deleting(or editing?) some functions i have an error
> ERROR: cache lookup failed for function ..;
> Can you make recaching of invalidate functions?'
I believe it already
I don't quote know how this data but any constant factor seems like it
would be arbitrary. It sounds like a more principled algorithm would
be to use stats_target^2. But that has the same problem. Even
stats_target^1.5 would be too big for stats_target 10,000.
I think just using 10 is proba
Greg Stark writes:
> Huh, I didn't realize that ever worked in the past. I thought the way
> to do what the op describes was to cast it to text[] or whatever
> datatype you from out-of-band knowledge to expect.
We don't seem to allow that either ...
regression=# select array_to_string(histog
Huh, I didn't realize that ever worked in the past. I thought the way
to do what the op describes was to cast it to text[] or whatever
datatype you from out-of-band knowledge to expect.
--
Greg
On 13 Dec 2008, at 19:38, Tom Lane wrote:
Corey Horton writes:
I'm trying to use array_to_st
"Oleg Serov" writes:
> Hello!. I'm using PgBouncer with permanent connection, So, when i
> deleting(or editing?) some functions i have an error
> ERROR: cache lookup failed for function ..;
You're going to need to explain exactly what you're doing if you
want help with that. However, if the
Corey Horton writes:
> I'm trying to use array_to_string on the pg_stats column
> histogram_bounds...
> test83=# select array_to_string(histogram_bounds::anyarray, '-') from
> pg_stats where attname = 'id' and tablename = 'widgets';
> ERROR: argument declared "anyarray" is not an array but type
Hello!. I'm using PgBouncer with permanent connection, So, when i
deleting(or editing?) some functions i have an error
ERROR: cache lookup failed for function ..;
Can you make recaching of invalidate functions?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Markus Wanner wrote:
I don't think synchronous replication guarantees that it will be
immediately visible. Even if it did push the change to the other
machine, and the other machine had committed it, that doesn't guarantee
that any reader sees it any more than if I commit to the same machine
(no
It appears that the visibility map patch is causing pg_class.reltuples to be
set improperly after a vacuum. For example, it is set to 0 if the map
indicated that no pages in the heap needed to be scanned.
Perhaps reltuples should not be updated unless every page was scanned during
the vacuum?
--
I see. Thanks for the advice. I would research on how to use tuplestore
object.
Regards,
Bramandia R.
On Sat, Dec 13, 2008 at 10:36 AM, Tom Lane wrote:
> "Bramandia Ramadhana" writes:
> > Hmm how if an upper level node needs to store (for future use) the
> > TupleTableSlot* returned by lower
Hi,
Mark Mielke wrote:
> Might it not be true that anybody unfamiliar would be confused and that
> this is a bit of a straw man?
Might be. I've neglected the issue myself for a while.
> I don't think synchronous replication guarantees that it will be
> immediately visible. Even if it did push th
Hi,
Aidan Van Dyk wrote:
> Well, I think the PG MVCC (which wal-streaming just ships across
> somewhere else) will save that. So with hot-standby you could have
> another client could see the result *after* the COMMIT has been
> requested, but *before* the COMMIT returns... But we have this
> si
Markus Wanner wrote:
Tom Lane wrote:
We won't call it anything, because we never will or can implement that.
See the theory of relativity: the notion of exactly simultaneous events
at distinct locations isn't even well-defined
That has never been the point of the discussion. It's rathe
* Markus Wanner [081213 16:33]:
> Hi,
>
> Hannu Krosing wrote:
> > You can have a variantof sync rep + hot standby where the master does
> > not return committed before the slave has both synced the data and
> > replied the transaction so that it is visible on slave but in that case
> > you may h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 13 déc. 08 à 22:32, Tom Lane a écrit :
Spread to what? AFAICS the way that XMLELEMENT uses AS is a
single-purpose wart
Ok now that explains.
The common lisp inspired syntax is only nice if we're to avoid using
AS, which I thought was the situ
Dimitri Fontaine writes:
> What if relabeling support were to spread some more?
Spread to what? AFAICS the way that XMLELEMENT uses AS is a
single-purpose wart (much like a lot of other stuff the SQL committee
invents :-(). I do not see a need to reserve AS in function argument
lists for that p
Hi,
Hannu Krosing wrote:
> You can have a variantof sync rep + hot standby where the master does
> not return committed before the slave has both synced the data and
> replied the transaction so that it is visible on slave but in that case
> you may have a usecase, where it is actually visible on
Hi,
Simon Riggs wrote:
>> Hot Standby (although the latter
>> seems to have stalled a bit...)
>
> It's just being worked on asynchronously. ;-)
LOL, thanks for bringing humor into this discussion :-)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 13 déc. 08 à 17:05, Tom Lane a écrit :
I personally agree that AS seems more SQL-ish, but that's in the eye
of the beholder.
So do I, but I fear it's already taken for another meaning.
The argument about ambiguity in XMLELEMENT is bogus becase
Hi,
Tom Lane wrote:
> We won't call it anything, because we never will or can implement that.
> See the theory of relativity: the notion of exactly simultaneous events
> at distinct locations isn't even well-defined
That has never been the point of the discussion. It's rather about the
question i
ITAGAKI Takahiro escreveu:
> - A new GUC variable 'explain_analyze_format' is added.
I'm afraid that this variable name doesn't tell what it means. What about
'explain_analyze_stats_format' or even 'explain_stats_format'?
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pg
On Sat, 2008-12-13 at 21:35 +0200, Hannu Krosing wrote:
> We still could call Sync Rep as a feature "synchronous replication" on
> basis that "WAL Streaming - Synchronous Write" is the highest security
> level achievable using the feature.
>
> And maybe have Sync Hot Standby as a feature on top o
On Sat, 2008-12-13 at 13:05 -0500, Robert Haas wrote:
> > I certainly agree to using such terms. Unfortunately, in my experience,
> > synchronous replication is commonly used to mean that transactions are
> > guaranteed to be immediately visible on remote nodes after the client
> > got commit ackno
On Sat, 2008-12-13 at 13:05 -0500, Robert Haas wrote:
> Hot Standby (although the latter
> seems to have stalled a bit...)
It's just being worked on asynchronously. ;-)
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing
Synchronous replication, "sync rep" is *not* intersted in the "slave's
visiblity of the commit", because PostgreSQL doesn't "serve" requests
when in recovery (wal receiving) mode *now*.
This sync rep patch/proposal/discution is *strictly* (at this point yet,
hot standby may eventually or hopefully
"Robert Haas" writes:
> I think we need to reserve the term "synchronous replication" for a
> system where transactions that begin at the same time on the primary
> and standby see the same tuples. Clearly that is "more" synchronous
> than what is being proposed here; if we call this "synchronous
> I certainly agree to using such terms. Unfortunately, in my experience,
> synchronous replication is commonly used to mean that transactions are
> guaranteed to be immediately visible on remote nodes after the client
> got commit acknowledgment. That's the cause for confusion I'm envisioning.
I
I started making the changes to increase the default and maximum stats
targets 10X, as I believe was agreed to in this thread:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00386.php
I came across this bit in ts_typanalyze.c:
/* We want statistic_target * 100 lexemes in the MCEL
> I personally agree that AS seems more SQL-ish, but that's in the eye
> of the beholder.
>
> The argument about ambiguity in XMLELEMENT is bogus becase XMLELEMENT
> doesn't (and won't) have named parameters. But it is true that
> XMLELEMENT is doing something subtly different with the AS clause t
Hi,
Simon Riggs wrote:
> On Sat, 2008-12-13 at 14:07 +0100, Markus Wanner wrote:
>> Speaking of a "synchronous commit"
>> is utterly misleading, because the commit itself is exactly the thing
>> that's *not* synchronous.
>
> Not really sure where you're going here.
I'm pointing to a potential mi
On 2008-12-13, at 16:19, Tom Lane wrote:
I'm sure it's technically possible, but I see no redeeming social
value
in it ... we should pick one and quit repainting the bike shed.
+1000
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
David E. Wheeler wrote:
> On Dec 13, 2008, at 5:19 PM, Tom Lane wrote:
>
> > I'm sure it's technically possible, but I see no redeeming social
> > value
> > in it ... we should pick one and quit repainting the bike shed.
>
> Well, as I've said, I'm okay with AS, though it's not my favorite. I
"David E. Wheeler" writes:
> I don't suppose that the position of the label and
> the value on either side of "AS" could be reversible, could it?
No. Consider
SELECT foo(bar AS baz) FROM ...
If the from-clause provides columns named both bar and baz, it would
be impossible to decide
On Dec 13, 2008, at 5:19 PM, Tom Lane wrote:
I'm sure it's technically possible, but I see no redeeming social
value
in it ... we should pick one and quit repainting the bike shed.
Well, as I've said, I'm okay with AS, though it's not my favorite. I
can see the argument that it's more like
"David E. Wheeler" writes:
> On Dec 13, 2008, at 5:05 PM, Tom Lane wrote:
>> However, after looking at the precedent of XMLELEMENT, it's hard to
>> deny that if the SQL committee ever chose to standardize named parameters,
>> AS is what they would use. The chances that ":" would become the
>> s
On Dec 13, 2008, at 5:05 PM, Tom Lane wrote:
However, after looking at the precedent of XMLELEMENT, it's hard to
deny
that if the SQL committee ever chose to standardize named parameters,
AS is what they would use. The chances that ":" would become the
standard are negligible --- that's not t
Dimitri Fontaine wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Le 13 d?c. 08 ? 11:39, Peter Eisentraut a ?crit :
> > On Friday 12 December 2008 20:05:57 Tom Lane wrote:
> >> Excellent. I checked that psql's colon-variable feature behaves the
> >> same. So it looks like th
Dimitri Fontaine writes:
> Le 13 déc. 08 à 11:39, Peter Eisentraut a écrit :
>> I personally thought that AS was a better idea.
> It seems some people want to be able to overload some default
> parameters (but not others) and at the same time alias them to some
> new label. I'm not sure I und
On Sat, 2008-12-13 at 14:07 +0100, Markus Wanner wrote:
> Speaking of a "synchronous commit"
> is utterly misleading, because the commit itself is exactly the thing
> that's *not* synchronous.
Not really sure where you're going here. "synchronous replication" is
used exactly as described in the
On 2008-12-13, at 13:07, Markus Wanner wrote:
However, that is a marketing decision [1], which should not be mixed
with the technical discussion here. Speaking of a "synchronous commit"
is utterly misleading, because the commit itself is exactly the thing
that's *not* synchronous.
[1]: Som
Hi,
Simon Riggs wrote:
> You're right that neither the data transfer nor data availability is
> entirely synchronous, but data transfer is synchronous at time of
> *commit*: it is recorded on multiple nodes at the same time.
I'm unsure what you mean by a "data transfer being synchronous". To what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 13 déc. 08 à 11:39, Peter Eisentraut a écrit :
On Friday 12 December 2008 20:05:57 Tom Lane wrote:
Excellent. I checked that psql's colon-variable feature behaves the
same. So it looks like the proposed "name: value" syntax would
indeed
A Dissabte 13 Desembre 2008, Peter Eisentraut va escriure:
> On Friday 12 December 2008 20:05:57 Tom Lane wrote:
> > Excellent. I checked that psql's colon-variable feature behaves the
> > same. So it looks like the proposed "name: value" syntax would indeed
> > not break any existing features.
On Friday 12 December 2008 20:05:57 Tom Lane wrote:
> Excellent. I checked that psql's colon-variable feature behaves the
> same. So it looks like the proposed "name: value" syntax would indeed
> not break any existing features. Barring better ideas I think we should
> go with that one.
I perso
On Friday 12 December 2008 19:31:11 Robert Haas wrote:
> Not really. I'm not an SELinux expert. But typically the two do
> exist alongside one another. For example, installing SELinux (MAC)
> does on your system does not make "chmod g+w file" (DAC) stop working;
> it merely performs an ADDITIONA
On Friday 12 December 2008 19:09:26 Alvaro Herrera wrote:
> I don't understand -- why wouldn't we just have two columns, one for
> plain row-level security and another for whatever security system the
> platforms happens to offer? If we were to follow that route, we could
> have row-level security
Tom Lane wrote:
Kurt Harriman writes:
However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.
There is no such option, and won't be.
Yours is the first comment anyone has posted to the list
regard
On Sat, 2008-12-13 at 00:00 +0100, Markus Wanner wrote:
> Hi,
>
> Fujii Masao wrote:
> > I'd like to define the meaning of "synch rep" again. "synch rep" means:
> >
> > (1) Transaction commit waits for WAL records to be replicated to the standby
> > before the command returns a "success" i
On Fri, Dec 12, 2008 at 8:05 PM, Tom Lane wrote:
> Michael Meskes writes:
> > On Fri, Dec 12, 2008 at 10:06:30AM -0500, Tom Lane wrote:
> >> Hmm ... actually, ecpg might be a problem here anyway. I know it has
> >> special meaning for :name, but does it allow space between the colon
> >> and th
60 matches
Mail list logo
