Joshua D. Drake wrote:
David Fetter wrote:
On Thu, Sep 11, 2008 at 11:28:36PM -0400, Tom Lane wrote:
Joshua Drake <[EMAIL PROTECTED]> writes:
I think something like:
psql: FATAL: Ident authentication failed for user "root"
HINT:
http://www.postgresql.org/docs/8.3/static/client-authentication
David Fetter wrote:
On Thu, Sep 11, 2008 at 11:28:36PM -0400, Tom Lane wrote:
Joshua Drake <[EMAIL PROTECTED]> writes:
I think something like:
psql: FATAL: Ident authentication failed for user "root"
HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
Would be nice.
Do
Tom Lane wrote:
Joshua Drake <[EMAIL PROTECTED]> writes:
I think something like:
psql: FATAL: Ident authentication failed for user "root"
HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
Would be nice.
Do you really think that's helpful in the typical case wher
On Thu, Sep 11, 2008 at 11:28:36PM -0400, Tom Lane wrote:
> Joshua Drake <[EMAIL PROTECTED]> writes:
> > I think something like:
>
> > psql: FATAL: Ident authentication failed for user "root"
> > HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
>
> > Would be nice.
>
>
On Thu, Sep 11, 2008 at 11:28:36PM -0400, Tom Lane wrote:
> Joshua Drake <[EMAIL PROTECTED]> writes:
> > I think something like:
>
> > psql: FATAL: Ident authentication failed for user "root"
> > HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
>
> > Would be nice.
>
>
Joshua Drake <[EMAIL PROTECTED]> writes:
> I think something like:
> psql: FATAL: Ident authentication failed for user "root"
> HINT: http://www.postgresql.org/docs/8.3/static/client-authentication.html
> Would be nice.
Do you really think that's helpful in the typical case where someone
fat-fi
On Thu, Sep 11, 2008 at 08:10:45PM -0700, Joshua D. Drake wrote:
> On Thu, 11 Sep 2008 22:59:40 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > > psql: FATAL: Ident authentication failed for user "root"
> > > HINT: Is pg_hba.conf set properly on the server?
> >
> > Seems pretty useles
On Thu, 11 Sep 2008 22:59:40 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> > psql: FATAL: Ident authentication failed for user "root"
> > HINT: Is pg_hba.conf set properly on the server?
>
> Seems pretty useless. What does "set properly" mean? There isn't
> even any good reason to think
David Fetter <[EMAIL PROTECTED]> writes:
> This isn't exactly informative to newbies, so I'm proposing a patch
> like that attached for such failures. Instead of seeing that
> mysterious message, they'd get something like this:
> psql: FATAL: Ident authentication failed for user "root"
>
Folks,
Far and away the most common question we get in IRC includes phrases
like:
psql: FATAL: Ident authentication failed for user "root"
This isn't exactly informative to newbies, so I'm proposing a patch
like that attached for such failures. Instead of seeing that
mysterious message, th
Tom Lane wrote:
Ron Mayer <[EMAIL PROTECTED]> writes:
'1Y1M'::interval ... minute ... month
Hmmm. I would say that the problem with that is not that it's
nonstandard but that it's ambiguous.
Ah yes.
Our documentation...says..."or abbreviations".
...What if we just tweak the code to
reje
Ron Mayer <[EMAIL PROTECTED]> writes:
> Oh. I wasn't proposing 8601-only. Just the one-character
> shorthands like '1Y1M'::interval that postgresql interprets
> as "1 year one minute". No standard specifies anything close
> to that; and any similar standards ask to interpret that M as
> months
Tom Lane wrote:
The other problem is that the SQL spec clearly defines an interval
literal syntax, and it's not this ISO thing. So even without backward
compatibility issues, 8601-only doesn't seem like it would fly.
Oh. I wasn't proposing 8601-only. Just the one-character
shorthands like
Ron Mayer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think *replacement* would be a hard sell, as that would tick off all
>> the existing users ;-). Now it seems like being able to accept either
> I originally submitted a patch that supported both, and I think
> you suggested replacing on
I wrote:
> Are people satisfied that the Windows part of the patch is okay?
I went ahead and applied this patch after some trivial stylistic fixes.
The buildfarm will soon tell us if the WIN32 part of the patch compiles,
but not whether it works --- would someone double-check the functioning
of th
Tom Lane wrote:
Ron Mayer <[EMAIL PROTECTED]> writes:
Back a while ago (2003) there was some talk about replacing
some of the non-standard extensions with shorthand forms of
intervals with ISO 8601 intervals that have a similar but
not-the-same shorthand.
I think *replacement* would be a hard
Ron Mayer <[EMAIL PROTECTED]> writes:
> Back a while ago (2003) there was some talk about replacing
> some of the non-standard extensions with shorthand forms of
> intervals with ISO 8601 intervals that have a similar but
> not-the-same shorthand.
I think *replacement* would be a hard sell, as tha
Josh Berkus wrote:
Josh is probably basing that on the long history of
discussion/revision cycles.
Yep, and that *I* don't understand what the patch does, so I'm not going to
turn a newbie reviewer loose on it.
Here is a quick overview, there are two parts to the patch:
1. event system
T
Tom Lane wrote:
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
Tom Lane <[EMAIL PROTECTED]> wrote:
I am not sure about some of the corner cases --- anyone want to see if
their understanding of the spec for is different?
The patch seems to support extensions to the standard.
Right. All of t
> Josh is probably basing that on the long history of
> discussion/revision cycles.
Yep, and that *I* don't understand what the patch does, so I'm not going to
turn a newbie reviewer loose on it.
--
--Josh
Josh Berkus
PostgreSQL
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-h
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> sys/time.h and unistd.h are #included just a few lines after that, but
> within a #ifndef WIN32 block. I don't think the patch added any
> codepaths where we'd need those header files on Windows, so I presume
> that was just an oversight and those
On Thu, Sep 11, 2008 at 5:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The patch looks OK to me as it was the last time I looked at it; maybe
>> Tom has more comments, so I decided against just committing it.
>
> I haven't got round to looking at it in this fest. If anyone else wants
> to look it
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Merlin Moncure escribió:
>> Alvaro actually performed a review on libpq events. We are waiting on
>> his feedback on our changes (based on his review) and the newly
>> submitted documentation. I'll update the wiki accordingly. I wasn't
>> sure if Alva
Hi Magnus,
Josh has assigned your patch to me for an initial review.
First up I'd like to say that this is a really nice upgrade.
Shielding a running server from reloading a bogus conf file makes a
whole lot of sense.
On Sun, Aug 17, 2008 at 1:47 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Here is an updated version of the "Copy storage parameters" patch.
> http://archives.postgresql.org/pgsql-hackers/2008-07/msg01417.php
I looked this over and feel that it still needs work. The
implementation seems appropriate for columns coming from
Gregory Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
I'm not sure what to do if we need signals sent from processes that
aren't connected to shared memory; but maybe we need not cross that
bridge here.
Such as signals coming from the postmaster? Isn't that where most of them come
from th
Alvaro Herrera wrote:
Actually a minor gripe ... should PQsetvalue be PQsetValue? :-)
We were mimicing PQgetvalue, which uses a lowercase 'v'. Is there a
preference, none on this end.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing li
Merlin Moncure escribió:
> On Thu, Sep 11, 2008 at 1:53 AM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> > Some patches have not been assigned to reviewers for various reasons. The
> > following weren't assigned because they are complex and really need a
> > high-end hacker or committer to take them on
On Thu, Sep 11, 2008 at 1:53 AM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Some patches have not been assigned to reviewers for various reasons. The
> following weren't assigned because they are complex and really need a
> high-end hacker or committer to take them on:
>
> libpq events
Alvaro actual
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Back in February, Tom said here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00963.php :
That defeats a couple of optimizations that
Simon put in recently. The one for no XLOG during COPY is not too
hard to see how to re-enable, b
Andrew Dunstan wrote:
Back in February, Tom said here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00963.php :
That defeats a couple of optimizations that
Simon put in recently. The one for no XLOG during COPY is not too
hard to see how to re-enable, but I'm not sure what else the
On Thu, Sep 11, 2008 at 9:01 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Could someone please point me at where this optimization was committed? I'm
> having trouble locating it.
I think it's this one:
http://archives.postgresql.org/pgsql-committers/2007-01/msg00296.php
--
Guillaume
--
Sen
Back in February, Tom said here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00963.php :
That defeats a couple of optimizations that
Simon put in recently. The one for no XLOG during COPY is not too
hard to see how to re-enable, but I'm not sure what else there was.
Could s
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Here is a patch to user NDirectFileRead/Write counters to get I/O counts
> in BufFile module. We can see the counters when log_statement_stats is on.
Couple thoughts here:
* Let's rename them BufFileReadCount and BufFileWriteCount to reflect
their ac
Josh Berkus <[EMAIL PROTECTED]> writes:
> Also, note that the following patches need performance testing on a
> variety of platforms. Everyone should help with this.
> GSoC Improved Hash Indexing
> posix fadvises
> operator restrictivity function for text search
> CLUSTER using sort instead of in
On Fri, Sep 12, 2008 at 3:34 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Applied with minimal modifications. I changed a couple of error
> messages that didn't seem to meet the style guidelines,
Great, thanks Tom. And thanks again to Alex and Martijn for helping
me refine the patch.
> and I moved
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
> Simon Riggs wrote:
>> Taking snapshots from primary has a few disadvantages
>>
>> ...
>> * snapshots on primary prevent row removal (but this was also an
>> advantage of this technique!)
>
> That makes it an awful solution for high ava
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I've attached a new version of the patch (version 3), as well as an
> incremental patch to show the differences between versions 2 and 3.
Applied with minimal modifications. I changed a couple of error
messages that didn't seem to meet the style guidel
Gregory Stark wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
BTW, we haven't talked about how to acquire a snapshot in the slave. You'll
somehow need to know which transactions have not yet committed, but will in the
future.
I'm not sure why you need to know which ones will commit in
On Tue, 2008-09-02 at 12:47 -0400, Alvaro Herrera wrote:
> Unknown SDATA: [mdash ]
> at /usr/share/sgml/docbook/utils-0.6.14/helpers//docbook2man-spec.pl
> line 1241, line 11975.
>
> Please see here:
>
> http://archives.postgresql.org/message-id/20080821130203.GN4169%
> 40alvh.no-ip.org
FWIW, F
Tom Lane <[EMAIL PROTECTED]> writes:
> I'm not sure what to do if we need signals sent from processes that
> aren't connected to shared memory; but maybe we need not cross that
> bridge here.
Such as signals coming from the postmaster? Isn't that where most of them come
from though?
--
Gregor
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> BTW, we haven't talked about how to acquire a snapshot in the slave. You'll
> somehow need to know which transactions have not yet committed, but will in
> the
> future.
I'm not sure why you need to know which ones will commit in the future. ISTM
"Lawrence, Ramon" <[EMAIL PROTECTED]> writes:
> To keep the changes simple, the update simply calls
> ExecChooseHashTableSize() in create_hashjoin_plan() to re-calculate the
> expected number of batches. This is more efficient and results in less
> code changes than modifying the HashPath struct t
Hi,
Tom Lane wrote:
No, that's not what I had in mind at all, just the ability to deliver
one of a specified set of event notifications --- ie, get around the
fact that Unix only gives us two user-definable signal types.
Ah, okay. And I already thought you'd like imessages :-(
For signals se
ITAGAKI Takahiro wrote:
***
*** 29,36
--- 29,40
#include "postgres_fe.h"
#include "libpq-fe.h"
+ #include "pqsignal.h"
#include
+ #include
+ #include
+ #include
#ifdef WIN32
#undef FD_SETSIZE
sys/time.h and unistd.h are #included just a few lines
Markus Wanner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Sooner or later we shall have to bite the bullet and set up a
>> multiplexing system to transmit multiple event types to backends with
>> just one signal. We already did it for signals to the postmaster.
> Agreed. However, it's non-tr
Jorgen Austvik - Sun Norway wrote:
> The attached patch makes pg_regress write converted files to
> /sql and /expected, which is one way to make it read
> and write to the same directory. Tested on Solaris x86 with pgsql "make
> check" and standalone.
Okay, so this patch does change it in a
Fujii Masao wrote:
I think that this case would often happen. So, we should establish a certain
solution or procedure to the case where TLI of the master doesn't match
TLI of the slave. If we only allow the case where TLI of both servers is the
same, the configuration after failover always needs
On Thu, Sep 11, 2008 at 3:17 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-09-10 at 17:57 +0900, Fujii Masao wrote:
>
>> My sequence covers several cases :
>>
>> * There is no missing WAL file.
>> * There is a lot of missing WAL file.
>
> This is the likely case for any medium+ sized
Simon Riggs wrote:
So part of the handshake between
primary and standby must be "what is your recentxmin?". The primary will
then use the lower/earliest of the two.
Even then, the master might already have vacuumed away tuples that are
visible to an already running transaction in the slave, be
Peter Eisentraut wrote:
> Alvaro Herrera wrote:
>> So I went ahead and moved its mention to a separate question, where it
>> has a lot more visibility. (I also added an URL to anoncvs, where
>> people can see it more readily.)
>
> Perhaps the low visibility also has to do with the fact that
> do
Thanks for the detailed thinking. At least one very good new idea here,
some debate on other points.
On Thu, 2008-09-11 at 09:24 +0300, Heikki Linnakangas wrote:
> And still we can't escape the scenario that the slave receives a WAL
> record that vacuums away a tuple that's still visible accor
Csaba Nagy wrote:
and that means in fact that if you have
continuously overlapping small transactions, the "blocking horizon"
could be even blocked forever, as there'll always be a query running,
and the new queries will always have the snapshot of the currently
running ones because WAL recovery
Le jeudi 11 septembre 2008, Csaba Nagy a écrit :
> Well now that I think I understand what Heikki meant, I also think the
> problem is that there's no choice at all to advance, because the new
> queries will simply have the same snapshot as currently running ones as
> long as WAL reply is blocked..
On Thu, 2008-09-11 at 15:33 +0200, Dimitri Fontaine wrote:
> What would forbid the slave to choose to replay all currently lagging WALs
> each time it's given the choice to advance a little?
Well now that I think I understand what Heikki meant, I also think the
problem is that there's no choice a
Le jeudi 11 septembre 2008, Heikki Linnakangas a écrit :
> Well, yes, but you can fall behind indefinitely that way. Imagine that
> each transaction on the slave lasts, say 10 minutes, with a new
> transaction starting every 5 minutes. On the master, there's a table
> that's being vacuumed (or HOT-
On Thu, 2008-09-11 at 16:19 +0300, Heikki Linnakangas wrote:
> Well, yes, but you can fall behind indefinitely that way. Imagine that
> each transaction on the slave lasts, say 10 minutes, with a new
> transaction starting every 5 minutes. On the master, there's a table
> that's being vacuumed (
> I'd imagine that even if applying the WAL on the slave is blocked, it's
> still streamed from the master to the slave, and in case of failover the
> slave will fast-forward before starting up as the new master. Of course, if
> it has fallen 3 days behind because of a giant reporting query, it can
Csaba Nagy wrote:
On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
One problem with this, BTW, is that if there's a continuous stream of
medium-length transaction in the slave, each new snapshot taken will
prevent progress in the WAL replay, so the WAL replay will advance in
"baby
On Thu, Sep 11, 2008 at 2:07 AM, Simon Riggs wrote:
> Transaction snapshots is probably the most difficult problem for Hot
> Standby to resolve.
> * remotely from primary node
> * locally on the standby node
>
> If we derive a snapshot locally, then we will end up with a situation
> wher
Hi,
Tom Lane wrote:
Sooner or later we shall have to bite the bullet and set up a
multiplexing system to transmit multiple event types to backends with
just one signal. We already did it for signals to the postmaster.
Agreed. However, it's non-trivial if you want reliable queues (i.e. no
mes
Hi,
Fujii Masao wrote:
Umm... backends have already used SIGUSR1. PostgresMain() sets up a signal
handler for SIGUSR1 as follows.
Uh.. right. Thanks for pointing that out. Maybe just use SIGPIPE for now?
Yes, since WAL sender waits on select(), it's convenient to use signal
for the notificat
"Fujii Masao" <[EMAIL PROTECTED]> writes:
> Which signal should WAL sender send to backends?
Sooner or later we shall have to bite the bullet and set up a
multiplexing system to transmit multiple event types to backends with
just one signal. We already did it for signals to the postmaster.
On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
> One problem with this, BTW, is that if there's a continuous stream of
> medium-length transaction in the slave, each new snapshot taken will
> prevent progress in the WAL replay, so the WAL replay will advance in
> "baby steps", and
On Wed, Sep 10, 2008 at 11:13 PM, Markus Wanner <[EMAIL PROTECTED]> wrote:
>> Which signal should we use for the notification to the backend from
>> WAL sender? The notable signals are already used.
>
> I'm using SIGUSR1, see src/backend/storage/ipc/imsg.c from Postgres-R, line
> 232. That isn't is
Csaba Nagy wrote:
On Thu, 2008-09-11 at 15:23 +0300, Heikki Linnakangas wrote:
I'd imagine that even if applying the WAL on the slave is blocked, it's
still streamed from the master to the slave, and in case of failover the
slave will fast-forward before starting up as the new master.
Which b
Gregory Stark wrote:
b) vacuum on the server which cleans up a tuple the slave has in scope has to
block WAL reply on the slave (which I suppose defeats the purpose of having
a live standby for users concerned more with fail-over latency).
One problem with this, BTW, is that if there's a
On Thu, 2008-09-11 at 15:23 +0300, Heikki Linnakangas wrote:
> I'd imagine that even if applying the WAL on the slave is blocked, it's
> still streamed from the master to the slave, and in case of failover the
> slave will fast-forward before starting up as the new master.
Which begs the questio
Merlin Moncure wrote:
There is nothing stopping you from setting up two (or more) slave
servers, with one designated as failover that doens't serve queries,
right?
I'd imagine that even if applying the WAL on the slave is blocked, it's
still streamed from the master to the slave, and in case o
> temp_buffers is actually special-cased in the code because
>
> /*
>* We show the GUC var until local buffers have been initialized, and
>* NLocBuffer afterwards.
>*/
>
> It is not clear to me right now why that is a good idea. But it is only
> this one paramter.
OK, well that's no
On Thu, Sep 11, 2008 at 7:18 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> a) transactions with live snapshots on the slave prevent the master from being
> able to vacuum tuples (which defeats the purpose of having a live standby
> server for some users).
>
> or
>
> b) vacuum on the server whi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Actually, 8.2 initializes it to InvalidTransactionId too, so it doesn't
> seem like there's a problem there either. Since the problem stems from
> using it as initializer for the Min() calculation, there's no actual bug
> on 8.2 either. The bug only ap
Another question:
Does we need random_bool to spread workload? It seems to me a useless, because
it also invokes one backend to use more pages instead of using one which is
already in buffer cache. I think that it should generate a lot of extra i/o. Do
not forget WAL full page write for firsti
Alvaro Herrera wrote:
So I went ahead and moved its mention to a separate question, where it
has a lot more visibility. (I also added an URL to anoncvs, where
people can see it more readily.)
Perhaps the low visibility also has to do with the fact that
documentation is hidden under "tools".
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> temp_buffers is actually special-cased in the code because
> /*
> * We show the GUC var until local buffers have been initialized, and
> * NLocBuffer afterwards.
> */
> It is not clear to me right now why that is a good idea.
I th
Zdenek Kotala wrote:
I have question about FSM structure on the page. If I look into the code
it seems to me that tree structure is "degenerated" on the right side.
It is probably space optimization because complete tree needs BLCKSZ/2
space on the page and rest is empty.
Is my assumption cor
I have question about FSM structure on the page. If I look into the code it
seems to me that tree structure is "degenerated" on the right side. It is
probably space optimization because complete tree needs BLCKSZ/2 space on the
page and rest is empty.
Is my assumption correct? If yes maybe ext
Gregory Stark <[EMAIL PROTECTED]> writes:
> Abbas <[EMAIL PROTECTED]> writes:
>> While writing code or reviewing a path are we supposed to consider the
>> camel cased names correct or the under-score separated names correct?
> Some parts of the code use the two to distinguish between functions loc
Robert Haas wrote:
A good start might be to always OUTPUT memory parameters using the
same base unit.
SHOW gives output that matches what you input.
Not for me it doesn't.
portal=# show temp_buffers;
temp_buffers
--
1024
(1 row)
portal=# set temp_buffers = '16MB';
SET
portal=#
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2008-09-11 at 11:11 +0100, Richard Huxton wrote:
>
>> I have to say I agree with Heikki here. Blocking the master based on
>> what the slave is doing seems to make host standby less useful than warm.
>
> I agree also, that why I flagged it up for
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On Wed, Sep 10, 2008 at 9:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> On reflection I'm not even sure that this is strictly an autovacuum
>> bug. It can be cast more generically as "RecentGlobalXmin getting
>> used without ever having been set", and
Abbas <[EMAIL PROTECTED]> writes:
> While writing code or reviewing a path are we supposed to consider the
> camel cased names correct or the under-score separated names correct?
Some parts of the code use the two to distinguish between functions local to
that module and functions that are part
Heikki Linnakangas wrote:
> ITAGAKI Takahiro wrote:
>> Here is a revised version of the pgbench duration patch.
>
> Looking at the Win32 timer implementation, it's a bit different from the
> one we have in src/backend/port/win32/timer.c. The one in timer.c uses a
> separate thread and WaitForSingl
On Thu, 2008-09-11 at 11:11 +0100, Richard Huxton wrote:
> I have to say I agree with Heikki here. Blocking the master based on
> what the slave is doing seems to make host standby less useful than warm.
I agree also, that why I flagged it up for discussion.
--
Simon Riggs www.2ndQu
Abbas wrote:
Hi,
I have noticed two different coding conventions being followed in
postgres code base.
See e.g. function names in syslogger.c
static void set_next_rotation_time(void);
static void sigHupHandler(SIGNAL_ARGS);
and variable names in the same file
int bytes_in_logbuffer = 0;
ITAGAKI Takahiro wrote:
Here is a revised version of the pgbench duration patch.
Looking at the Win32 timer implementation, it's a bit different from the
one we have in src/backend/port/win32/timer.c. The one in timer.c uses a
separate thread and WaitForSingleObjectEx() to wait, while your
i
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> Taking snapshots from primary has a few disadvantages
>>
>> ...
>> * snapshots on primary prevent row removal (but this was also an
>> advantage of this technique!)
>
> That makes it an awful solution for high availability. A backend
Abbas wrote:
I have noticed two different coding conventions being followed in
postgres code base.
See e.g. function names in syslogger.c
static void set_next_rotation_time(void);
static void sigHupHandler(SIGNAL_ARGS);
and variable names in the same file
int bytes_in_logbuffer = 0;
char
On Thu, 2008-09-11 at 09:24 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Taking snapshots from primary has a few disadvantages
> >
> > ...
> > * snapshots on primary prevent row removal (but this was also an
> > advantage of this technique!)
>
> That makes it an awful
Hi,
I have noticed two different coding conventions being followed in
postgres code base.
See e.g. function names in syslogger.c
static void set_next_rotation_time(void);
static void sigHupHandler(SIGNAL_ARGS);
and variable names in the same file
int bytes_in_logbuffer = 0;
char*current
On Thu, 2008-09-11 at 09:24 +0300, Heikki Linnakangas wrote:
> I like the idea of acquiring snapshots locally in the slave much more.
> As you mentioned, the options there are to defer applying WAL, or cancel
> queries.
More exotic ways to defer applying WAL include using some smart
filesystem
David Rowley wrote:
The thing that surprised me was that string_to_array didn't perform as well.
I expected single character searches to perform a little better. I can't
think why it would be slower now.
Yes, that's strange. I tried to reproduce that here, with a CVS snapshot
before the patch,
92 matches
Mail list logo
