OK, marked as done. Thanks.
---
Volkan YAZICI wrote:
> IIRC, "Update pg_dump and psql to use the new COPY libpq API" TODO
> item's goal is already achieved in the cvs tip.
>
>
> Regards.
>
> ---(e
Kevin Brown <[EMAIL PROTECTED]> writes:
> After examining the output of pg_filedump, it became obvious this was
> a corrupt page issue. What bothers me is the way in which it's
> corrupt. The corrupt data looks supiciously like the data from
> different table, or perhaps from an index. In this c
Apologies if my previous attempts to post this to the mailing list
have actually succeeded, but I've seen no evidence of that...
While doing some bugzilla testing, I ran into a data page corruption
issue.
The symptom was the usual "could not access status of transaction
". I tracked it down vi
Hi,
Tom Lane writes:
Martijn van Oosterhout writes:
For simple systems then you could have a short pg_hba.conf to limit the
IP addresses users can connect on, and the DB stores what databases
they have access to...
Right, you'd still have a pg_hba.conf, but it would hopefully be short
and sw
Thank you very much :) :)
On Sun, 2006-04-16 at 17:08 -0400, Tom Lane wrote:
> Gevik Babakhani <[EMAIL PROTECTED]> writes:
> > On Sun, 2006-04-16 at 11:48 -0400, Tom Lane wrote:
> >> I don't think there would be any objection to adding a database-level
> >> CONNECT privilege that's checked inside
Martijn van Oosterhout wrote:
>On Thu, Apr 13, 2006 at 09:00:10PM -0400, Tom Lane wrote:
>
>
>>Probably there would need to be at least three callbacks involved:
>>one for setup, called just after the tuple descriptor info has been
>>received; one for per-field data receipt, and one for per-tupl
Martijn van Oosterhout writes:
> Do people like this idea?
Not really ...
> Note, I don't return a pointer to the GnuTLS session anywhere. I think
> that's a bad idea all round and we need to provide another way for
> programs to acheive the same effect.
No, failing to provide that is the bad i
Martijn van Oosterhout writes:
> For simple systems then you could have a short pg_hba.conf to limit the
> IP addresses users can connect on, and the DB stores what databases
> they have access to...
Right, you'd still have a pg_hba.conf, but it would hopefully be short
and sweet, not doing much
Gevik Babakhani <[EMAIL PROTECTED]> writes:
> On Sun, 2006-04-16 at 11:48 -0400, Tom Lane wrote:
>> I don't think there would be any objection to adding a database-level
>> CONNECT privilege that's checked inside the database, *after* the
>> existing pg_hba.conf mechanism.
> Tom, could you please
Martijn van Oosterhout writes:
> I must be missing something obvious, but why don't we compress the
> xlogs? They appear to be quite compressable (>75%) with standard gzip...
Might be worth experimenting with, but I'm a bit dubious. We've seen
several tests showing that XLogInsert's calculation
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2006-04-15 at 11:45 -0400, Tom Lane wrote:
>> No, we'll just change the test in xlog.c so that fullPageWrites is
>> ignored if XLogArchivingActive.
> I can see the danger of which you speak, but does it necessarily apply
> to all forms of backup?
There was some discussion about the issues relating to using other SSL
libraries. In a nutshell, it came down to that we couldn't return
anything other than an OpenSSL pointer from PQgetssl because existing
programs simply wouldn't know what to do with it.
So, I was pondering what we might want fr
On Sun, Apr 16, 2006 at 08:34:10PM +0200, Gevik Babakhani wrote:
> On Sun, 2006-04-16 at 11:48 -0400, Tom Lane wrote:
>
> > I don't think there would be any objection to adding a database-level
> > CONNECT privilege that's checked inside the database, *after* the
> > existing pg_hba.conf mechanism
Hannu Krosing <[EMAIL PROTECTED]> writes:
> But if we do need to consider the kernel-level behaviour mentioned, then
> the whole PITR thing becomes an impossibility. Consider the case when we
> get a torn page during the initial copy with tar/cpio/rsync/whatever,
> and no WAL record updates it.
Th
Ühel kenal päeval, P, 2006-04-16 kell 11:31, kirjutas Tom Lane:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > So we should probably document that rsync is only working solution.
>
> No, we're just turning off the variable. One experiment on one version
> of rsync doesn't prove it's "safe", even
On Sun, 2006-04-16 at 11:48 -0400, Tom Lane wrote:
> I don't think there would be any objection to adding a database-level
> CONNECT privilege that's checked inside the database, *after* the
> existing pg_hba.conf mechanism. That requires no new concepts: we
> already have databases and privilege
On Sat, Apr 15, 2006 at 01:31:58PM +0300, Hannu Krosing wrote:
> > (No, I don't think tar's blocksize options control this
> > necessarily --- those indicate the blocking factor on the *tape*.
> > And not everyone uses tar anyway.)
>
> If I'm desperate enough to get the 2x reduction of WAL writes,
Martijn van Oosterhout writes:
>> there is actually no proof of the current order depency is really
>> a good idea. Other access lists work without that constraint.
> For something that may not be a good idea, it's awfully popular.
Didn't we have this entire discussion a month ago?
I don't thin
On Sat, 2006-04-15 at 11:45 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking we should throw an error on pg_start_backup() and
> > pg_stop_backup if full_page_writes is off.
>
> No, we'll just change the test in xlog.c so that fullPageWrites is
> ignored if XLogArchivingActive.
I
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> So we should probably document that rsync is only working solution.
No, we're just turning off the variable. One experiment on one version
of rsync doesn't prove it's "safe", even if there weren't the kernel-
behavior issue to consider.
On Sun, Apr 16, 2006 at 03:37:42PM +0200, Tino Wildenhain wrote:
> > Apart from the complaint that this makes no attempt to take care of the
> > fact that entires in pg_hba.conf are order sensetive. Where is that
> > found in this syntax? What about pg_ident.conf?
>
> there is actually no proof of
...
>> 2. What do we think about the SQL command to be. Would it be like the
>> following or another syntax.
>>
>> GRANT
>> CONNECTION [LOCAL | HOST | HOSTSSL | HOSTNOSSL ]
>> ON [ ALL | mydatabase1 ]
>> TO [ ALL | user1,user2,user3 ]
>> FROM 127.0.0.1/32
>> METHOD [ TRU
On Sun, Apr 16, 2006 at 01:08:36PM +0200, Gevik Babakhani wrote:
> Folks,
>
> I would like to start a discussion regarding the TODO item "%Allow
> pg_hba.conf settings to be controlled via SQL"
> 1. What do we think about removing the pg_hba.conf functionality keeping
> the connection informati
On 4/16/06, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > I guess that writing our own pg_tar, which cooperates with postgres
> > backends to get full pages, is still in the realm of possible things,
> > even on kernels which dont guarantee atomic visibility of write() calls.
> >
> > But until s
Folks,
I would like to start a discussion regarding the TODO item "%Allow
pg_hba.conf settings to be controlled via SQL"
In the past threads we have been talking about some of the options of
how this could be done. I would like to discuss the following items to
get more clarity.
1. What do we th
IIRC, "Update pg_dump and psql to use the new COPY libpq API" TODO
item's goal is already achieved in the cvs tip.
Regards.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
-Original Message-
From: "Jonah H. Harris"<[EMAIL PROTECTED]>
Sent: 15/04/06 20:06:27
To: "Pgsql Hackers"
Subject: [HACKERS] Google SoC--Idea Request
> As such, we need to quickly put together a list of oh, 15-20 midlevel
> project ideas.
Another thought - a nice C++ project, requiring
27 matches
Mail list logo
